Prohibit enum <-> int mixup

Prohibit enum <-> int mixup

[Enrico Weigelt]

Hi folks,


is there a way to let the compiler prohibit mixing up enums and
ints ? (eg. no assignments between enums and ints, no numeric
operations on enums, etc).

That would be a great help to me in a current refactoring process.


cu
-- 
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weigelt@metux.de
 mobile: +49 151 27565287  icq:   210169427         skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------

Re: Prohibit enum <-> int mixup

[Ian Lance Taylor]

Enrico Weigelt <weigelt@metux.de> writes:

> is there a way to let the compiler prohibit mixing up enums and
> ints ? (eg. no assignments between enums and ints, no numeric
> operations on enums, etc).

I assume you are talking about C.  Try -Wc++-compat.  However, that will
warn about a number of things other than enum comparisons.  There is no
option to pull out the specific enum checks from the rest of the C++
compatibility checks.

Ian

Re: Prohibit enum <-> int mixup

[Enrico Weigelt]

* Ian Lance Taylor <iant@google.com> wrote:
> Enrico Weigelt <weigelt@metux.de> writes:
> 
> > is there a way to let the compiler prohibit mixing up enums and
> > ints ? (eg. no assignments between enums and ints, no numeric
> > operations on enums, etc).
> 
> I assume you are talking about C.  Try -Wc++-compat.  However, that will
> warn about a number of things other than enum comparisons.  There is no
> option to pull out the specific enum checks from the rest of the C++
> compatibility checks.

I'm using C++. It already warns me about a few things, eg. missing
case's in switch statements. But it still accepts assigning 
enum to int and vice versa.


cu
-- 
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weigelt@metux.de
 mobile: +49 151 27565287  icq:   210169427         skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------

Re: Prohibit enum <-> int mixup

[Jonathan Wakely]

On 29 January 2011 20:48, Enrico Weigelt wrote:
>
> I'm using C++. It already warns me about a few things, eg. missing
> case's in switch statements. But it still accepts assigning
> enum to int and vice versa.

No it doesn't, C++ allows enums to be assigned to ints but not the
other way around.

enum e { val };
e var = 0;

e.cc:2: error: invalid conversion from ‘int’ to ‘e’

Re: Prohibit enum <-> int mixup

[Jonathan Wakely]

On 29 January 2011 22:33, Jonathan Wakely wrote:
> On 29 January 2011 20:48, Enrico Weigelt wrote:
>>
>> I'm using C++. It already warns me about a few things, eg. missing
>> case's in switch statements. But it still accepts assigning
>> enum to int and vice versa.
>
> No it doesn't, C++ allows enums to be assigned to ints but not the
> other way around.
>
> enum e { val };
> e var = 0;
>
> e.cc:2: error: invalid conversion from ‘int’ to ‘e’

Technically what is allowed is implicit conversion from enum to int.
In C++0x you can define a scoped enum which doesn't allow the
conversion.

Re: Prohibit enum <-> int mixup

[Enrico Weigelt]

* Enrico Weigelt <weigelt@metux.de> wrote:

> > I assume you are talking about C.  Try -Wc++-compat.  However, that will
> > warn about a number of things other than enum comparisons.  There is no
> > option to pull out the specific enum checks from the rest of the C++
> > compatibility checks.
> 
> I'm using C++. It already warns me about a few things, eg. missing
> case's in switch statements. But it still accepts assigning 
> enum to int and vice versa.

Just had a little test w/ zlib:
It doesn't compile out of the box, but the fixes seem to be
quite simple (eg. function parameter declarations).


cu
-- 
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weigelt@metux.de
 mobile: +49 151 27565287  icq:   210169427         skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------

Re: Prohibit enum <-> int mixup

[Enrico Weigelt]

* Jonathan Wakely <jwakely.gcc@gmail.com> wrote:

> Technically what is allowed is implicit conversion from enum to int.
> In C++0x you can define a scoped enum which doesn't allow the
> conversion.

How exactly is this done ?


cu
-- 
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weigelt@metux.de
 mobile: +49 151 27565287  icq:   210169427         skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------

Re: Prohibit enum <-> int mixup

[Jonathan Wakely]

On 30 January 2011 20:11, Enrico Weigelt wrote:
> * Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>
>> Technically what is allowed is implicit conversion from enum to int.
>> In C++0x you can define a scoped enum which doesn't allow the
>> conversion.
>
> How exactly is this done ?

enum class foo { bar };

foo f = foo::bar;

int i = foo::bar;  // error, no conversion

Re: Prohibit enum <-> int mixup

[Enrico Weigelt]

* Enrico Weigelt <weigelt@metux.de> wrote:

<snip>

To make it more clear what I'm trying to do:


The current codebase uses enums eg. for declaring several options
(eg. selectable values or choosable actions in some GUI). The
application often is contigiously adapted for each job/project.

For example, the supported languages of are configured in the
source like that:

enum LANGUAGES 
{
    LANGUAGE_NONE	= 0,
    
    LANGUAGE_GERMAN,
    LANGUAGE_ENGLISH,
    LANGUAGE_FRENCH,
    
