Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #148799 > unrolled thread

Warning in LLVM Clang

Back to article view | Back to comp.lang.c

Contents

  Warning in LLVM Clang Mehdi Amini <atorrses@gmail.com> - 2020-01-06 17:57 +0330
    Warning in LLVM Clang chad <cdalten@gmail.com> - 2020-01-06 07:47 -0800
    Re: Warning in LLVM Clang Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-06 15:58 +0000
      Re: Warning in LLVM Clang Mehdi Amini <atorrses@gmail.com> - 2020-01-07 15:32 +0330
        Which compiler is it, anyway??? (Was: Warning in LLVM Clang) gazelle@shell.xmission.com (Kenny McCormack) - 2020-01-07 12:58 +0000
        Re: Warning in LLVM Clang Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-07 14:33 +0000
          Re: Warning in LLVM Clang Mehdi Amini <atorrses@gmail.com> - 2020-01-08 16:35 +0330
            Re: Warning in LLVM Clang David Brown <david.brown@hesbynett.no> - 2020-01-08 15:11 +0100
              Re: Warning in LLVM Clang Mehdi Amini <atorrses@gmail.com> - 2020-01-09 16:15 +0330
                Re: Warning in LLVM Clang David Brown <david.brown@hesbynett.no> - 2020-01-09 14:34 +0100
                  Re: Warning in LLVM Clang Mehdi Amini <atorrses@gmail.com> - 2020-01-09 17:49 +0330
                    Re: Warning in LLVM Clang Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-01-09 19:35 +0000
                      Re: Warning in LLVM Clang David Brown <david.brown@hesbynett.no> - 2020-01-10 10:28 +0100
                        Re: Warning in LLVM Clang Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-10 12:39 +0000
                          Re: Warning in LLVM Clang Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-01-10 12:57 +0000
                            Re: Warning in LLVM Clang Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-10 13:23 +0000
                          Re: Warning in LLVM Clang David Brown <david.brown@hesbynett.no> - 2020-01-10 14:09 +0100
                            Re: Warning in LLVM Clang Mehdi Amini <atorrses@gmail.com> - 2020-01-10 16:45 +0330
                            Re: Warning in LLVM Clang Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-10 13:20 +0000
                          Re: Warning in LLVM Clang Mehdi Amini <atorrses@gmail.com> - 2020-01-10 17:20 +0330
                            Re: Warning in LLVM Clang Mehdi Amini <atorrses@gmail.com> - 2020-01-10 17:24 +0330
                            Re: Warning in LLVM Clang Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-10 23:52 +0000
                          Re: Warning in LLVM Clang scott@slp53.sl.home (Scott Lurndal) - 2020-01-10 15:29 +0000
                            Re: Warning in LLVM Clang Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-10 23:28 +0000
                      Re: Warning in LLVM Clang Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-01-11 14:21 +0000
                Re: Warning in LLVM Clang James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-09 22:08 -0500
                  Not exactly an "alias", but that's just being a CLC pedant... (Was: Warning in LLVM Clang) gazelle@shell.xmission.com (Kenny McCormack) - 2020-01-10 09:52 +0000
                    Re: Not exactly an "alias", but that's just being a CLC pedant... (Was: Warning in LLVM Clang) David Brown <david.brown@hesbynett.no> - 2020-01-10 11:26 +0100
                  Re: Warning in LLVM Clang Mehdi Amini <atorrses@gmail.com> - 2020-01-10 16:48 +0330
                    Re: Warning in LLVM Clang Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-10 09:34 -0800
                      Re: Warning in LLVM Clang Mehdi Amini <atorrses@gmail.com> - 2020-01-11 14:41 +0330
    Re: Warning in LLVM Clang Guillaume <message@bottle.org> - 2020-01-06 17:23 +0100
      Re: Warning in LLVM Clang Mehdi Amini <atorrses@gmail.com> - 2020-01-07 15:39 +0330

Page 1 of 2  [1] 2  Next page →

#148799 — Warning in LLVM Clang

Hi,

I have set the -w flag for Clang compiler , on one project I still get
about 100 warnings ; why ?

How to make this #pragma work correctly , I get warnings that they are 
correctly known:

