rlib-devel — RLIB Development Mailing List

Re: [Rlib-devel] [Fwd: Some documentation tweaks]

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

William,

I got all of these.   I've been in the process of migrating the
documentation to a wiki so selected people can edit it

Right now it's a free for all

http://newrlib.sicom.com

Fell free to put your changes there

- bob

On Sun, 2005-07-17 at 16:02 -0600, William K. Volkman wrote:
> I noticed that this small set of changes hasn't been
> applied.  Is there something I need to correct?
> 
> Thanks,
> William.
> -------- Forwarded Message --------
> From: William K. Volkman <wk...@us...>
> To: rli...@li...
> Subject: Some documentation tweaks
> Date: Sun, 12 Jun 2005 21:47:14 -0600
> 
> I made some additions to the attributes, fixed some spelling, and
> tried to clarify rlib_add_parameter usage.
> 
> HTH,
> William.
> 

Re: [Rlib-devel] add_function capability and pcode.h

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

My vote is to install pcode.h because if you are going to to make custom
RLIB functions you clearly know what you are doing and probably want
thew full pcode stack

- bob

On Mon, 2005-07-18 at 13:54 -0600, William K. Volkman wrote:
> Hi,
> 	I notice that pcode.h is not installed in /usr/include/rlib
> however to be able to write a function which can be "add"ed it
> pretty much needs defined:
> 
> rlib_value_stack_pop
> RLIB_VALUE_GET_AS_STRING
> RLIB_VALUE_GET_AS_NUMBER
> rlib_value_new_string
> rlib_value_new_number
> 
> So should those definitions migrate to rlib.h or (the quickest)
> add pcode.h to the list of installed headers.
> 
> Thoughts/preferences?
> 
> Cheers,
> William.
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Rlib-devel mailing list
> Rli...@li...
> https://lists.sourceforge.net/lists/listinfo/rlib-devel

[Rlib-devel] add_function capability and pcode.h

[William K. V. <wk...@us...>]

Hi,
	I notice that pcode.h is not installed in /usr/include/rlib
however to be able to write a function which can be "add"ed it
pretty much needs defined:

rlib_value_stack_pop
RLIB_VALUE_GET_AS_STRING
RLIB_VALUE_GET_AS_NUMBER
rlib_value_new_string
rlib_value_new_number

So should those definitions migrate to rlib.h or (the quickest)
add pcode.h to the list of installed headers.

Thoughts/preferences?

Cheers,
William.

[Rlib-devel] [Fwd: [Fwd: [Fwd: Some documentation tweaks]]]

[William K. V. <wk...@us...>]

And this time perhaps we'll recall that the MUA is
stupid and doesn't include attachments when forwarding
so I have to re-attach them by hand...It's Monday...
-----Forwarded Message-----
From: William K. Volkman <wk...@us...>
To: rli...@li...
Subject: [Fwd: [Fwd: Some documentation tweaks]]
Date: Mon, 18 Jul 2005 13:44:08 -0600

And now we'll try sending from our registered email
address...
-----Forwarded Message-----
From: William K. Volkman <wk...@ne...>
To: rli...@li...
Subject: [Fwd: Some documentation tweaks]
Date: Sun, 17 Jul 2005 16:02:46 -0600

I noticed that this small set of changes hasn't been
applied.  Is there something I need to correct?

Thanks,
William.
-------- Forwarded Message --------
From: William K. Volkman <wk...@us...>
To: rli...@li...
Subject: Some documentation tweaks
Date: Sun, 12 Jun 2005 21:47:14 -0600

I made some additions to the attributes, fixed some spelling, and
tried to clarify rlib_add_parameter usage.

HTH,
William.

[Rlib-devel] [Fwd: [Fwd: Some documentation tweaks]]

[William K. V. <wk...@us...>]

And now we'll try sending from our registered email
address...
-----Forwarded Message-----
From: William K. Volkman <wk...@ne...>
To: rli...@li...
Subject: [Fwd: Some documentation tweaks]
Date: Sun, 17 Jul 2005 16:02:46 -0600

I noticed that this small set of changes hasn't been
applied.  Is there something I need to correct?

Thanks,
William.
-------- Forwarded Message --------
From: William K. Volkman <wk...@us...>
To: rli...@li...
Subject: Some documentation tweaks
Date: Sun, 12 Jun 2005 21:47:14 -0600

I made some additions to the attributes, fixed some spelling, and
tried to clarify rlib_add_parameter usage.

HTH,
William.

[Rlib-devel] [Fwd: Some documentation tweaks]

[William K. V. <wk...@ne...>]

I noticed that this small set of changes hasn't been
applied.  Is there something I need to correct?

