Re: [xml] Patches to 2.3.4

["Peter Jacobi" <pj walter-graphtek com>]

Hi Dabiel, All,

Sorry, this isn't based on hard facts, but only on personal preferences 
and my reading of the C standard, but I don't like at all pulling all this 
code in.

Let me explain, what I would find more reasonable:

1. Define a well behaving C environment as the common subset of C99, 
some version of POSIX and the newest gcc/glib.

2. Use this subset! Don't punish implementations giving good support by 
re-implementing, what's already provided. No #ifdef kludges in all .c files 
for inferior implementations. On the other hand, don't start using 
extensions only to be found in one implementation.

3. When it is possible to help more than one compiler not having a 
required feature (e.g. the snprintf case), it would be nice to have a 
workaround in the package. In the snprintf case this would be the trio lib, 
I assume. 

3a. Using the trio_* names and macros in xmlconfig.h seems preferable 
to me. On related issue, compilers needing a leading underscore for 
snprintf, open, etc should be given the necessary macro definitions in 
xmlconfig.h and/or win32config.h.

Regards,
Peter Jacobi

Daniel Veillard <veillard redhat com> wrote:
>   Well actually that's part of the things I changed. I didn't want
> to add trio_ prefixes in the code. Maybe a solution based on macros
> in the xmlconfig.h header will allow to get back to a less patched trio
> file and avoid exporting what should be a system funtion (IMHO this was
> safe since linkers should not raise errors when 2 libraries exports the
> same symbol, they will raise problem when this happen in .o files though).