Question on GCC 4.6 and -fpermissive

Question on GCC 4.6 and -fpermissive

[Jeffrey Walton]

Hi Guys,

I'm running a table drive test suite. The tables are about 250K each,
and there are 7 of them. Each row in the table looks similar to the
following (this particular row is consumed by a 'short'):

    { 0x0001, 0x0001, <some bool> };

Without '-fpermissive' the code would not compile'. With
'-fpermissive', the code compiles but produces a warning for each line
encountered:

    AdditionVerify.cpp:68:1: warning: narrowing conversion of ‘65535’
        from ‘int’ to ‘short int’ inside { } [-fpermissive]

GCC's 4.6 docs do not appear to have a [no]warning switch for
permissive [1] (the docs for the switches don't even mention the word
'permissive'). Taking a stab in the dark, my current CXXFLAGS looks is
below, which has not helped.

    CXXFLAGS += -std=c++0x -fpermissive -Wno-permissive \
        -Wno-narrow -Wno-narrowing -Wno-narrow-conversion
        -Wno-narrowing-conversion -Wno-coversion

Any ideas on how to hush the compiler for for this warning. I'm
concerned it the volume of output might be masking more relevant
warnings.

Jeff

[1] http://gcc.gnu.org/onlinedocs/gcc-4.6.1/gcc/Warning-Options.html#Warning-Options

Re: Question on GCC 4.6 and -fpermissive

[Jonathan Wakely]

On 10 August 2011 09:22, Jeffrey Walton wrote:
> Hi Guys,
>
> I'm running a table drive test suite. The tables are about 250K each,
> and there are 7 of them. Each row in the table looks similar to the
> following (this particular row is consumed by a 'short'):
>
>    { 0x0001, 0x0001, <some bool> };
>
> Without '-fpermissive' the code would not compile'.

Why?  You might want to fix that.  -fpermissive is a band-aid to work
around broken code, for backwards compatibility.  You should aim to
wean yourself off it. You shouldn't write new code that relies on it.

> With
> '-fpermissive', the code compiles but produces a warning for each line
> encountered:
>
>    AdditionVerify.cpp:68:1: warning: narrowing conversion of ‘65535’
>        from ‘int’ to ‘short int’ inside { } [-fpermissive]
>
> GCC's 4.6 docs do not appear to have a [no]warning switch for
> permissive [1] (the docs for the switches don't even mention the word
> 'permissive').

It's listed in the options summary:
http://gcc.gnu.org/onlinedocs/gcc/Option-Summary.html
and here:
http://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Dialect-Options.html

It's not a warning option, it alters the C++ language that's
supported, to allow non-standard constructs and things that were
"traditionally" allowed (either by pre-standard C++ compilers or by
earlier versions of G++)

If you don't want -fpermissive then don't use it.

> Taking a stab in the dark, my current CXXFLAGS looks is
> below, which has not helped.
>
>    CXXFLAGS += -std=c++0x -fpermissive -Wno-permissive \
>        -Wno-narrow -Wno-narrowing -Wno-narrow-conversion
>        -Wno-narrowing-conversion -Wno-coversion

Well no, clearly just making up options isn't going to help.

> Any ideas on how to hush the compiler for for this warning. I'm
> concerned it the volume of output might be masking more relevant
> warnings.

If you don't want warnings about narrowing then use -Wno-narrow, which
works for me.  If it doesn't work for you please provide a *working*
example, not pseudocode or one that doesn't actually demonstrate your
point.

Re: Question on GCC 4.6 and -fpermissive

[Jeffrey Walton]