#pragma clang diagnostic push
#pragma clang diagnostic warning "-Wall" // -Weverything

// Some function

#pragma clang diagnostic pop

I get:
-Wunknown-pragmas

-- 
www.my-c-codes.com/

Farewell.

[toc] | [next] | [standalone]

#148800

Because you're a dumbass?

[toc] | [prev] | [next] | [standalone]

#148802

Mehdi Amini <atorrses@gmail.com> writes:

> I have set the -w flag for Clang compiler , on one project I still get
> about 100 warnings ; why ?

Something, somewhere, is wrong!  A first step would be to cut down the
code until you get just one or two warnings and post that code along with the
command used for the compilation.

> How to make this #pragma work correctly , I get warnings that they are
> correctly known:
>
> #pragma clang diagnostic push
> #pragma clang diagnostic warning "-Wall" // -Weverything
>
> // Some function
>
> #pragma clang diagnostic pop
>
> I get:
> -Wunknown-pragmas

I can't reproduce this.  It works as expected in a small test case I
just wrote:

  $ cat w.c
  int f(int x) {}
  #pragma clang diagnostic push
  #pragma clang diagnostic warning "-Wall"
  int g(int x) {}
  #pragma clang diagnostic pop
  int h(int x) {}
  $ clang -Wno-all -c w.c
  w.c:4:15: warning: control reaches end of non-void function [-Wreturn-type]
  int g(int x) {}
                ^
  1 warning generated.


Post the code the does not work for you along with the version if clang
that you are using.

  $ clang --version
  clang version 8.0.0-3 (tags/RELEASE_800/final)
  Target: x86_64-pc-linux-gnu
  Thread model: posix
  InstalledDir: /usr/bin

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#148832

On 1/6/20 7:28 PM, Ben Bacarisse wrote:
> Mehdi Amini <atorrses@gmail.com> writes:
> 
>> I have set the -w flag for Clang compiler , on one project I still get
>> about 100 warnings ; why ?
> 
> Something, somewhere, is wrong!  A first step would be to cut down the
> code until you get just one or two warnings and post that code along with the
> command used for the compilation.
> 
>> How to make this #pragma work correctly , I get warnings that they are
>> correctly known:
>>
>> #pragma clang diagnostic push
>> #pragma clang diagnostic warning "-Wall" // -Weverything
>>
>> // Some function
>>
>> #pragma clang diagnostic pop
>>
>> I get:
>> -Wunknown-pragmas
> 
> I can't reproduce this.  It works as expected in a small test case I
> just wrote:
> 
>    $ cat w.c
>    int f(int x) {}
>    #pragma clang diagnostic push
>    #pragma clang diagnostic warning "-Wall"
>    int g(int x) {}
>    #pragma clang diagnostic pop
>    int h(int x) {}
>    $ clang -Wno-all -c w.c
>    w.c:4:15: warning: control reaches end of non-void function [-Wreturn-type]
>    int g(int x) {}
>                  ^
>    1 warning generated.
> 
> 
> Post the code the does not work for you along with the version if clang
> that you are using.
> 
>    $ clang --version
>    clang version 8.0.0-3 (tags/RELEASE_800/final)
>    Target: x86_64-pc-linux-gnu
>    Thread model: posix
>    InstalledDir: /usr/bin
> 

Sorry this is my first major project using a Makefile. It seems to me
that actually GCC is the compiler not Clang. Now how can I disable all
warnings and just show them for a part of code ?

Part of Makefile:

[...]
CC = gcc
CCDEPMODE = depmode=gcc3
CFLAGS =   -Wall -Wno-parentheses
[...]

-- 
www.my-c-codes.com/

Farewell.

[toc] | [prev] | [next] | [standalone]

#148835 — Which compiler is it, anyway??? (Was: Warning in LLVM Clang)

In article <qv1s14$pi0$1@dont-email.me>,
Mehdi Amini  <atorrses@gmail.com> wrote:
...
>Sorry this is my first major project using a Makefile. It seems to me
>that actually GCC is the compiler not Clang. Now how can I disable all
>warnings and just show them for a part of code ?
>
>Part of Makefile:
>
>[...]
>CC = gcc
>CCDEPMODE = depmode=gcc3
>CFLAGS =   -Wall -Wno-parentheses
>[...]

