bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Warnings to be fixed


From: Jim Meyering
Subject: Re: Warnings to be fixed
Date: Sat, 18 Oct 2008 14:37:42 +0200

Jim Meyering <address@hidden> wrote:
> Paul Eggert <address@hidden> wrote:
>> Jim Meyering <address@hidden> writes:
>>
>>>       mode = (sizeof (mode_t) < sizeof (int)
>>>           ? va_arg (ap, int)
>>>           : va_arg (ap, mode_t));    <<<============ line 43
>>>
>>> IMHO, adding casts here just to avoid that warning would be
>>> counterproductive.
>>
>> I agree.  But would it turn your stomach to rewrite it this way?
>> (I assume this would silence the warning.)  In general I don't like
>> this kind of rewrite, but in this particular case it might be OK.
>>
>>   if (sizeof (mode_t) < sizeof (int))
>>     mode = va_arg (ap, int);
>>   else
>>     mode = va_arg (ap, mode_t);
>
> Nice work-around.
> Ok for me to push this in your name?

Unfortunately, that provokes an ominous-looking warning on at
least i386 FreeBSD 6.1 (gcc 4.2.0 20070307):

open-safer.c: In function 'open_safer':
open-safer.c:44: warning: 'mode_t' is promoted to 'int' when passed through 
'...'
open-safer.c:44: warning: (so you should pass 'int' not 'mode_t' to 'va_arg')
open-safer.c:44: note: if this code is reached, the program will abort

Of course, the offending code is never reached,
but this warning is worse than the original.

The obvious next step (which I'd been hoping to avoid)
is to write a autoconf compile-test in open-safer.m4 that
defines a cpp macro so we can instead do this:

       mode = va_arg (ap, GL_TYPE_MODE_T_OR_INT);

where that macro is defined to either int or mode_t, accordingly.
Any other ideas?

We can always revert back to using the conditional expression,
but this started as an attempt to avoid compiler warnings.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]