text: Mike Frysinger wrote:> On Saturday 27 December 2008 14:23:19 H. Peter Anvin wrote:>> Mike Frysinger wrote:>>> {su}{8,16,32,64} doesnt matter too much to me vs {u,}int_t{8,16,32,64}_t.>>> as long as people stop using __{su}{8,16,32,64}. using the latter>>> though does mean headers will more likely be "just usable" w/out needing>>> linux/types.h include. but then people would be forced to include>>> stdint.h or similar before a linux header ... and that sucks.>> That is a total non-starter. This would mean that the C library itself>> cannot use these headers without exporting additional symbols into the>> namespace, *WHICH IT IS NOT ALLOWED TO DO*.> > which is already happening today you mean. grep the kernel headers and you'll > see a ton of [u]intXX_t hits.Now, keep in mind this is only true for headers exported to userspace.But this is correct - which is the base of this conversation (Samsuggesting that they should be warned about, and I suggestedauto-converting them.)> this logic though means that the kernel should not be defining any structures > that the C library is defining (such as asm-generic/fcntl.h). such structs > should get renamed the same way as __[us]XX typesThis is also correct, at least for exported headers. Forkernel-internal headers, it doesn't matter. Unfortunately we do have atleast several cases of exported interfaces with globally visible names.There is one other exception of note, which is a header file which canonly be included by the userspace *application*, using a nonportabletop-level include (either directly <linux/*> or indirectly via <sys/*>). In those cases we can be looser about at least structure names. Thisis common for ioctl structures. -hpa-- H. Peter Anvin, Intel Open Source Technology CenterI work for Intel. I don't speak on their behalf.