By any chance, are you working on a Mac?

On some systems (notably, the Mac), "gcc" is really "clang".
This is actually convenient, because it means that the large quantity of
existing makefiles that use and/or assume gcc will continue to work.

-- 
I'll give him credit for one thing: He is (& will be) the most quotable President
ever.  Books have been written about (GW) Bushisms, but Dubya's got nothing on Trump.

    Tremendously wet - from the standpoint of water.

[toc] | [prev] | [next] | [standalone]

#148842

Mehdi Amini <atorrses@gmail.com> writes:

> On 1/6/20 7:28 PM, Ben Bacarisse wrote:
<cut>
>> I can't reproduce this.
<cut>
>> Post the code the does not work for you along with the version if clang
>> that you are using.

???

> Sorry this is my first major project using a Makefile. It seems to me
> that actually GCC is the compiler not Clang.

I might be clang none the less because gcc point to clang on a Mac.  I'd
know if you'd posted the version!  Help us to help you.

> Now how can I disable all
> warnings and just show them for a part of code ?

As far as I know, once you've used -w on the command line (as you once
suggested), you can't turn any warnings back on.

> Part of Makefile:
>
> [...]
> CC = gcc
> CCDEPMODE = depmode=gcc3
> CFLAGS =   -Wall -Wno-parentheses
> [...]

You can use -Wno-all and then use a pragma to turn -Wall on for the code
you want.  You could also use -Wno-everything and turn on the warnings
you want later on.  But it might be better to use the pragmas to turn
the warnings off.

However, this reply may be waste of time.  You reported a program with
pragmas that I can't reproduce.  Post code and versions, so we can help.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#148870

On 1/7/20 6:03 PM, Ben Bacarisse wrote:
> Mehdi Amini <atorrses@gmail.com> writes:
> 
>> On 1/6/20 7:28 PM, Ben Bacarisse wrote:

[...]

>>> Post the code the does not work for you along with the version if clang
>>> that you are using.
> 
> ???
> 

[...]

About code I have to say that it a an opensource multi file project. I
am having problem with a GTK+ signal. So it is not simple to send here
just a small code that has the same behavior. On compiler versions:

:~$ clang --version
clang version 6.0.0-1ubuntu2 (tags/RELEASE_600/final)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

:~$ gcc --version
gcc (Ubuntu 7.4.0-1ubuntu1~18.04.1) 7.4.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is
NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.


-- 
www.my-c-codes.com/

Farewell.

[toc] | [prev] | [next] | [standalone]

#148871

On 08/01/2020 14:05, Mehdi Amini wrote:
> On 1/7/20 6:03 PM, Ben Bacarisse wrote:
>> Mehdi Amini <atorrses@gmail.com> writes:
>>
>>> On 1/6/20 7:28 PM, Ben Bacarisse wrote:
> 
> [...]
> 
>>>> Post the code the does not work for you along with the version if clang
>>>> that you are using.
>>
>> ???
>>
> 
> [...]
> 
> About code I have to say that it a an opensource multi file project. I
> am having problem with a GTK+ signal. So it is not simple to send here
> just a small code that has the same behavior. 

It does not matter how big the source is.  What you have to do is figure
out a minimal, stand-alone, compilable snippet of code that demonstrates
the problem.  It does not have to be an extraction from the original
code - usually it is better to write a new test "foo" function that has
the same effect.  This process has at least three major benefits:

1. It means other people can help you, because they can see a short bit
of code.  No one is going to wade through dozens of long source files on
github (or whatever) to help, but many are happy to read through a dozen
lines of code in a Usenet post.

2. During the process of making such a sample, there is a good chance
that you will figure it out yourself, and learn something in the
process.  This happens often.

3. You can paste the code into <https://godbolt.org> and test it out
with different compilers, different versions, different warning settings
and flag options.  This can be a big help for you in finding out what is
going on.



