rlib-devel

[Rlib-devel] GCC4 warning fixes part1

[Zoltan B. <zb...@du...>]

Hi,

I tried to find why RLIB crashes on my FC3/x86-64 system.
Although valgrind for AMD64 found 1 error caused by a mis-sized malloc,
it is still in its infancy, today's valgrind subversion repo segfaults.
Instead, I tried to use GCC 4 to find the error.

I used this exaggerated warning level:

CFLAGS=3D"-g -O -pedantic -Wcomment -Wformat -Wimplicit -Wmultichar \
-Wparentheses -Wreturn-type -Wswitch -Wunused -Wuninitialized -Wall \
-W -Wshadow -Wpointer-arith -Wcast-align -Wwrite-strings -Wconversion \
-Wstrict-prototypes -Wlong-long

In this first patch, I corrected the following (most annoying) warning
types, some of which are actual coding bugs:

warning: function declaration isn't a prototype
warning: ISO C90 forbids mixed declarations and code
warning: ISO C forbids conversion of function pointer to object pointer t=
ype
warning: ISO C forbids initialization between function pointer and 'void =
*'
warning: ISO C forbids assignment between function pointer and 'void *'
warning: declaration of 'var/func' shadows a previous local
warning: declaration of 'var/func' shadows a global declaration
warning: ISO C does not allow extra ';' outside of a function
warning: empty body in an if-statement

Please, review the patch, especially the two fixes in graphing.c,
that fixes this construct, note the ';' after the if():

	if (condition);
		do_something();

and the changes in layout.c from line 836 so the changes follow
the original intention. All the other changes in the attached patch
are trivial changes.

Best regards,
Zolt=E1n B=F6sz=F6rm=E9nyi

[Rlib-devel] GCC4 warning fixes part2

[Zoltan B. <zb...@du...>]

Hi,

part 2, this time I fixed the following warnings to decrease the flood:

warning: passing argument N of 'func' discards qualifiers from pointer
target type
warning: initialization discards qualifiers from pointer target type

and every fallout that would cause incompatible pointers in assignment
warnings.

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.

Best regards,
Zolt=E1n B=F6sz=F6rm=E9nyi

[Rlib-devel] GCC4 warning fixes part3

[Zoltan B. <zb...@du...>]

Hi,

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. Fixed by using the abstract type "gint64".

Best regards,
Zolt=E1n B=F6sz=F6rm=E9nyi

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

Re: [Rlib-devel] GCC4 warning fixes part3

[Zoltan B. <zb...@du...>]

Bob Doan =C3=ADrta:
> 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)

OK. How about the following patch? Changelog:

**************************************************
Speed up RLIB slightly when used in "batch mode"
(e.g. creating multiple reports in a row) by
not unloading the datasource modules.
Hide the differrent function pointers behind typedefs
to silence the warnings about assignment between
void* and function pointers.
**************************************************

I tried it today on a RedHat 9 system, neither gcc-3.2.2,
nor compat-gcc-2.96 complain. If your compiler does,
please tell me your CFLAGS settings. Thanks.

It shouldn't cause problems, libraries opened with dlopen()
(or on Windows, LoadLibrary()) are closed/freed automatically
when the application exits.

Best regards,
Zolt=C3=A1n B=C3=B6sz=C3=B6rm=C3=A9nyi