Re: [Rlib-devel] GCC4 warning fixes part3

[Bob D. <bd...@si...>]

All Applied! (Except for the odd double pointer stuff in datasource)  I
do this because gcc 2.x and 3.x complain if I don't (I know it looks
silly)

Thanks for the great patches!

- bob


> They are attached. Changelog for each follows. The previous
> "monster GCC4 cleanup patch" still contains more stuff.
> I will split it up to smaller pieces that you can review.
>=20
> 01-rlib-1.3.4-gcc4-warnings-1.patch:
>=20
> Fix the following types of GCC 4.0 warnings:
> - warning: function declaration isn't a prototype
>    This is an actual syntax error but the compiler just warns about it.
> - warning: ISO C90 forbids mixed declarations and code
>    Similar constructs aren't really accepted by older compilers:
>      int some_variable;
>      some_variable =3D 0;
>      int some_other_variable;
> - warning: ISO C forbids conversion of function pointer to object=20
> pointer type
>    warning: ISO C forbids initialization between function pointer and=20
> 'void *'
>    warning: ISO C forbids assignment between function pointer and 'void=
 *'
>    Same topic, assignment and conversion between function pointers
>    and object pointers aren't accepted.
> - warning: declaration of 'var/func' shadows a previous local
>    warning: declaration of 'var/func' shadows a global declaration
>    Shadowing parameters, global variables and previously declared local
>    variables can be actual coding bugs.
> - warning: ISO C does not allow extra ';' outside of a function
>    This is a badly defined function:
>      int function(void) {
>        ...
>      };
> - warning: empty body in an if-statement
>    Bad coding, weak attempt at winning an award on the annual
>    Obfuscated C Code Contest:
>      if (expression);
>        do_something();
>=20
> 02-rlib-1.3.4-gcc4-warnings-2.patch
>=20
> - warning: passing argument N of 'func' discards qualifiers from pointe=
r
> target type
> - warning: initialization discards qualifiers from pointer target type
>=20
> and every fallout that would cause incompatible pointers in assignment
> warnings after fixing them.
>=20
> Reasoning: many functions that accept a "gchar *" parameter don't write
> back to the string so they can be marked "const gchar *".
> Indeed, most calls to them are done with constant strings.
>=20
> 03-rlib-1.3.4-number-conversion-crash-fix.patch
>=20
> Allocate strings dynamically in rlib_number_sprintf() and
> rlib_pcode_operator_str(). Also rlib_number_sprintf() so
> it interprets decimal numbers in the correct direction.
> Previously when it got a number format "%18.27", it interpreted
> it as "%81.72", immediately destroying stack content, as the
> space for the to-be-converted strings were too small and
> allocated on the stack.
> Fix one ((long long *)&variable) issue in the unused
> RLIB_VALUE_GET_AS_NUMBERNP macro, too. It could cause massive
> data corruption on 64-bit systems if used.
>=20
> 04-rlib-1.3.4-gcc4-warnings-3.patch
>=20
> There are some places in RLIB where "long long" variables are used.
> Problem is, "long" and "long long" are not the same size across
> architectures. "long" is the native word size of the CPU, i.e.
> 32 bit on 32-bit architectures, 64 bit on 64-bit architectures.
> Size of "long long" is double the native word size. Intention in RLIB
> was to use a 64-bit variable. Fix all those by using the abstract type
> "gint64".
>=20
> 05-rlib-1.3.4-stack-stomping-fixes.patch
>=20
> Fix two suspicious functions that were caught by the bounds checking
> extension for GCC4.
>=20
> - gint64 tentothe(gint n) does not check whether the index into the
>    local array is a correct index. Fix it by using pow(N, M).
>    Two advantages: no more bad stack access and it gives correct answer
>    for n=3D0...18, comparing with the previous n=3D0...11.
>=20
> - gchar hextochar(gchar c) assigned an integer (32-bit) value
>    internally   to its character parameter, possibly overwriting
>    something on the stack.
>=20
> Best regards,
> Zolt=C3=A1n B=C3=B6sz=C3=B6rm=C3=A9nyi