> On compiler versions:
> 
> :~$ clang --version
> clang version 6.0.0-1ubuntu2 (tags/RELEASE_600/final)
> Target: x86_64-pc-linux-gnu
> Thread model: posix
> InstalledDir: /usr/bin
> 
> :~$ gcc --version
> gcc (Ubuntu 7.4.0-1ubuntu1~18.04.1) 7.4.0
> Copyright (C) 2017 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is
> NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
> PURPOSE.
> 
> 

[toc] | [prev] | [next] | [standalone]

#148877

On 1/8/20 5:41 PM, David Brown wrote:
> On 08/01/2020 14:05, Mehdi Amini wrote:
>> On 1/7/20 6:03 PM, Ben Bacarisse wrote:
>>> Mehdi Amini <atorrses@gmail.com> writes:
>>>
>>>> On 1/6/20 7:28 PM, Ben Bacarisse wrote:
>>

[...]

> It does not matter how big the source is.  What you have to do is figure
> out a minimal, stand-alone, compilable snippet of code that demonstrates
> the problem.  It does not have to be an extraction from the original
> code - usually it is better to write a new test "foo" function that has
> the same effect.  This process has at least three major benefits:
> 
> 1. It means other people can help you, because they can see a short bit
> of code.  No one is going to wade through dozens of long source files on
> github (or whatever) to help, but many are happy to read through a dozen
> lines of code in a Usenet post.
> 
> 2. During the process of making such a sample, there is a good chance
> that you will figure it out yourself, and learn something in the
> process.  This happens often.
> 
> 3. You can paste the code into <https://godbolt.org> and test it out
> with different compilers, different versions, different warning settings
> and flag options.  This can be a big help for you in finding out what is
> going on.
> 
> 
> 
>> On compiler versions:
>>
>> :~$ clang --version
>> clang version 6.0.0-1ubuntu2 (tags/RELEASE_600/final)
>> Target: x86_64-pc-linux-gnu
>> Thread model: posix
>> InstalledDir: /usr/bin
>>
>> :~$ gcc --version
>> gcc (Ubuntu 7.4.0-1ubuntu1~18.04.1) 7.4.0
>> Copyright (C) 2017 Free Software Foundation, Inc.
>> This is free software; see the source for copying conditions.  There is
>> NO
>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
>> PURPOSE.
>>

OK , here is my try on this link:

https://www.tutorialspoint.com/compile_c_online.php

Code:
// pragma problem
#include <stdlib.h>

#pragma clang diagnostic push
#pragma clang diagnostic warning "-Wall" // -Weverything
int main(void)
{
     //exit(1);
     return 0;
}
#pragma clang diagnostic pop

Result:
$gcc -o main *.c -Wall -Wno-parentheses
main.c:4:0: warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas]
  #pragma clang diagnostic push

main.c:5:0: warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas]
  #pragma clang diagnostic warning "-Wall" // -Weverything

main.c:11:0: warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas]
  #pragma clang diagnostic pop

$main


-- 
www.my-c-codes.com/

Farewell.

[toc] | [prev] | [next] | [standalone]

#148878