On Wed, Aug 10, 2011 at 5:32 AM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> On 10 August 2011 09:22, Jeffrey Walton wrote:
>> Hi Guys,
>>
>> I'm running a table drive test suite. The tables are about 250K each,
>> and there are 7 of them. Each row in the table looks similar to the
>> following (this particular row is consumed by a 'short'):
>>
>>    { 0x0001, 0x0001, <some bool> };
>>
>> Without '-fpermissive' the code would not compile'.
>
> Why?  You might want to fix that.  -fpermissive is a band-aid to work
> around broken code, for backwards compatibility.  You should aim to
> wean yourself off it. You shouldn't write new code that relies on it.
Agreed. Its old code, and the thought of performing casts on values in
tables with files as large as 250K takes the wind out of me.

Fortunately, its code from the test cases, and not used in production.

>> With
>> '-fpermissive', the code compiles but produces a warning for each line
>> encountered:
>>
>>    AdditionVerify.cpp:68:1: warning: narrowing conversion of ‘65535’
>>        from ‘int’ to ‘short int’ inside { } [-fpermissive]
>>
>> GCC's 4.6 docs do not appear to have a [no]warning switch for
>> permissive [1] (the docs for the switches don't even mention the word
>> 'permissive').
>
> It's listed in the options summary:
> http://gcc.gnu.org/onlinedocs/gcc/Option-Summary.html
> and here:
> http://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Dialect-Options.html
Right. I found the flag under the 4.6.1 dialect docs.

> It's not a warning option, it alters the C++ language that's
> supported, to allow non-standard constructs and things that were
> "traditionally" allowed (either by pre-standard C++ compilers or by
> earlier versions of G++)
>
> If you don't want -fpermissive then don't use it.
I think I prefer -fpermissive in this particular case. Its going to
take a while to track down the 1700 or so offensive values.

>> Taking a stab in the dark, my current CXXFLAGS looks is
>> below, which has not helped.
>>
>>    CXXFLAGS += -std=c++0x -fpermissive -Wno-permissive \
>>        -Wno-narrow -Wno-narrowing -Wno-narrow-conversion
>>        -Wno-narrowing-conversion -Wno-coversion
>
> Well no, clearly just making up options isn't going to help.
:) Fortunately, GCC consumes unknown options.

In the absence of [clear] documentation that states what to do, I try
to use creativity while searching for the answer.

>> Any ideas on how to hush the compiler for for this warning. I'm
>> concerned it the volume of output might be masking more relevant
>> warnings.
>
> If you don't want warnings about narrowing then use -Wno-narrow, which
> works for me.
OK.  -Wno-narrow did not [completely?] work for me on Fedora 15 and
GCC 4.6. I say completely because there are 1734 warnings from GCC.

Driver program:
http://code.google.com/p/owasp-esapi-cplusplus/source/browse/trunk/deps/safeint/tests/TestMain.cpp
Sample table: http://code.google.com/p/owasp-esapi-cplusplus/source/browse/trunk/deps/safeint/tests/AddVerify.cpp

The makefile for the test program is located in the same folder
(deps/safeint/tests) and not root:
http://code.google.com/p/owasp-esapi-cplusplus/source/browse/trunk/deps/safeint/tests/GNUmakefile

> If it doesn't work for you please provide a *working*
> example, not pseudocode or one that doesn't actually demonstrate your
> point.
Agreed. The last example was poor. My apologies.

Jeff

[jeffrey@fedora15 ~]$ gcc --version
gcc (GCC) 4.6.0 20110603 (Red Hat 4.6.0-10)
Copyright (C) 2011 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.

[jeffrey@fedora15 tests]$ make 2> make.txt
g++ -DNDEBUG=1 -g -O2 -DSAFEINT_DISALLOW_UNSIGNED_NEGATION=1 -pipe
-Wall -Wextra -Wno-type-limits -Wno-unused -std=c++0x -fpermissive
-Wno-narrow -I../. TestMain.cpp IncDecVerify.cpp AddVerify.cpp
SubVerify.cpp MultVerify.cpp DivVerify.cpp ModVerify.cpp
UnaryVerify.cpp PtrVerify.cpp -o TestMain.exe
./TestMain.exe
...
[jeffrey@fedora15 tests]$ cat make.txt | head -1
IncDecVerify.cpp:427:1: warning: narrowing conversion of ‘128’ from
‘int’ to ‘char’ inside { } [-fpermissive]
[jeffrey@fedora15 tests]$ cat make.txt | wc -l
1734

