From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark Kettenis To: aj@suse.de Cc: libc-hacker@sourceware.cygnus.com Subject: Re: Further cleanup for glibc 2.2 Date: Sat, 29 Jan 2000 05:43:00 -0000 Message-id: <200001291343.e0TDhF008729@delius.kettenis.local> References: X-SW-Source: 2000-01/msg00208.html From: Andreas Jaeger Date: 29 Jan 2000 13:21:15 +0100 Andreas, the report that prompted you to make these changes mentioned that the problem occurred with glibc-2.1.3pre1. I believe that -pre1 was made *after* the inclusion of was removed from but *before* the inline I/O functions were added. Ulrich, could you please try to add a ChangeLog entry when you make a semi-public or public release. That would make determining whether a bug has already been fixed somewhat easier. I'm not really happy with this patch - the changes in glibc 2.1.3 to lead to the introduction of new symbols with version 2.1.3. Do we really want to have these functions with version 2.1.3? I don't think so, and I'm not sure whether we want to add those functions to 2.2. Let me explain: The origional that comes with the Linux kernel, and that we previously included from uses `extern inline'. Linus is on record for saying that he uses `extern inline' in places where he would otherwise use a macro, and expects those functions to be *always* inlined by the compiler. He complained to the GCC folks when some `extern inlines' in the kernel were no longer inlined. Of course this is a bit annoying, but we should realise that by changing this, we're modifying *existing* behaviour. If people think that is OK, we have several options: * Turn the I/O functions into macros. This is what most closely mimicks Linus' intentions because the code will always be "inlined", but we lose type-checking and debugging becomes a bit annoying. * Keep things as they are, but emit a warning when is included in a file that is compiled without optimization. There is still the possibility that the compiler doesn't inline a I/O functions and will produce a linker warning though. * Use `static inline' instead. The user won't notice when I/O functions aren't inlined when compiling without optimization, except that the program becomes a bit larger (but probably not more than a few bytes). * Provide public entry-points for the I/O functions. This introduces potential versioning problems, although their impact would probably notbe noticable. The I/O functions are only used in a few programs and everyone who uses a sane compiler and -O when compiling these programs will not introduce a dependency on the new, versioned symbols. Personally I think providing entry-points for the I/O functions is overkill, and I would go for the `static inline' approach. Mark