On 09/01/2020 13:45, Mehdi Amini wrote:
> On 1/8/20 5:41 PM, David Brown wrote:
>> On 08/01/2020 14:05, Mehdi Amini wrote:
>>> On 1/7/20 6:03 PM, Ben Bacarisse wrote:
>>>> Mehdi Amini <atorrses@gmail.com> writes:
>>>>
>>>>> On 1/6/20 7:28 PM, Ben Bacarisse wrote:
>>>
> 
> [...]
> 
>> It does not matter how big the source is.  What you have to do is figure
>> out a minimal, stand-alone, compilable snippet of code that demonstrates
>> the problem.  It does not have to be an extraction from the original
>> code - usually it is better to write a new test "foo" function that has
>> the same effect.  This process has at least three major benefits:
>>
>> 1. It means other people can help you, because they can see a short bit
>> of code.  No one is going to wade through dozens of long source files on
>> github (or whatever) to help, but many are happy to read through a dozen
>> lines of code in a Usenet post.
>>
>> 2. During the process of making such a sample, there is a good chance
>> that you will figure it out yourself, and learn something in the
>> process.  This happens often.
>>
>> 3. You can paste the code into <https://godbolt.org> and test it out
>> with different compilers, different versions, different warning settings
>> and flag options.  This can be a big help for you in finding out what is
>> going on.
>>
>>
>>
>>> On compiler versions:
>>>
>>> :~$ clang --version
>>> clang version 6.0.0-1ubuntu2 (tags/RELEASE_600/final)
>>> Target: x86_64-pc-linux-gnu
>>> Thread model: posix
>>> InstalledDir: /usr/bin
>>>
>>> :~$ gcc --version
>>> gcc (Ubuntu 7.4.0-1ubuntu1~18.04.1) 7.4.0
>>> Copyright (C) 2017 Free Software Foundation, Inc.
>>> This is free software; see the source for copying conditions.  There is
>>> NO
>>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
>>> PURPOSE.
>>>
> 
> OK , here is my try on this link:
> 
> https://www.tutorialspoint.com/compile_c_online.php
> 
> Code:
> // pragma problem
> #include <stdlib.h>
> 
> #pragma clang diagnostic push
> #pragma clang diagnostic warning "-Wall" // -Weverything
> int main(void)
> {
>     //exit(1);
>     return 0;
> }
> #pragma clang diagnostic pop
> 
> Result:
> $gcc -o main *.c -Wall -Wno-parentheses
> main.c:4:0: warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas]
>  #pragma clang diagnostic push
> 
> main.c:5:0: warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas]
>  #pragma clang diagnostic warning "-Wall" // -Weverything
> 
> main.c:11:0: warning: ignoring #pragma clang diagnostic [-Wunknown-pragmas]
>  #pragma clang diagnostic pop
> 
> $main
> 
> 

You are using clang-specific pragmas, then compiling with gcc with the
warning for unknown pragmas enabled.  The compiler is giving you the
warning you asked for.

Your choices include:

1. Disable the "unknown pragma" warning (gcc -Wall -Wno-unknown-pragmas).

2. Compile with clang.

3. Change the clang-specific pragmas to gcc-specific equivalents:

	#pragma GCC diagnostic warning "-Wall"

(clang might happily accept that too - it accepts a fair number of
gcc-specific extensions.)

4. Use conditional compilation testing compiler type, and give
appropriate pragmas for different compilers.

5. Drop the pragma entirely, and put the flags in the builder (makefile,
cmake, or whatever).

[toc] | [prev] | [next] | [standalone]

#148879

On 1/9/20 5:04 PM, David Brown wrote:
> On 09/01/2020 13:45, Mehdi Amini wrote:
>> On 1/8/20 5:41 PM, David Brown wrote:
>>> On 08/01/2020 14:05, Mehdi Amini wrote:
>>>> On 1/7/20 6:03 PM, Ben Bacarisse wrote:
>>>>> Mehdi Amini <atorrses@gmail.com> writes:
>>>>>
>>>>>> On 1/6/20 7:28 PM, Ben Bacarisse wrote:

[...]

> 
> You are using clang-specific pragmas, then compiling with gcc with the
> warning for unknown pragmas enabled.  The compiler is giving you the
> warning you asked for.
> 
> Your choices include:
> 
> 1. Disable the "unknown pragma" warning (gcc -Wall -Wno-unknown-pragmas).
> 
> 2. Compile with clang.
> 
> 3. Change the clang-specific pragmas to gcc-specific equivalents:
> 
> 	#pragma GCC diagnostic warning "-Wall"
> 
> (clang might happily accept that too - it accepts a fair number of
> gcc-specific extensions.)
> 
> 4. Use conditional compilation testing compiler type, and give
> appropriate pragmas for different compilers.
> 
> 5. Drop the pragma entirely, and put the flags in the builder (makefile,
> cmake, or whatever).
> 
> 

Can I change the Makefile as I originally intended , that is , is it
safe to change these :

CC = gcc
CCDEPMODE = depmode=gcc3
CFLAGS =   -Wall -Wno-parentheses

to

CC = gcc
CCDEPMODE = depmode=gcc3
CFLAGS =

Then enable warnings on a specific part of code with what you said ? or 
even other warnings like -Wextra ?