Re: Question on GCC 4.6 and -fpermissive

[Jonathan Wakely]

On 10 August 2011 12:02, Jeffrey Walton wrote:
> On Wed, Aug 10, 2011 at 5:32 AM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>> On 10 August 2011 09:22, Jeffrey Walton wrote:
>>> Hi Guys,
>>>
>>> I'm running a table drive test suite. The tables are about 250K each,
>>> and there are 7 of them. Each row in the table looks similar to the
>>> following (this particular row is consumed by a 'short'):
>>>
>>>    { 0x0001, 0x0001, <some bool> };
>>>
>>> Without '-fpermissive' the code would not compile'.
>>
>> Why?  You might want to fix that.  -fpermissive is a band-aid to work
>> around broken code, for backwards compatibility.  You should aim to
>> wean yourself off it. You shouldn't write new code that relies on it.
> Agreed. Its old code, and the thought of performing casts on values in
> tables with files as large as 250K takes the wind out of me.
>
> Fortunately, its code from the test cases, and not used in production.
>
>>> With
>>> '-fpermissive', the code compiles but produces a warning for each line
>>> encountered:
>>>
>>>    AdditionVerify.cpp:68:1: warning: narrowing conversion of ‘65535’
>>>        from ‘int’ to ‘short int’ inside { } [-fpermissive]
>>>
>>> GCC's 4.6 docs do not appear to have a [no]warning switch for
>>> permissive [1] (the docs for the switches don't even mention the word
>>> 'permissive').
>>
>> It's listed in the options summary:
>> http://gcc.gnu.org/onlinedocs/gcc/Option-Summary.html
>> and here:
>> http://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Dialect-Options.html
> Right. I found the flag under the 4.6.1 dialect docs.
>
>> It's not a warning option, it alters the C++ language that's
>> supported, to allow non-standard constructs and things that were
>> "traditionally" allowed (either by pre-standard C++ compilers or by
>> earlier versions of G++)
>>
>> If you don't want -fpermissive then don't use it.
> I think I prefer -fpermissive in this particular case. Its going to
> take a while to track down the 1700 or so offensive values.
>
>>> Taking a stab in the dark, my current CXXFLAGS looks is
>>> below, which has not helped.
>>>
>>>    CXXFLAGS += -std=c++0x -fpermissive -Wno-permissive \
>>>        -Wno-narrow -Wno-narrowing -Wno-narrow-conversion
>>>        -Wno-narrowing-conversion -Wno-coversion
>>
>> Well no, clearly just making up options isn't going to help.
> :) Fortunately, GCC consumes unknown options.
>
> In the absence of [clear] documentation that states what to do, I try
> to use creativity while searching for the answer.
>
>>> Any ideas on how to hush the compiler for for this warning. I'm
>>> concerned it the volume of output might be masking more relevant
>>> warnings.
>>
>> If you don't want warnings about narrowing then use -Wno-narrow, which
>> works for me.
> OK.  -Wno-narrow did not [completely?] work for me on Fedora 15 and
> GCC 4.6. I say completely because there are 1734 warnings from GCC.
>
> Driver program:
> http://code.google.com/p/owasp-esapi-cplusplus/source/browse/trunk/deps/safeint/tests/TestMain.cpp
> Sample table: http://code.google.com/p/owasp-esapi-cplusplus/source/browse/trunk/deps/safeint/tests/AddVerify.cpp
>
> The makefile for the test program is located in the same folder
> (deps/safeint/tests) and not root:
> http://code.google.com/p/owasp-esapi-cplusplus/source/browse/trunk/deps/safeint/tests/GNUmakefile
>
>> If it doesn't work for you please provide a *working*
>> example, not pseudocode or one that doesn't actually demonstrate your
>> point.
> Agreed. The last example was poor. My apologies.
>
> Jeff
>
> [jeffrey@fedora15 ~]$ gcc --version
> gcc (GCC) 4.6.0 20110603 (Red Hat 4.6.0-10)
> Copyright (C) 2011 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.
>
> [jeffrey@fedora15 tests]$ make 2> make.txt
> g++ -DNDEBUG=1 -g -O2 -DSAFEINT_DISALLOW_UNSIGNED_NEGATION=1 -pipe
> -Wall -Wextra -Wno-type-limits -Wno-unused -std=c++0x -fpermissive
> -Wno-narrow -I../. TestMain.cpp IncDecVerify.cpp AddVerify.cpp
> SubVerify.cpp MultVerify.cpp DivVerify.cpp ModVerify.cpp
> UnaryVerify.cpp PtrVerify.cpp -o TestMain.exe
> ./TestMain.exe
> ...
> [jeffrey@fedora15 tests]$ cat make.txt | head -1
> IncDecVerify.cpp:427:1: warning: narrowing conversion of ‘128’ from
> ‘int’ to ‘char’ inside { } [-fpermissive]
> [jeffrey@fedora15 tests]$ cat make.txt | wc -l
> 1734