Thanks,
William.
-------- Forwarded Message --------
From: William K. Volkman <wk...@us...>
To: rli...@li...
Subject: Some documentation tweaks
Date: Sun, 12 Jun 2005 21:47:14 -0600

I made some additions to the attributes, fixed some spelling, and
tried to clarify rlib_add_parameter usage.

HTH,
William.

[Rlib-devel] RLIB 1.3.4 Released

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

Hey All,

RLIB 1.3.4 is now out!

- Fix problems with followers (me)
- Ability to add custom function (Even from languages like PHP!) (me)
- New C# Bindings (me)
- Memory Leaks Fixed (William K. Volkman)
- Some random crashes fixed (Me, Zoltan, William K. Volkman)
- Compile cleanups (Zoltan)
- ODBC Datasource no longer relies on SQLRowCount (Zoltan)
- Compiler fixes / regression testing (me)

Download for sourceforge and enjoy

- Bob

Re: [Rlib-devel] patch to enable "width" and "height" parameters on HTML

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

Applied!

Ty!

On Fri, 2005-07-08 at 14:14 -0300, Everton Luis Berz wrote:
> Follow my patch to enable width and height on IMG tag (HTML ouput).
> 
> 
> plain text document attachment
> (rlib-html_img_src_width_height_patch.txt)
> Index: libsrc/html.c
> ===================================================================
> RCS file: /cvsroot/rlib/rlib/libsrc/html.c,v
> retrieving revision 1.60
> diff -u -r1.60 html.c
> --- libsrc/html.c	27 Jun 2005 16:45:48 -0000	1.60
> +++ libsrc/html.c	8 Jul 2005 17:12:05 -0000
> @@ -286,7 +286,7 @@
>  	gchar buf[MAXSTRLEN];
>  
>  	print_text(r, "<DIV>", FALSE);	
> -	sprintf(buf, "<img src=\"%s\">", nname);
> +    sprintf(buf, "<img src=\"%s\" width=\"%f\" height=\"%f\">", nname, nwidth, nheight);
>  	print_text(r, buf, FALSE);
>  	print_text(r, "</DIV>", FALSE);
>  }

[Rlib-devel] patch to enable "width" and "height" parameters on HTML

[Everton L. B. <ev...@fa...>]

Follow my patch to enable width and height on IMG tag (HTML ouput).


-- 
Everton Luis Berz
Nucleo de Sistemas :: FACCAT - Faculdades de Taquara
+55 51 541 6600 - R.647
ICQ 7807919

Re: [Rlib-devel] RLIB 1.3.4 Pre Release

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

Applied!

Ty!

- bob


> here's a fix for the ODBC datasource. Problem is, SQLRowCount() is
> optional. I tested some PostgreSQL ODBC versions and not all
> of them support it, and when it's not supported, it returns -1.
> It makes the report only use the first record of the result set.
> So I fixed the ODBC datasource to not rely on the number of rows.
> Patch is attached.
>=20
> Best regards,
> Zolt=C3=A1n B=C3=B6sz=C3=B6rm=C3=A9nyi

Re: [Rlib-devel] RLIB 1.3.4 Pre Release

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

Hi,

Bob Doan =EDrta:
> All,
>=20
> If anyone has time can you try:
> http://www.sicom.com/~bdoan/rlib-1-3.4.tar.gz
>=20
> This release includes numerous bug fixes along with pretty serious
> double free bug in RPDF which was cauing RLIB to crash randomly and/or
> you could not run RLIB in a loop generating reports.
>=20
> Let me know if it works for you
>=20
> - Bob

here's a fix for the ODBC datasource. Problem is, SQLRowCount() is
optional. I tested some PostgreSQL ODBC versions and not all
of them support it, and when it's not supported, it returns -1.
It makes the report only use the first record of the result set.
So I fixed the ODBC datasource to not rely on the number of rows.
Patch is attached.

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

[Rlib-devel] RLIB 1.3.4 Pre Release

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

All,

If anyone has time can you try:
http://www.sicom.com/~bdoan/rlib-1-3.4.tar.gz

This release includes numerous bug fixes along with pretty serious
double free bug in RPDF which was cauing RLIB to crash randomly and/or
you could not run RLIB in a loop generating reports.

Let me know if it works for you

- Bob

[Rlib-devel] Re: GCC4 warning fixes part6

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

Hi,

next part. Changelog:

******************************************************
Use correct C-style comments in C sources and headers.
It allows compilation with "gcc -ansi -pedantic" on GCC4.
******************************************************

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

[Rlib-devel] Re: GCC4 warning fixes part5

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

Hi,

next part. Changelog:

******************************************************
Fix "warning: missing initializer ..." warnings on GCC4.
******************************************************

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

