[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Devel] Code cleanup (Re: Pure C)
From: |
David Turner |
Subject: |
[Devel] Code cleanup (Re: Pure C) |
Date: |
Tue, 19 Jun 2001 17:34:08 +0200 |
Hello all,
I've performed a major code cleanup yesterday, in order to get rid
of extremely pedantic (lint-style) compiler warnings that I was having with
Visual C++ (using /W4) and Borland C++.
This should also reduce the warnings encounted by Wolfgang with its TOS
compiler. I have inspected the following:
- the "variable is assigned a value that is never used" warnings
should be ignored. There are still a lot of them, but they only
relate to two cases that I consider legal:
- when defining the default value of a variable, like in:
FT_Error error = 0;
and that the variable is assigned a new value a few
lines later. Generally speaking, I prefer to keep
the default value here as a safeguard, in case the
code below the variable declaration is changed.
- when using the FT_UNUSED(x) macro, to specify an unused
parameter. These should be simply ignored..
- the "invalid conversion of 'int' to 'short'" and other shorter integer
types
was mainly due to:
- the fact that the FT_Bool type is defined as FT_Byte, when it
should really be FT_Int. This will not be changed for binary
compatibility reasons. Instead, I introduced a new macro named
FT_BOOL(x) to explicitely cast 'x' to a FT_Bool
- the use of "short" or "char" structure fields, and their
processing. For example, the following code will create a
warning:
struct { short x; } var1;
short var2;
{
var2 = 10;
var1.x += var2;
}
because "var1.x += var2" is equivalent to "var1.x = var1.x + var2"
where the result of the '+' is automatically promoted to an "int"
- other places where the automatic promotion to "int" was causing
some warnings. For example:
FT_Byte mask = 0x80;
FT_Byte val;
val = mask >> 3; /* warning, "mask >> 3" is an "int" */
All these have been removed
- the "condition is constant" warning was not removed, since it is used
a lot with conditional compilation, i.e..
#define DUMMY_STMNT do { } while(0);
#define TRACE(x) DUMMY_STMNT
Hence, a pragma is used with Visual C++ to disable this warning..
> Indeed, this isn't an easy thing to fix...
>
> > However, 32-bit enumeration types are not completely ANSI compliant
> > (for ANSI compliance, a enum should "fit" into an int, because in
> > fact every enum constant is converted into an int at compiler time,
> > and there are no further relation between the type and the
> > constants. This is whole different from Pascal or even C++, and
> > misleading, but was contrained by backward compatibility.)
>
> I've fixed this already by using #ifndef ... #endif around the
> problematic macros so that Wolfgang can provide his own macros in a
> platform-specific file.
>
OK, I'll have a look :-)
Regards,
- David
Re: [Devel] PureC, David Turner, 2001/06/16