If I have:

enum colour {RED, GREEN, BLUE}

int colour_to_hex(enum colour colour)
{
switch (colour)
{
RED: return 0xff0000;
GREEN: return 0x00ff00;
// BLUE: return 0x0000ff;
}

...
}

... then the compiler will warn me that I've missed a case in the switch statement. Which is good and very helpful.

But if I do:

int hex = colour_to_hex(10);

... then the compiler doesn't complain that 10 is not in the enum.

Why? Surely the compiler can tell.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Richard Harnden <richard.nospam@gmail.invalid> wrote or quoted:

int hex = colour_to_hex(10);
... then the compiler doesn't complain that 10 is not in the enum.
Why? Surely the compiler can tell.

I get

|
|error: enum conversion when passing argument 1 of 'colour_to_hex' is invalid in C++ [-Wc++-compat]
| |int hex = colour_to_hex(10);
| | ^~
|note: expected 'enum colour' but argument is of type 'int'
| | int colour_to_hex(enum colour colour)
| | ^~~~~~~~~~~~~
|

with

gcc -Wc++-compat

.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

ram@zedat.fu-berlin.de (Stefan Ram) writes:

Richard Harnden <richard.nospam@gmail.invalid> wrote or quoted:

int hex = colour_to_hex(10);
... then the compiler doesn't complain that 10 is not in the enum.
Why? Surely the compiler can tell.

I get

|
|error: enum conversion when passing argument 1 of 'colour_to_hex' is invalid in C++ [-Wc++-compat]
| |int hex = colour_to_hex(10);
| | ^~
|note: expected 'enum colour' but argument is of type 'int'
| | int colour_to_hex(enum colour colour)
| | ^~~~~~~~~~~~~
|

with

gcc -Wc++-compat

That example exemplifies the seriously screwed up error reporting in the
gnu compiler collection.

One line of informative error message followed by 5 lines of useless
cruft to wade through. And no way to turn it off completely.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 05/04/2025 13:26, Stefan Ram wrote:

Richard Harnden <richard.nospam@gmail.invalid> wrote or quoted:

int hex = colour_to_hex(10);
... then the compiler doesn't complain that 10 is not in the enum.
Why? Surely the compiler can tell.

I get

|
|error: enum conversion when passing argument 1 of 'colour_to_hex' is invalid in C++ [-Wc++-compat]
| |int hex = colour_to_hex(10);
| | ^~
|note: expected 'enum colour' but argument is of type 'int'
| | int colour_to_hex(enum colour colour)
| | ^~~~~~~~~~~~~
|

with

gcc -Wc++-compat

Yes. In C++, the enumeration constants are of the enumeration type,
while in C they are "int".


It would be nice if gcc had a warning for this kind of thing (for those
that choose to enable it).

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

ram@zedat.fu-berlin.de (Stefan Ram) wrote or quoted:

int hex = colour_to_hex(10);

However,

|colour_to_hex((enum colour)10)

compiles as C under the above option without warnings,
while compiling it as C++ one gets:

|warning: The value '10' provided to the cast expression is not in the valid range of values for 'colour' [clang-analyzer-optin.core.EnumCastOutOfRange]

|warning: the result of the conversion is unspecified because '10' is outside the range of type 'colour' [-Wconversion]

.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 05/04/2025 17:53, Thiago Adams wrote:

Em 4/5/2025 7:29 AM, Richard Harnden escreveu:

If I have:

enum colour {RED, GREEN, BLUE}

int colour_to_hex(enum colour colour)
{
     switch (colour)
     {
         RED: return 0xff0000;
         GREEN: return 0x00ff00;
         // BLUE: return 0x0000ff;
     }

     ...
}

... then the compiler will warn me that I've missed a case in the
switch statement.  Which is good and very helpful.

But if I do:

int hex = colour_to_hex(10);

... then the compiler doesn't complain that 10 is not in the enum.

Why? Surely the compiler can tell.

Sometimes enums are used as bit set.

f(BIT1 | BIT2)

this situation would generate a lot of warning because BIT1|BIT2 is not
part of the enum, just BIT1 and BIT2 separately.

One way that this could be fixed is adding an attribute

[[bitset]]
enum E{ BIT1 = 2, BIT2 = 4};

Then the compiler would not generate a warning in this case.

gcc has the "flag_enum" attribute precisely for this purpose.
Standardising it in the C standards would be nice, but the C standard
does not currently have much that is merely about improving compiler
warnings.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