[Rlib-devel] Re: GCC4 warning fixes part4

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

Zoltan Boszormenyi =EDrta:
> Sorry, it went to the rlib-users list.

And now with the attachment. :-(

>=20
> Zoltan Boszormenyi =EDrta:
>=20
>> Hi,
>>
>> here's the next part. Changelog:
>>
>> ***********************************************************
>> Silence warnings in datasource.c. The original code gave these
>> kinds of warnings on GCC4:
>> 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 *=
'
>> The above warnings sound serious but on the other hand, explicitly
>> casting the address of a function pointer to a (gpointer *) gave this
>> warning on older GCCs:
>> warning: dereferencing type-punned pointer will break strict-aliasing=20
>> rules
>> Aliasing function pointers to gpointer using unions solves this, using
>>   union {
>>     gpointer ptr;
>>     void (*function)(void);
>>   }
>> allows the assignment to the gpointer and calling function() without
>> warnings.
>> ***********************************************************
>>
>> Best regards,
>> Zolt=E1n B=F6sz=F6rm=E9nyi
>=20
>=20
>=20

[Rlib-devel] GCC4 warning fixes part4

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

Sorry, it went to the rlib-users list.

Zoltan Boszormenyi =EDrta:
> Hi,
>=20
> here's the next part. Changelog:
>=20
> ***********************************************************
> Silence warnings in datasource.c. The original code gave these
> kinds of warnings on GCC4:
> warning: ISO C forbids conversion of function pointer to object pointer=
=20
> type
> warning: ISO C forbids initialization between function pointer and 'voi=
d *'
> warning: ISO C forbids assignment between function pointer and 'void *'
> The above warnings sound serious but on the other hand, explicitly
> casting the address of a function pointer to a (gpointer *) gave this
> warning on older GCCs:
> warning: dereferencing type-punned pointer will break strict-aliasing r=
ules
> Aliasing function pointers to gpointer using unions solves this, using
>   union {
>     gpointer ptr;
>     void (*function)(void);
>   }
> allows the assignment to the gpointer and calling function() without
> warnings.
> ***********************************************************
>=20
> Best regards,
> Zolt=E1n B=F6sz=F6rm=E9nyi

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

Re: [Rlib-devel] Fixes crash if user fails to check error return

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

Applied!

Ty!

- bob

On Mon, 2005-06-13 at 19:51 -0600, William K. Volkman wrote:
> Calling get_output if the report execution failed (I.E.
> the XML was poorly formed) can access violate.  Be more
> defensive in the interface.
> 
> 

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] Re: Crasher bug in RLIB

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

Zoltan Boszormenyi =EDrta:
> - gchar hextochar(gchar c) assigned an integer (32-bit) value
>   internally to its character parameter, possibly overwriting
>   something on the stack.

I hate myself when I keep forgetting that implicit type-casts work. :-(
So this fix is actually a warning fix, not a bugfix.

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

Re: [Rlib-devel] Re: Crasher bug in RLIB

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

Zoltan Boszormenyi =EDrta:
> William K. Volkman =EDrta:
>=20
>> On Thu, 2005-06-23 at 23:25, Zoltan Boszormenyi wrote:
>>
>>> Bad news. Running the same report in a for() cycle, it still
>>> crashes on the second turn. There are more stack-destroying bugs
>>> in heaven and earth, Horatio... :-)
>>
>>
>>
>> I also ran into this last night, haven't had a chance to
>=20
>=20
> Phew. So it's not just my bad luck. :-)
>=20
>> investigate further.  Are you using your two patches
>> for the GCC 4 issues?  My RLIB version is skewed a bit
>=20
>=20
> Yes, I am using those two patches, and I also cleaned up
> "long long" usage replacing it with gint64 abstract type
> to further reduce the amount of warnings. It would be best
> to get rid of all the explicit casts so the compiler's
> type checking will work.
>=20
>> from latest CVS, 3 of the last 5 patches I made
>> are not in CVS yet.  I might get some time this weekend
>> to help you hunt the other bugs.
>=20
>=20
> I intend to install the final gcc-4.0.0 (the gcc4 update for FC3
> is based on a snapshot) and the bounds checking patch on top of it.
> This seems to be a highly useful feature, you can find it here:
>=20
> http://sourceforge.net/projects/boundschecking/
>=20
> The compiler will generate code that guards against itself
> if you use option -fbounds-checking.

After compiling GCC4 4 times, here's the RPM SPEC file if someone
is interested. It's based on the FC3 GCC4 errata release, you will need
gcc4-4.0.0-0.41.fc3.src.rpm, the patch from the above address for
GCC 4.0, bounds-checking-gcc-4.0.0-1.00.patch.bz2, and this specfile.