The combination of -std=c++0x and -fpermissive is an odd one.  "I want
to us C++0x features, but I want to accept crufty old pre-C++98 code".
 That's probably always going to cause some issues, and it isn't
likely to be a priority for anyone to do anything about that.

Re: Question on GCC 4.6 and -fpermissive

[Jonathan Wakely]

On 10 August 2011 10:32, Jonathan Wakely wrote:
>
> If you don't want warnings about narrowing then use -Wno-narrow, which
> works for me.

That should have been -Wno-narrowing, which might be new in 4.7

Re: Question on GCC 4.6 and -fpermissive

[Jeffrey Walton]

On Wed, Aug 10, 2011 at 7:19 AM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> On 10 August 2011 12:02, Jeffrey Walton wrote:
>> On Wed, Aug 10, 2011 at 5:32 AM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>>> On 10 August 2011 09:22, Jeffrey Walton wrote:
>>>> Hi Guys,
>>>>
>>>> I'm running a table drive test suite. The tables are about 250K each,
>>>> and there are 7 of them. Each row in the table looks similar to the
>>>> following (this particular row is consumed by a 'short'):
>>>> [SNIP]
>>
>> [jeffrey@fedora15 ~]$ gcc --version
>> gcc (GCC) 4.6.0 20110603 (Red Hat 4.6.0-10)
>> Copyright (C) 2011 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.
>>
>> [jeffrey@fedora15 tests]$ make 2> make.txt
>> g++ -DNDEBUG=1 -g -O2 -DSAFEINT_DISALLOW_UNSIGNED_NEGATION=1 -pipe
>> -Wall -Wextra -Wno-type-limits -Wno-unused -std=c++0x -fpermissive
>> -Wno-narrow -I../. TestMain.cpp IncDecVerify.cpp AddVerify.cpp
>> SubVerify.cpp MultVerify.cpp DivVerify.cpp ModVerify.cpp
>> UnaryVerify.cpp PtrVerify.cpp -o TestMain.exe
>> ./TestMain.exe
>> ...
>> [jeffrey@fedora15 tests]$ cat make.txt | head -1
>> IncDecVerify.cpp:427:1: warning: narrowing conversion of ‘128’ from
>> ‘int’ to ‘char’ inside { } [-fpermissive]
>> [jeffrey@fedora15 tests]$ cat make.txt | wc -l
>> 1734
>
> The combination of -std=c++0x and -fpermissive is an odd one.  "I want
> to use C++0x features, but I want to accept crufty old pre-C++98 code".
>  That's probably always going to cause some issues, and it isn't
> likely to be a priority for anyone to do anything about that.
Ideally, the code would compile cleanly under -std=c++0x. The need for
-fpermissive caught me off guard, but I don't have your knowledge of
C++. For now, I can live without a cast in the tables. I'm still
interested in seeing the non-narrowing warnings in case there's
something else that can be fixed.

