This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: ["Markus F.X.J. Oberhumer" <


many thanks for your suggestion.

Unfortunately this is not feasible in my situation as I'm also
using C++, and I'm not sure what other compilers would say
about this on high warning levels.

Still I think that the libc headers should be warning free 
(as are libc5 and glibc 2.0), but I don't want to make
a problem out of this.

JFYI, I've specialized on high-performance data compression
(see my homepage for some publicly available GPL packages),
and doing both fast and portable (from 16 to 64 bits)
low-level address shuffling is very sensible to implicit
(and explicit) conversions such as integral promotion.
-Wconversion has helped me spotting some of these nasty
surprises (void * vs int vs long vs size_t vs ptrdiff_t).


On 29-May-1999 Geoff Keating wrote:
>> Date: Fri, 28 May 1999 16:34:48 +0200 (CEST)
>> Reply-To:
>> From: "Markus F.X.J. Oberhumer" <>
>> Does this mean that the glibc 2.1 will not be -Wconversion
>> warning free ?
>> I'm asking this as -Wconversion does have some usefulness
>> when porting software across machines with different int sizes,
>> and my "-O2 -Wconversion -W... -Werror" is a real-world
>> example.
>> The problem as I see it that because of optimization parts
>> of the implementation become visible in the interface, and
>> the implementation is not fully warning free. This should
>> get fixed, IMHO, probably by using int params in the
>> internal functions.
> You can eliminate all need for -Wconversion by supplying appropriate
> prototypes for your functions (you may like to provide more than one
> prototype).  For instance,
> extern int bar();
> extern int bar(short x, short y);
> produces, with 'gcc -O2':
> /tmp/z.c:2: conflicting types for `bar'
> /tmp/z.c:2: An argument type that has a default promotion
> /tmp/z.c:2: can't match an empty parameter name list declaration.
> /tmp/z.c:1: previous declaration of `bar'
> whereas the same thing with 'int' works fine.
> Note that the order of the prototypes matters.  You must have the
> empty prototype first.
> There was an interesting bug in the PostgreSQL database server
> recently that was of exactly this form, except that the authors were
> casting the equivalent of 'bar' to 'int (*)()' and then calling it,
> which of course doesn't work, and which they would have noticed much
> earlier if they had included an empty prototype before the definition
> of 'bar'.
> -- 
> Geoffrey Keating <>

-----   Markus F.X.J. Oberhumer <>   -----
-----                  -----
-----        5E CB 5C 85 DE AF 9E BF  E9 DA 7E 6A 39 F8 CC 67          -----

                             3 WARPS TO URANUS

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]