#pragma GCC diagnostic warning "-Wall"

-- 
www.my-c-codes.com/

Farewell.

[toc] | [prev] | [next] | [standalone]

#148887

On Thu, 2020-01-09, Mehdi Amini wrote:
> On 1/9/20 5:04 PM, David Brown wrote:
>> On 09/01/2020 13:45, Mehdi Amini wrote:
>>> On 1/8/20 5:41 PM, David Brown wrote:
>>>> On 08/01/2020 14:05, Mehdi Amini wrote:
>>>>> On 1/7/20 6:03 PM, Ben Bacarisse wrote:
>>>>>> Mehdi Amini <atorrses@gmail.com> writes:
>>>>>>
>>>>>>> On 1/6/20 7:28 PM, Ben Bacarisse wrote:
>
> [...]
>
>> 
>> You are using clang-specific pragmas, then compiling with gcc with the
>> warning for unknown pragmas enabled.  The compiler is giving you the
>> warning you asked for.
>> 
>> Your choices include:
>> 
>> 1. Disable the "unknown pragma" warning (gcc -Wall -Wno-unknown-pragmas).
>> 
>> 2. Compile with clang.
>> 
>> 3. Change the clang-specific pragmas to gcc-specific equivalents:
>> 
>> 	#pragma GCC diagnostic warning "-Wall"
>> 
>> (clang might happily accept that too - it accepts a fair number of
>> gcc-specific extensions.)
>> 
>> 4. Use conditional compilation testing compiler type, and give
>> appropriate pragmas for different compilers.
>> 
>> 5. Drop the pragma entirely, and put the flags in the builder (makefile,
>> cmake, or whatever).

I think here David just commented on your example, which did not show
your original problem. It just showed you mixing clang pragmas and
the gcc compiler.

> Can I change the Makefile as I originally intended , that is , is it
> safe to change these :
>
> CC = gcc
> CCDEPMODE = depmode=gcc3
> CFLAGS =   -Wall -Wno-parentheses
>
> to
>
> CC = gcc
> CCDEPMODE = depmode=gcc3
> CFLAGS =
>
> Then enable warnings on a specific part of code with what you said ? or 
> even other warnings like -Wextra ?
>
> #pragma GCC diagnostic warning "-Wall"

I strongly recommend enabling maximum warnings in the Makefile (in
CFLAGS), and if it's really necessary, disabling warnings for certain
files, also in the Makefile:

  my_weird_file.o: CFLAGS+=-Wno-parentheses

But I don't understand why you can't just live with the warnings, or
fix the code.

Another Make thing: CC is the standard name for the C compiler and
CFLAGS is the standard name for the C compiler options (together with
CPPFLAGS).  But CCDEPMODE has, as far as I can tell, no special
meaning in Make.

Lastly, your CFLAGS should also specify what C dialect you want,
optimization and debugging options.  I tend to use:

  CFLAGS=-Wall -Wextra -pedantic -std=c99 -g -O2

but then I sometimes have to soften it up for individual files,
e.g. those which expect to find POSIX-specific declarations in
standard headers, or which use language extensions.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#148895

On 09/01/2020 20:35, Jorgen Grahn wrote:
> On Thu, 2020-01-09, Mehdi Amini wrote:
>> On 1/9/20 5:04 PM, David Brown wrote:
>>> On 09/01/2020 13:45, Mehdi Amini wrote:
>>>> On 1/8/20 5:41 PM, David Brown wrote:
>>>>> On 08/01/2020 14:05, Mehdi Amini wrote:
>>>>>> On 1/7/20 6:03 PM, Ben Bacarisse wrote:
>>>>>>> Mehdi Amini <atorrses@gmail.com> writes:
>>>>>>>
>>>>>>>> On 1/6/20 7:28 PM, Ben Bacarisse wrote:
>>
>> [...]
>>
>>>
>>> You are using clang-specific pragmas, then compiling with gcc with the
>>> warning for unknown pragmas enabled.  The compiler is giving you the
>>> warning you asked for.
>>>
>>> Your choices include:
>>>
>>> 1. Disable the "unknown pragma" warning (gcc -Wall -Wno-unknown-pragmas).
>>>
>>> 2. Compile with clang.
>>>
>>> 3. Change the clang-specific pragmas to gcc-specific equivalents:
>>>
>>> 	#pragma GCC diagnostic warning "-Wall"
>>>
>>> (clang might happily accept that too - it accepts a fair number of
>>> gcc-specific extensions.)
>>>
>>> 4. Use conditional compilation testing compiler type, and give
>>> appropriate pragmas for different compilers.
>>>
>>> 5. Drop the pragma entirely, and put the flags in the builder (makefile,
>>> cmake, or whatever).
> 
> I think here David just commented on your example, which did not show
> your original problem. It just showed you mixing clang pragmas and
> the gcc compiler.