For what its worth, if I had your understanding of GCC and the C++
language, I probably would not need -Wall, -Wextra, and the handful of
other warnings.

Jeff

Re: Question on GCC 4.6 and -fpermissive

[Jeffrey Walton]

On Wed, Aug 10, 2011 at 7:22 AM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> On 10 August 2011 10:32, Jonathan Wakely wrote:
>>
>> If you don't want warnings about narrowing then use -Wno-narrow, which
>> works for me.
>
> That should have been -Wno-narrowing, which might be new in 4.7
OK, thanks.

This might be useful if the language allows it. Rather than issuing 18
separate warnings on the following - which would require 18 casts:

static const IncTest< __int8 > inc_int8[] =
{
       { 0x00, 0x01, true},
       { 0x01,0x02, true},
       { 0x02, 0x03, true},
       { 0x7e, 0x7f, true},
       { 0x7f, 0x80, false},
       { 0x80, 0x81, true},
       { 0x81, 0x82, true},
       { 0xfe, 0xff, true},
       { 0xff, 0x00, true},
};

Require us to perform the first cast, and then {accept|imply} the type
on the remainder since we specified the type on the first element:

static const IncTest< __int8 > inc_int8[] =
{
       { (__int8)0x00, (__int8)0x01, true},
       { 0x01,0x02, true},
       { 0x02, 0x03, true},
       { 0x7e, 0x7f, true},
       { 0x7f, 0x80, false},
       { 0x80, 0x81, true},
       { 0x81, 0x82, true},
       { 0xfe, 0xff, true},
       { 0xff, 0x00, true},
};

Jeff

Re: Question on GCC 4.6 and -fpermissive

[Jonathan Wakely]

On 10 August 2011 13:12, Jeffrey Walton wrote:
> On Wed, Aug 10, 2011 at 7:22 AM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>> On 10 August 2011 10:32, Jonathan Wakely wrote:
>>>
>>> If you don't want warnings about narrowing then use -Wno-narrow, which
>>> works for me.
>>
>> That should have been -Wno-narrowing, which might be new in 4.7
> OK, thanks.
>
> This might be useful if the language allows it. Rather than issuing 18
> separate warnings on the following - which would require 18 casts:
>
> static const IncTest< __int8 > inc_int8[] =
> {
>       { 0x00, 0x01, true},
>       { 0x01,0x02, true},
>       { 0x02, 0x03, true},
>       { 0x7e, 0x7f, true},
>       { 0x7f, 0x80, false},
>       { 0x80, 0x81, true},
>       { 0x81, 0x82, true},
>       { 0xfe, 0xff, true},
>       { 0xff, 0x00, true},
> };

It doesn't issue 18 warnings, it issues 8, for the narrowing
conversions.  There's no problem converting the constants 0x00 or 0x01
to a char.

> Require us to perform the first cast, and then {accept|imply} the type
> on the remainder since we specified the type on the first element:
>
> static const IncTest< __int8 > inc_int8[] =
> {
>       { (__int8)0x00, (__int8)0x01, true},
>       { 0x01,0x02, true},
>       { 0x02, 0x03, true},
>       { 0x7e, 0x7f, true},
>       { 0x7f, 0x80, false},
>       { 0x80, 0x81, true},
>       { 0x81, 0x82, true},
>       { 0xfe, 0xff, true},
>       { 0xff, 0x00, true},
> };

That would not be conforming. Neither is -Wno-narrowing for that
matter, C++11 says there are 8 errors in that code.