freetype-devel
[Top][All Lists]
Advanced

[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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]