Yes, exactly.  There isn't enough information in the original post -
that's why we need a small example.  If that doesn't show the original
problem, then a new small example is needed.

> 
>> Can I change the Makefile as I originally intended , that is , is it
>> safe to change these :
>>
>> CC = gcc
>> CCDEPMODE = depmode=gcc3
>> CFLAGS =   -Wall -Wno-parentheses
>>
>> to
>>
>> CC = gcc
>> CCDEPMODE = depmode=gcc3
>> CFLAGS =
>>
>> Then enable warnings on a specific part of code with what you said ? or 
>> even other warnings like -Wextra ?
>>
>> #pragma GCC diagnostic warning "-Wall"
> 
> I strongly recommend enabling maximum warnings in the Makefile (in
> CFLAGS), and if it's really necessary, disabling warnings for certain
> files, also in the Makefile:
> 
>   my_weird_file.o: CFLAGS+=-Wno-parentheses
> 
> But I don't understand why you can't just live with the warnings, or
> fix the code.

I'd say "fix the code", rather than living with the warnings.  Warnings
are given for a reason - they indicate that the code might have
problems.  They are not a guarantee that there is a problem, and in some
cases it is merely stylistic differences, which is why you then want to
disable warnings that conflict with your coding style.  But I am a
strong believer that your code is not finished if there are /any/
warnings generated with your build process.

> 
> Another Make thing: CC is the standard name for the C compiler and
> CFLAGS is the standard name for the C compiler options (together with
> CPPFLAGS).  But CCDEPMODE has, as far as I can tell, no special
> meaning in Make.
> 
> Lastly, your CFLAGS should also specify what C dialect you want,
> optimization and debugging options.  I tend to use:
> 
>   CFLAGS=-Wall -Wextra -pedantic -std=c99 -g -O2

Agreed - that is a good habit.

> 
> but then I sometimes have to soften it up for individual files,
> e.g. those which expect to find POSIX-specific declarations in
> standard headers, or which use language extensions.
> 
> /Jorgen
> 

[toc] | [prev] | [next] | [standalone]

#148898

David Brown <david.brown@hesbynett.no> writes:
<cut>
> I'd say "fix the code", rather than living with the warnings.

In this case, I'm not sure that's the right approach.  If I recall
correctly the code is old and stable (some X-Windows program or other)
so leaving it well alone might be the safest option.

<cut>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#148899

On Fri, 2020-01-10, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
> <cut>
>> I'd say "fix the code", rather than living with the warnings.
>
> In this case, I'm not sure that's the right approach.  If I recall
> correctly the code is old and stable (some X-Windows program or other)
> so leaving it well alone might be the safest option.

Either the thread is confused or I've been a sloppy reader, or both.

If certain source files are written in an old C dialect, I'd change
CFLAGS (warning options, but primarily -std=FOO) for those files.
Not just enable or disable -Wall.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#148905

Jorgen Grahn <grahn+nntp@snipabacken.se> writes:

> On Fri, 2020-01-10, Ben Bacarisse wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>> <cut>
>>> I'd say "fix the code", rather than living with the warnings.
>>
>> In this case, I'm not sure that's the right approach.  If I recall
>> correctly the code is old and stable (some X-Windows program or other)
>> so leaving it well alone might be the safest option.
>
> Either the thread is confused or I've been a sloppy reader, or both.
>
> If certain source files are written in an old C dialect, I'd change
> CFLAGS (warning options, but primarily -std=FOO) for those files.
> Not just enable or disable -Wall.

