[rtems commit] semopen.c: Address set but unused variable warning

Joel Sherrill joel.sherrill at OARcorp.com
Sun Sep 22 14:45:47 UTC 2013


There is precedence for using the compiler attributes
so I just added that and switched.

Thanks for the feedback.

If we have a print format string to use for mode_t and
wchar_t, a few more cases would be fixed.

On 9/22/2013 7:32 AM, Pavel Pisa wrote:
> Hello Ralf and others,
> 
> On Sunday 22 of September 2013 05:01:49 Ralf Corsepius wrote:
>>> diff --git a/cpukit/posix/src/semopen.c b/cpukit/posix/src/semopen.c
>>> index b863080..e61fad0 100644
>>> --- a/cpukit/posix/src/semopen.c
>>> +++ b/cpukit/posix/src/semopen.c
>>> @@ -43,6 +43,14 @@
>>>    *        parameters must be present.
>>>    */
>>>
>>> +/*
>>> + * mode is set but never used. GCC gives a warning for this
>>> + * and we need to tell GCC not to complain. But we have to
>>> + * have it because we have to work through the variable
>>> + * arguments to get to attr.
>>> + */
>>> +#pragma GCC diagnostic push
>>> +#pragma GCC diagnostic ignored "-Wunused-but-set-variable"
>>>   sem_t *sem_open(
>>>     const char *name,
>>>     int         oflag,
>>> @@ -137,3 +145,4 @@ return_id:
>>>       return (sem_t *)&the_semaphore->Object.id;
>>>     #endif
>>>   }
>>> +#pragma GCC diagnostic pop
>>
>> Why this brutal and probably non-portable way to suppress warnings?
>>
>> Why doesn't __attribute__((unused)) or similar suffice?
> 
> I would prefer to see something like RTEMS_ATTR_UNUSED to support
> multiple compilers. You can look at my collection of these in
> uLUt definitions file
> 
> http://sourceforge.net/p/ulan/ulut/ci/master/tree/ulut/ul_utdefs.h
> 
> I declare file contents (by this e-mail) as free for public
> domain use (uLUt as whole is is GPL/LGPL/MPL RTEMS compatible too).
> 
> As for the actual __attribute__((unused)) there is even portable
> solution which does not depend on GCC extension.
> 
> {
>   int my_unused_var;
>   (void) my_unused_var;
> }
> 
> This solution should be accepted by all compilers and is suggested
> by some people as better option.
> 
> Best wishes,
> 
>              Pavel
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel
> 



-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985



More information about the devel mailing list