    LANGUAGE_MAX,

    LANGUAGE_ITALIAN
    ...
};

The funny thing: LANGUAGE_MAX tells the maximum of supported
languages in the current configuration (when some change, they
get reordered above or under the LANGUAGE_MAX), and several
places iterate or check for the range of 
LANGUAGE_NONE < x < LANGUAGE_MAX.

Even worse: sometimes numeric values are used instead of the
enum values, which will cause a hell of trouble when the enums
change. (eg. for return codes, etc).

Obviously this is crappy, and I'd like to clean that up step
by step. We have *lots* of such stuff lying around anywhere
in the app.

If I could tell the compiler to simply forbid such mixups,
that would be *great* help for identifying such places.


cu
-- 
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weigelt@metux.de
 mobile: +49 151 27565287  icq:   210169427         skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------

Re: Prohibit enum <-> int mixup

[Enrico Weigelt]

* Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> On 30 January 2011 20:11, Enrico Weigelt wrote:
> > * Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> >
> >> Technically what is allowed is implicit conversion from enum to int.
> >> In C++0x you can define a scoped enum which doesn't allow the
> >> conversion.
> >
> > How exactly is this done ?
> 
> enum class foo { bar };
> 
> foo f = foo::bar;
> 
> int i = foo::bar;  // error, no conversion

Ah, looks promising: it also refuses < and > operators, exactly
what I'm looking for :)

I'll have to add --std=c++0x parameter - does that have any other
side effects I should be aware of ?


cu
-- 
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 phone:  +49 36207 519931  email: weigelt@metux.de
 mobile: +49 151 27565287  icq:   210169427         skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------

Re: Prohibit enum <-> int mixup

[Jonathan Wakely]

On 30 January 2011 20:32, Enrico Weigelt wrote:
>
> I'll have to add --std=c++0x parameter - does that have any other
> side effects I should be aware of ?

-std=c++0x enables lots of things, but if you don't use e.g. variadic
templates or the decltype keyword you shouldn't notice.  The only
thing I can think of affecting valid code is changing the meaning of
the 'auto' keyword, which noone sensible uses anyway.

Re: Prohibit enum <-> int mixup

[Kevin P. Fleming]

On 01/30/2011 02:54 PM, Jonathan Wakely wrote:
> On 30 January 2011 20:32, Enrico Weigelt wrote:
>>
>> I'll have to add --std=c++0x parameter - does that have any other
>> side effects I should be aware of ?
>
> -std=c++0x enables lots of things, but if you don't use e.g. variadic
> templates or the decltype keyword you shouldn't notice.  The only
> thing I can think of affecting valid code is changing the meaning of
> the 'auto' keyword, which noone sensible uses anyway.

It can result in a number of deprecation warnings, though, and if you 
have -Werror enabled that could be problematic for you. Our project 
includes a bunch of headers from a large third-party library that 
trigger these warnings, but telling g++ that they are 'system headers' 
makes it stop converting them to errors when -Werror is in use, so we've 
been able to work around it.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: kfleming@digium.com
Check us out at www.digium.com & www.asterisk.org

Re: Prohibit enum <-> int mixup

[Ian Lance Taylor]

Jonathan Wakely <jwakely.gcc@gmail.com> writes:

> On 30 January 2011 20:32, Enrico Weigelt wrote:
>>
>> I'll have to add --std=c++0x parameter - does that have any other
>> side effects I should be aware of ?
>
> -std=c++0x enables lots of things, but if you don't use e.g. variadic
> templates or the decltype keyword you shouldn't notice.  The only
> thing I can think of affecting valid code is changing the meaning of
> the 'auto' keyword, which noone sensible uses anyway.

Using -std=c++0x will cause libstdc++ to build in C++0x mode, which last
time I checked was not strictly ABI compatible with libstdc++ not built
in C++0x mode.  So if you link with a dynamic libstdc++.so, you may get
in trouble in some complex scenarios.

Ian

Re: Prohibit enum <-> int mixup

[Kevin P. Fleming]

On 01/31/2011 01:16 PM, Ian Lance Taylor wrote:
> Jonathan Wakely<jwakely.gcc@gmail.com>  writes:
>
>> On 30 January 2011 20:32, Enrico Weigelt wrote:
>>>
>>> I'll have to add --std=c++0x parameter - does that have any other
>>> side effects I should be aware of ?
>>
>> -std=c++0x enables lots of things, but if you don't use e.g. variadic
>> templates or the decltype keyword you shouldn't notice.  The only
>> thing I can think of affecting valid code is changing the meaning of
>> the 'auto' keyword, which noone sensible uses anyway.
>
> Using -std=c++0x will cause libstdc++ to build in C++0x mode, which last
> time I checked was not strictly ABI compatible with libstdc++ not built
> in C++0x mode.  So if you link with a dynamic libstdc++.so, you may get
> in trouble in some complex scenarios.

I don't think the OP was asking about building GCC itself using 
--std=c++0x, just his programs. In that situation, presumably his 
libstdc++ was built by his distro and has the 'standard' ABI, right?

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: kfleming@digium.com
Check us out at www.digium.com & www.asterisk.org

