It's been rumoured that Andrew S. Howell said:
>
> Looks like this is a "it can't possibly fail there" bug. The file name
> that I enter is set in fileBoxCB but is null when fileBox
> returns. In fileBox, the code that waits for the use to hit a button:
>
> while( !done || XtAppPending(app) )
> XtAppProcessEvent( app, XtIMAll );
>
> /* save the last directory that the user worked in.
> * we will offer up this same directory to the user next
> * time they get to this box.
> */
> if (fileName) { <-- null here...
>
> Still a bit confused as how this could happen. The address passed in
> to the callback's client data is the same as I see in fileBoxCB.
>
> Maybe a compiler bug? I am running an old gcc.
Possibly, but also ...
-- make clean; make sometimes old objects sneak in and ruin everything.
-- print the address of each string (use %p) I wonder if there are two strings,
one that is null, one that is set.
-- worse comes to worse, in gdb, there is a way of 'watching' a variable,
and stopping every time its set. that way, you can spot every time someone changes
the value of the thing ... (however, warning, i've had gdb+libefence+gnucash lock
up my x server requiring a reboot ...)
--linas
----- %< -------------------------------------------- >% ------
The GnuCash / X-Accountant Mailing List
To unsubscribe, send mail to [EMAIL PROTECTED] and
put "unsubscribe gnucash-devel [EMAIL PROTECTED]" in the body