Using -fbounds-checking didn't reveal any real bugs in RLIB,
but here are fixes for two suspicious functions. They got suspicious
because of the bounds checking messages. One of the bugs was not
obvious, patch is also attached.

- 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.

- gchar hextochar(gchar c) assigned an integer (32-bit) value
   internally to its character parameter, possibly overwriting
   something on the stack.

However, it didn't fix the bug where running the same report
the second time makes it crash.

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] Re: Crasher bug in RLIB

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

William K. Volkman =EDrta:
> On Thu, 2005-06-23 at 23:25, Zoltan Boszormenyi wrote:
>=20
>>Bad news. Running the same report in a for() cycle, it still
>>crashes on the second turn. There are more stack-destroying bugs
>>in heaven and earth, Horatio... :-)
>=20
>=20
> I also ran into this last night, haven't had a chance to

Phew. So it's not just my bad luck. :-)

> investigate further.  Are you using your two patches
> for the GCC 4 issues?  My RLIB version is skewed a bit

Yes, I am using those two patches, and I also cleaned up
"long long" usage replacing it with gint64 abstract type
to further reduce the amount of warnings. It would be best
to get rid of all the explicit casts so the compiler's
type checking will work.

> from latest CVS, 3 of the last 5 patches I made
> are not in CVS yet.  I might get some time this weekend
> to help you hunt the other bugs.

I intend to install the final gcc-4.0.0 (the gcc4 update for FC3
is based on a snapshot) and the bounds checking patch on top of it.
This seems to be a highly useful feature, you can find it here:

http://sourceforge.net/projects/boundschecking/

The compiler will generate code that guards against itself
if you use option -fbounds-checking. Valgrind for x86-64
(daily subversion repository) starts working again
but it does not catch stack corruption. :-(
Thanks, anyway.

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

Re: [Rlib-devel] Re: Crasher bug in RLIB

[William K. V. <wk...@us...>]

On Thu, 2005-06-23 at 23:25, Zoltan Boszormenyi wrote:
> Bad news. Running the same report in a for() cycle, it still
> crashes on the second turn. There are more stack-destroying bugs
> in heaven and earth, Horatio... :-)

I also ran into this last night, haven't had a chance to
investigate further.  Are you using your two patches
for the GCC 4 issues?  My RLIB version is skewed a bit
from latest CVS, 3 of the last 5 patches I made
are not in CVS yet.  I might get some time this weekend
to help you hunt the other bugs.

Cheers,
William.

Re: [Rlib-devel] Re: Crasher bug in RLIB

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

Zoltan Boszormenyi =C3=ADrta:
> Hi!
>=20
> Bob Doan =C3=ADrta:
>=20
>> Can you send a stack trace or is it really nasty?
>>
>> On Mon, 2005-06-13 at 00:25 +0200, Zoltan Boszormenyi wrote:
>>
>>> Hi,
>>>
>>> I created a two-query report with <Part> tag.
>>> There is a bug somewhere in RLIB that overwrites the stack
>>> and I get a "** NUTS.. WE CRASHED" message.
>>> If I filter the report's queries to return no rows,
>>> it doesn't crash. But if I filter the queries to return
>>> something and execute the report twice with the same
>>> result sets, I get a crash. Executing the query the first
>>> time I get the correct PDF. I try to track it down.
>>> Finally, the developers put x86-64 support into valgrind,
>>> maybe it will work for me, too.
>>>
>>> Best regards,
>>> Zolt=C3=A1n B=C3=B6sz=C3=B6rm=C3=A9nyi
>=20
>=20
> Finally here's the fix for the crash I was experienced. It was not a
> 64-bitness issue, it crashed because the number conversion
> str(field,N,M) interpreted N and M backwards, e.g. str(field,18,2)
> was actually converted as "%81.2f" and the space used for
> converting both the integer and decimal parts of the number
> were statically allocated as:
>=20
>     gchar    left_holding[20];
>     gchar    right_holding[20];
>=20
> If one used two digit size for the integer part immediately
> exceeded the allocated space and caused stack corruption.
> I fixed rlib_number_sprintf() and rlib_pcode_operator_str()
> to allocate their strings dinamically and rlib_number_sprintf()
> to interpret the numbers correctly.
>=20
> It was a tough one to find without valgrind. :-D
>=20
> The patch also removes a bad cast, the macro changed isn't used
> in RLIB yet, but it would cause a memory corruption, too, on 64-bit
> systems. (long long) is 128 bits here and number_value member of
> struct rlib_value is gint64. The compiler can at least warn us
> this way.

Bad news. Running the same report in a for() cycle, it still
crashes on the second turn. There are more stack-destroying bugs
in heaven and earth, Horatio... :-)

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