Re: [gtk-list] Re: YATU - Yet Another Tutorial Update




Tim Janik writes:

>hup? nope, for the moment there are no functions that will pop up a window
>for you, but that could easily be implemented by consequent use of these
>functions.
>g_strerror and g_strsignal will only provide you with an explanatory string
>for the given errno-state.

Actually, I did write ccode for g_print, g_warning and g_error
printing there messages into a text widget. The widget is created on
demand, etc. Only problem is that its buggy. (I think its the text
widgets fault...josh). It'll eventually be used, but not now when it
crashes the program after a few messages have been written. Kinda neat
though. (And yes, the code for doing this is in gtkmain.c).

Werner Koch writes:

>On Thu, Jul 31, 1997 at 04:38:13AM +0200, Tim Janik wrote:
>> regarding g_malloc(), g_free() and siblings, these functions are much safer
>> than thier libc equivalences. e.g. g_free() just returns if called with
>> NULL, i even rely on that behaviour in my apps.
> ^^^^^
> That's required by Standard C, see also free(3).

I remember running across a system that didn't have this behavior. (ie
It would choke if free was passed a NULL pointer). I really should
have documented it at the time as I can't remember what it was now. Or
it could just be my imagination...I like the symetry of having both
g_malloc and g_free. I definately remember that strerror and strsignal
aren't portable. Those should really only compile in the code when
they aren't available on a particular system. (Using autoconf
checks). I think SunOS 4.x doesn't have them. Doesn't have strdup
either as I remember. (Warning: my memory is getting faulty in my
"old" age...don't quote me here).

Peter



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]