Re: glib-tml-980819-0.patch

[Tim Janik <timj gtk org>]

On Fri, 21 Aug 1998, Tor Lillqvist wrote:

> Tim Janik writes:
>  > you have basically just commented out the code that is performed
>  > by g_debug and g_stack_trace, and let them just call abort() if
>  > NATIVE_WIN32 is defined.
> 
> Maybe g_debug should even simply do ' *((int *)NULL) = 0 ' which will
> cause at least MS DevStudio, if installed, to offer debugging the
> program? (abort() just prints "Abnormal program termination" and
> stops)

out of curiosity, what will this cause without MS DevStudio? are you
sure this is not a reboot-hook? ;))

>  > GLIBAPI stuff:
>  > i'm hesitating a bit to apply this, since it would be nice if we could
>  > keep glib.h in its current manner. the automatic Window header file
>  > generation i suggested in the "Re: Gtk port to Win32 "progress report""
>  > thread might be a solution to this.
> 
> Oh well, I could try to write that perl or awk script that
> automatically generates a Win32-specific glib.h (and gmodule.h). The
> makefiles for Win32 would then copy it over glib.h. (They also should
> automatically copy glibconfig.h.win32 and gmoduleconf.h.win32 to
> glibconfig.h and gmoduleconf.h.)
> 
> Btw, I noticed I forgot to include the gmodule-win32.c file in the
> patch, sorry.

yep, i was curious to look at it, but then forgot that i missed reading it ;)

>  >   so your change to just #ifdef WIN32 for changing
>  >   the plugin names is probably justified ;) but we should really supply an
>  >   extra function for this, something like
>  > gchar*
>  > g_module_make_file_name (const gchar *module_name)
>  > {
>  >   g_return_val_if_fail (module_name != NULL, NULL);
>  > #ifdef WIN32
>  >   return g_strconcat ("lib", module_name, ".dll", NULL);
>  > #else /* !WIN32 */
>  >   return g_strconcat ("lib", module_name, ".so", NULL);
>  > #endif /* !WIN32 */
> 
> IMHO it's questionable if the "lib" prefix should be used on Win32.

sure, that can probably read
#ifdef WIN32
  return g_strconcat (module_name, ".dll", NULL);
#else /* !WIN32 */
  return g_strconcat ("lib", module_name, ".so", NULL);
#endif /* !WIN32 */

on unixen we currently require the "lib" prefix since automake/libtool
require this for shared libraries.

>  >   btw, why are you checking for "WIN32" here, and not for "NATIVE_WIN32" as
>  >   in the above?
> 
> Hmm. The GNU-Win32 tools don't support creating and dynamically
> loading shared libs very well yet (correct me if I'm wrong), so in a
> way this is a moot question. I don't know whether the GNU-Win32 tools
> eventually will prefer calling them .so or .dll .

ok, so "WIN32" is always defined for windows compilations, and
"NATIVE_WIN32" is defined for what then (watcom, GNU, MSC)?

>  > miscellaneous:
>  > - we probably need to make adaptions to a few else functions,
>  >   e.g. g_dirname, g_basename come to mind.
> 
> Yup.
> 
>  > for one i'd really like to thank you very much for going through
>  > this, making glib more portable is actually a *very* worthwhile
>  > goal.
> 
> Thanks. I guess I'll modify my changes according to your comments and
> submit a new patch in a few days?

that would be nice. i'm certainly willing to apply your patch,
but i'd like to get the GLIBAPI thing sorted out. if there is a way around
that (even if it requires some complicated header parsing and magic), imho,
we should go for that.

> One thing about gtk: the Watcom compiler (argh, maybe I should switch
> to using only MSVC and forget Watcom) defines va_list as "typedef char
> *va_list[1]". As you might imagine, va_list being an array type causes
> all kinds of strange effects in gtk in the functions where va_lists
> are passed by reference....
> 
> I think I'll take care of with a few macros, something like
> VA_LIST_REFERENCE(va) that expands to "&va" on normal systems or just
> "va" on Watcom. Etc.

hm, now you mention it, i still have a bug report in my queue that
reports similar problems on a unix machine. i'll fiddle around with the
va_list stuff again. we need to get this thing seperated out.

> 
> What does the C standard say, what should you be allowed to do with a
> va_list? Are there other compilers that define va_list as an array? Is
> the Watcom compiler non-compliant in this way?

i guess, peter mattis passed the va_lists by reference, because may have
thought, that you can't (reliably) process them with va_arg() if you
work on a copy only, but at least glibc (and libc) provide va_list
iterating functions that work on copies only, i.e. v*printf().
thus, i think the better solution to this is, to reduce the two va_list*
pointers, that get passed to a few functions in glib/gtk, into one
va_list that is passed as a copy parameter.

> 
> --tml
> 

---
ciaoTJ