Re: Prohibit enum <-> int mixup

[Jonathan Wakely]

On 31 January 2011 19:16, Ian Lance Taylor wrote:
>
> Using -std=c++0x will cause libstdc++ to build in C++0x mode, which last
> time I checked was not strictly ABI compatible with libstdc++ not built
> in C++0x mode.  So if you link with a dynamic libstdc++.so, you may get
> in trouble in some complex scenarios.

Do you remember the details?  I thought we'd done a good job of not
breaking the ABI, and have avoided making some changes required by
C+0x because they change the ABI.  I'd like to document the potential
problems if you can remember where the incompatibilities are.

Re: Prohibit enum <-> int mixup

[Jonathan Wakely]

On 31 January 2011 23:56, Ian Lance Taylor wrote:
> Jonathan Wakely <jwakely.gcc@gmail.com> writes:
>
>> On 31 January 2011 19:16, Ian Lance Taylor wrote:
>>>
>>> Using -std=c++0x will cause libstdc++ to build in C++0x mode, which last
>>> time I checked was not strictly ABI compatible with libstdc++ not built
>>> in C++0x mode.  So if you link with a dynamic libstdc++.so, you may get
>>> in trouble in some complex scenarios.
>>
>> Do you remember the details?  I thought we'd done a good job of not
>> breaking the ABI, and have avoided making some changes required by
>> C+0x because they change the ABI.  I'd like to document the potential
>> problems if you can remember where the incompatibilities are.
>
> http://gcc.gnu.org/PR45093

Aha, thanks

Re: Prohibit enum <-> int mixup

[Kevin P. Fleming]

On 01/31/2011 05:56 PM, Ian Lance Taylor wrote:
> Jonathan Wakely<jwakely.gcc@gmail.com>  writes:
>
>> On 31 January 2011 19:16, Ian Lance Taylor wrote:
>>>
>>> Using -std=c++0x will cause libstdc++ to build in C++0x mode, which last
>>> time I checked was not strictly ABI compatible with libstdc++ not built
>>> in C++0x mode.  So if you link with a dynamic libstdc++.so, you may get
>>> in trouble in some complex scenarios.
>>
>> Do you remember the details?  I thought we'd done a good job of not
>> breaking the ABI, and have avoided making some changes required by
>> C+0x because they change the ABI.  I'd like to document the potential
>> problems if you can remember where the incompatibilities are.
>
> http://gcc.gnu.org/PR45093

Well... based on Paolo's reply, that's quite concerning. Does this mean 
that distros need to provide two compiled versions of libstdc++ and the 
compiler wrapper will need to select the proper one to link against 
based on whether --std=c++0x was used or not? This could have major 
ripple effects as well, as various other C++ libraries (Boost, etc) will 
have to be compiled in both modes as well.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: kfleming@digium.com
Check us out at www.digium.com & www.asterisk.org

Re: Prohibit enum <-> int mixup

[Ian Lance Taylor]

"Kevin P. Fleming" <kpfleming@digium.com> writes:

> I don't think the OP was asking about building GCC itself using
> --std=c++0x, just his programs. In that situation, presumably his
> libstdc++ was built by his distro and has the 'standard' ABI, right?

Yes, and that's the problem.  For those cases where his program expects
to use the library, it may (in some obscure cases) use the wrong ABI.

Ian

Re: Prohibit enum <-> int mixup

[Ian Lance Taylor]

"Kevin P. Fleming" <kpfleming@digium.com> writes:

> Well... based on Paolo's reply, that's quite concerning. Does this
> mean that distros need to provide two compiled versions of libstdc++
> and the compiler wrapper will need to select the proper one to link
> against based on whether --std=c++0x was used or not? This could have
> major ripple effects as well, as various other C++ libraries (Boost,
> etc) will have to be compiled in both modes as well.

Yes, I think there is a serious issue here.  There are various forces
pushing toward breaking the libstdc++ ABI.  I do not know what the
libstdc++ maintainer's plans are.

Ian

Re: Prohibit enum <-> int mixup

[Kevin P. Fleming]

On 02/01/2011 01:43 PM, Ian Lance Taylor wrote:
> "Kevin P. Fleming"<kpfleming@digium.com>  writes:
>
>> Well... based on Paolo's reply, that's quite concerning. Does this
>> mean that distros need to provide two compiled versions of libstdc++
>> and the compiler wrapper will need to select the proper one to link
>> against based on whether --std=c++0x was used or not? This could have
>> major ripple effects as well, as various other C++ libraries (Boost,
>> etc) will have to be compiled in both modes as well.
>
> Yes, I think there is a serious issue here.  There are various forces
> pushing toward breaking the libstdc++ ABI.  I do not know what the
> libstdc++ maintainer's plans are.

I guess I was more concerned about having to have two versions of the 
library installed for the *same* compiler than about having ABI breakage 
at all. Obviously the latter is not ideal either, but it seems like it 
would be manageable. The former just sounds like a nightmare waiting in 
the wings :-)

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: kfleming@digium.com
Check us out at www.digium.com & www.asterisk.org