That might be a good idea as well, but modern compilers give lots of
warnings for old code, even if the right -std argument is used.

For some as yet unexplained reason (the story is coming out in drips),
the OP is adding new code to old source files and wants good warnings
for the new code.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#148901

On 10/01/2020 13:39, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
> <cut>
>> I'd say "fix the code", rather than living with the warnings.
> 
> In this case, I'm not sure that's the right approach.  If I recall
> correctly the code is old and stable (some X-Windows program or other)
> so leaving it well alone might be the safest option.
> 

To be more nuanced, I should say "fix the code if you can reasonably do
so".  If you can't - such as when you don't want to change the code
unless it is unavoidable - then compiler flags in the build system would
be the next option.  I'd still go for that option before the "live with
the warnings" option, but of course it's possible that you can't change
the build scripts either.

However, this code seems to be involving clang pragmas - that does not
sound like an old X program to me.

[toc] | [prev] | [next] | [standalone]

#148902

On 1/10/20 4:39 PM, David Brown wrote:
> On 10/01/2020 13:39, Ben Bacarisse wrote:
>> David Brown <david.brown@hesbynett.no> writes:

[...]

> However, this code seems to be involving clang pragmas - that does not
> sound like an old X program to me.

Well , I thought clang is the compiler since it is default compiler for 
my IDE (Code::Blocks). But I remembered that I am building from a custom 
Makefile. It seems to me that GCC is the compiler.


-- 
www.my-c-codes.com/

Farewell.

[toc] | [prev] | [next] | [standalone]

#148904

David Brown <david.brown@hesbynett.no> writes:

> On 10/01/2020 13:39, Ben Bacarisse wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>> <cut>
>>> I'd say "fix the code", rather than living with the warnings.
>> 
>> In this case, I'm not sure that's the right approach.  If I recall
>> correctly the code is old and stable (some X-Windows program or other)
>> so leaving it well alone might be the safest option.
>> 
>
> To be more nuanced, I should say "fix the code if you can reasonably do
> so".  If you can't - such as when you don't want to change the code
> unless it is unavoidable - then compiler flags in the build system would
> be the next option.  I'd still go for that option before the "live with
> the warnings" option, but of course it's possible that you can't change
> the build scripts either.
>
> However, this code seems to be involving clang pragmas - that does not
> sound like an old X program to me.

The OP is adding them to get the variable warning behaviour being
discussed.  I've seen no evidence they were there before, but there have
been rather few details posted.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#148906

On 1/10/20 4:09 PM, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
> <cut>
>> I'd say "fix the code", rather than living with the warnings.
> 
> In this case, I'm not sure that's the right approach.  If I recall
> correctly the code is old and stable (some X-Windows program or other)
> so leaving it well alone might be the safest option.
> 
> <cut>
> 

Code is a chess GUI which is open-source here available:

https://www.gnu.org/prep/ftp.html

Select a mirror from the list , choose "xboard" package. For now latest
version is 4.9.1 .

I remember compiling/installing it was not easy job though.

Now some typical warnings from original code:

Code1:
if(gameNr < 0 || appData.tourneyType < 1 ||  // gauntlet engine can 
always stay loaded as first engine

Warns1:
   CC       backend.o
backend.c: In function ‘ReserveGame’:
backend.c:1538:7: warning: this ‘if’ clause does not guard... 
[-Wmisleading-indentation]
        if(gameNr < 0 || appData.tourneyType < 1 ||  // gauntlet engine 
can always stay loaded as first engine
        ^~

Code2:
   { "x", ArgInt, (void *) &wpMain.x, TRUE, (ArgIniType) CW_USEDEFAULT },
Warns2:
./args.h:791:44: warning: cast to pointer from integer of different size 
[-Wint-to-pointer-cast]
    { "x", ArgInt, (void *) &wpMain.x, TRUE, (ArgIniType) CW_USEDEFAULT },
                                             ^
Can I fix such warnings ?

-- 
www.my-c-codes.com/

Farewell.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c

csiph-web