On 12/15/2017 03:17 AM, Tim Rühsen wrote:
>>> >>> # define NOWARN_PUSH(a) \ >>> _Pragma( STRINGIFY( clang
diagnostic push ) ) \ >>> _Pragma( STRINGIFY( clang diagnostic ignored a
) )
I would rather not clutter the code with calls to macros like these, as
such calls detract from ordinary
On 12/15/2017 12:54 PM, Gisle Vanem wrote:
> Tim Rühsen wrote:
>
>> Attached is a quick commit with a new lib/pragmas.h. Sorry, I currently
>> don't have time for anything more (e.g. a module).
>
> These are nice. MSVC also has the '__pragma()' keyword
> documented here:
>
Tim Rühsen wrote:
Attached is a quick commit with a new lib/pragmas.h. Sorry, I currently
don't have time for anything more (e.g. a module).
These are nice. MSVC also has the '__pragma()' keyword
documented here:
https://msdn.microsoft.com/en-us/library/d9x1s805.aspx
But that would need a
On 12/15/2017 10:49 AM, Bruno Haible wrote:
> Tim Rühsen wrote:
>> It works, but... ;-)
>
> OK, I've pushed it.
>
>> Your patch disables that warning for the whole file. IMO, we should keep
>> the scope of the #pragma as narrow as possible.
>>
>> We could have a pragma.h include file with the
Tim Rühsen wrote:
> It works, but... ;-)
OK, I've pushed it.
> Your patch disables that warning for the whole file. IMO, we should keep
> the scope of the #pragma as narrow as possible.
>
> We could have a pragma.h include file with the following C99 code (I
> leave the clang and gcc version
Hi Bruno,
On 12/15/2017 12:40 AM, Bruno Haible wrote:
>>> 1) It is not a goal to have absolutely no warnings with GCC or
>>>with clang. It is perfectly OK, IMO, if a compilation with "gcc -Wall"
>>>shows, say, 5 warnings in 10 files. The maintainer will get used to
>>>these warnings
> #if defined __clang__
> # define NOWARN(a) _Pragma( STRINGIFY( clang diagnostic ignored a ) )
> # define NOWARN_PUSH(a) \
> _Pragma( STRINGIFY( clang diagnostic push ) ) \
> _Pragma( STRINGIFY( clang diagnostic ignored a ) )
> # define NOWARN_POP _Pragma( STRINGIFY( gcc diagnostic pop ) )
On 12/15/2017 12:28 AM, Bruno Haible wrote:
Hi Bruno,
>>> Or through an in-file pragma that specifically documents that we are
>>> intentionally ignoring the warning.
>>
>> I vote for this.
>
> Does this patch eliminate the warning?
>
> I couldn't reproduce the issue with clang 3.9.1 on Linux,
Hi Tim,
> > 1) It is not a goal to have absolutely no warnings with GCC or
> >with clang. It is perfectly OK, IMO, if a compilation with "gcc -Wall"
> >shows, say, 5 warnings in 10 files. The maintainer will get used to
> >these warnings and see new warnings when they arise.
>
> That
Hi Tim,
> > Or through an in-file pragma that specifically documents that we are
> > intentionally ignoring the warning.
>
> I vote for this.
Does this patch eliminate the warning?
I couldn't reproduce the issue with clang 3.9.1 on Linux, therefore I have
to ask you to test it.
Bruno
diff
On 12/13/2017 11:24 PM, Bruno Haible wrote:
> Hi Tim,
>
>> clang's warning:
>>
>> spawn-pipe.c:364:34: warning: variable 'child' may be uninitialized when
>> used here [-Wconditional-uninitialized]
>> register_slave_subprocess (child);
>> ^
>
> I agree
On 12/13/2017 11:29 PM, Eric Blake wrote:
> On 12/13/2017 04:24 PM, Bruno Haible wrote:
>
>> Is '-Wconditional-uninitialized' implied in -Wall? If yes, I vote for
>> adding '-Wno-conditional-uninitialized' at least for this specific file
>> (through a Makefile.am variable).
>
> Or through an
On 12/13/2017 04:24 PM, Bruno Haible wrote:
> 1) It is not a goal to have absolutely no warnings with GCC or
>with clang. It is perfectly OK, IMO, if a compilation with "gcc -Wall"
>shows, say, 5 warnings in 10 files. The maintainer will get used to
>these warnings and see new
Hi Tim,
> clang's warning:
>
> spawn-pipe.c:364:34: warning: variable 'child' may be uninitialized when
> used here [-Wconditional-uninitialized]
> register_slave_subprocess (child);
> ^
I agree with your analysis that without massive inlining or other
This seems to be a false positive from clang - but how does a compiler
know for sure that a function (posix_spawnp) always initializes a
pointer argument when returning 0 ? Ok, it's written in the docs and we
know it but there is no syntax to tell the compiler exactly that.
That's why I vote for
15 matches
Mail list logo