scott@slp53.sl.home (Scott Lurndal) writes:

ram@zedat.fu-berlin.de (Stefan Ram) writes:

Richard Harnden <richard.nospam@gmail.invalid> wrote or quoted:

int hex = colour_to_hex(10);
... then the compiler doesn't complain that 10 is not in the enum.
Why? Surely the compiler can tell.

I get

|
|error: enum conversion when passing argument 1 of 'colour_to_hex' is
invalid in C++ [-Wc++-compat]
| |int hex = colour_to_hex(10);
| | ^~
|note: expected 'enum colour' but argument is of type 'int'
| | int colour_to_hex(enum colour colour)
| | ^~~~~~~~~~~~~
|

with

gcc -Wc++-compat

That example exemplifies the seriously screwed up error reporting in the
gnu compiler collection.

One line of informative error message followed by 5 lines of useless
cruft to wade through. And no way to turn it off completely.

That's true, but it can be reduced to only two lines total (so only one
line more than needed), by using -fno-diagnostics-show-caret.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

scott@slp53.sl.home (Scott Lurndal) writes:

ram@zedat.fu-berlin.de (Stefan Ram) writes:

Richard Harnden <richard.nospam@gmail.invalid> wrote or quoted:

int hex = colour_to_hex(10);
... then the compiler doesn't complain that 10 is not in the enum.
Why? Surely the compiler can tell.

I get

|
|error: enum conversion when passing argument 1 of 'colour_to_hex' is
invalid in C++ [-Wc++-compat]
| |int hex = colour_to_hex(10);
| | ^~
|note: expected 'enum colour' but argument is of type 'int'
| | int colour_to_hex(enum colour colour)
| | ^~~~~~~~~~~~~
|

with

gcc -Wc++-compat

That example exemplifies the seriously screwed up error reporting in the
gnu compiler collection.

One line of informative error message followed by 5 lines of useless
cruft to wade through. And no way to turn it off completely.

That's true, but it can be reduced to only two lines total (so only one
line more than needed), by using -fno-diagnostics-show-caret.

Yes, I use that. I still find that the "note:" lines clutter the
output and provide zero benefit.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 06/04/2025 16:47, Scott Lurndal wrote:

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

scott@slp53.sl.home (Scott Lurndal) writes:

ram@zedat.fu-berlin.de (Stefan Ram) writes:

Richard Harnden <richard.nospam@gmail.invalid> wrote or quoted:

int hex = colour_to_hex(10);
... then the compiler doesn't complain that 10 is not in the enum.
Why? Surely the compiler can tell.

I get

|
|error: enum conversion when passing argument 1 of 'colour_to_hex' is
invalid in C++ [-Wc++-compat]
| |int hex = colour_to_hex(10);
| | ^~
|note: expected 'enum colour' but argument is of type 'int'
| | int colour_to_hex(enum colour colour)
| | ^~~~~~~~~~~~~
|

with

gcc -Wc++-compat

That example exemplifies the seriously screwed up error reporting in the >>> gnu compiler collection.

One line of informative error message followed by 5 lines of useless
cruft to wade through. And no way to turn it off completely.

That's true, but it can be reduced to only two lines total (so only one
line more than needed), by using -fno-diagnostics-show-caret.

Yes, I use that. I still find that the "note:" lines clutter the
output and provide zero benefit.

Sometimes you can immediately spot the cause of an error - you've made a
typo and all you need is a vague indication that there is a mistake
somewhere in that area. Other times the cause can be quite subtle,
especially in C++, and the extra information can be of great help. Unfortunately, it's impossible for the compiler to tell which situation
you are in.

I'm sure you are aware of the "-fdiagnostic" options for fine-tuning the appearance of error messages - I have no idea if they can be used to
trim them down to something that suits you.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

scott@slp53.sl.home (Scott Lurndal) writes:

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

scott@slp53.sl.home (Scott Lurndal) writes:

[... gcc verbose error messages ...]

One line of informative error message followed by 5 lines of
useless cruft to wade through. And no way to turn it off
completely.

That's true, but it can be reduced to only two lines total (so
only one line more than needed), by using
-fno-diagnostics-show-caret.

Yes, I use that. I still find that the "note:" lines clutter the
output and provide zero benefit.

I sympathize with your reaction. My response was meant only to
provide information to anyone not aware of it.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

scott@slp53.sl.home (Scott Lurndal) writes:

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

