Juergen, I think whis warning is neither about compiler nor c standard.
It is about programmers' convention to use enum type to hold limited set
of values. Using enum for integer is not tricking the compiler, but
tricking other programmers who follow this convention (or even the self).
Most compilers warn if you retreat 'informal' programming rules, because
in most cases this lead to erroneous code.
Formally you do not need to follow this, of course.
On Sat, 19 Apr 2014 14:37:53 +0200
Juergen Sauermann <address@hidden> wrote:
Hi Peter,
I have changed it in SVN 215.
I still disagree with the warning because in a comparison of an
enumeration member
with an integer should perform integer promotion of the enum member to
int and then do
integer comparison and NOT convert the int to an enum member (which it
can't) and then
do the comparison (or issue the warning).
In other words, I read "l < 10" as "(int)l < 10" (which can be true or
false) and not as "l < (Function_line)10"
which can also be true or false because if I allow implicit
(Function_line)10 then I cannot rule out (Function_line)42
either.
The really interesting question is if the compiler would optimize "if (i
< 10)" away which I would consider a fault
in the compiler. As a warning it is just a bit annoying because it
forces "default: ;" all over the place.
/// Jürgen
On 04/19/2014 02:36 AM, Peter Teeson wrote:
Hi Jürgen:
I've been thinking again about this warning and I'm inclined to agree
with it.
..MyProjects/GNUAPL/apl-svn/src/UserFunction.cc:1191:10: Comparison of
constant 10 with expression of type 'Function_Line' is always true
if (l < 10) ucs.append(UNI_ASCII_SPACE);
These suggestions eliminate the Warning.
In File APL_Types.hh
enum Function_Line
{
Function_Retry = -2, // →'' in immediate execution
Function_Line_0 = 0,
Function_Line_1 = 1,
Function_Line_MAX = 10 // << === My suggestion
};
In UserFunction.cc:1191:10:
if (l < Function_Line_MAX) ucs.append(UNI_ASCII_SPACE); // << === My
suggestion