[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