scott@slp53.sl.home (Scott Lurndal) writes:

ram@zedat.fu-berlin.de (Stefan Ram) writes:

Richard Harnden <richard.nospam@gmail.invalid> wrote or quoted:

int hex = colour_to_hex(10);
... then the compiler doesn't complain that 10 is not in the enum.
Why? Surely the compiler can tell.

I get

|
|error: enum conversion when passing argument 1 of 'colour_to_hex' is
invalid in C++ [-Wc++-compat]
| |int hex = colour_to_hex(10);
| | ^~
|note: expected 'enum colour' but argument is of type 'int'
| | int colour_to_hex(enum colour colour)
| | ^~~~~~~~~~~~~
|

with

gcc -Wc++-compat

That example exemplifies the seriously screwed up error reporting in the >>> gnu compiler collection.

One line of informative error message followed by 5 lines of useless
cruft to wade through. And no way to turn it off completely.

That's true, but it can be reduced to only two lines total (so only one >>line more than needed), by using -fno-diagnostics-show-caret.

Yes, I use that. I still find that the "note:" lines clutter the
output and provide zero benefit.

Does

gcc -fcompare-debug-second -fno-diagnostics-show-caret

do what you want? The behaviour seems to be a side effect of some
internal debug options so it probably can't be relied upon long-term.

--
Ben.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Ben Bacarisse <ben@bsb.me.uk> writes:

scott@slp53.sl.home (Scott Lurndal) writes:

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

scott@slp53.sl.home (Scott Lurndal) writes:

ram@zedat.fu-berlin.de (Stefan Ram) writes:

Richard Harnden <richard.nospam@gmail.invalid> wrote or quoted:

int hex = colour_to_hex(10);
... then the compiler doesn't complain that 10 is not in the enum. >>>>>> Why? Surely the compiler can tell.

I get

|
|error: enum conversion when passing argument 1 of 'colour_to_hex' is >>>>> invalid in C++ [-Wc++-compat]
| |int hex = colour_to_hex(10);
| | ^~
|note: expected 'enum colour' but argument is of type 'int'
| | int colour_to_hex(enum colour colour)
| | ^~~~~~~~~~~~~
|

with

gcc -Wc++-compat

That example exemplifies the seriously screwed up error reporting in the >>>> gnu compiler collection.

One line of informative error message followed by 5 lines of useless
cruft to wade through. And no way to turn it off completely.

That's true, but it can be reduced to only two lines total (so only one >>>line more than needed), by using -fno-diagnostics-show-caret.

Yes, I use that. I still find that the "note:" lines clutter the
output and provide zero benefit.

Does

gcc -fcompare-debug-second -fno-diagnostics-show-caret

We use the latter. It doesn't get rid of the 'note' sections, however.

For some reason, -fcompare-debug-second is commented out in our Makefile, but it appears that only applies in when a second compile is required.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

scott@slp53.sl.home (Scott Lurndal) writes:

Ben Bacarisse <ben@bsb.me.uk> writes:

scott@slp53.sl.home (Scott Lurndal) writes:

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

...

That's true, but it can be reduced to only two lines total (so only one >>>>line more than needed), by using -fno-diagnostics-show-caret.

Yes, I use that. I still find that the "note:" lines clutter the
output and provide zero benefit.

Does

gcc -fcompare-debug-second -fno-diagnostics-show-caret

We use the latter. It doesn't get rid of the 'note' sections, however.

For some reason, -fcompare-debug-second is commented out in our Makefile, but it appears that only applies in when a second compile is required.

It appears to have a second "side-effect" use. It removes notes when I
use it.

--
Ben.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Ben Bacarisse <ben@bsb.me.uk> writes:

scott@slp53.sl.home (Scott Lurndal) writes:

Ben Bacarisse <ben@bsb.me.uk> writes:

scott@slp53.sl.home (Scott Lurndal) writes:

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:

...

That's true, but it can be reduced to only two lines total (so
only one line more than needed), by using
-fno-diagnostics-show-caret.

Yes, I use that. I still find that the "note:" lines clutter the
output and provide zero benefit.

Does

gcc -fcompare-debug-second -fno-diagnostics-show-caret

We use the latter. It doesn't get rid of the 'note' sections,
however.

For some reason, -fcompare-debug-second is commented out in our
Makefile, but it appears that only applies in when a second compile
is required.

It appears to have a second "side-effect" use. It removes notes
when I use it.

Nice to know. Thank you for posting it.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)