Re: [xml] libxml2.xmlIO.awn.1.patch

On 9/7/06, Emelyanov Alexey <emal lim ru> wrote:
 > 2006-09-06  Andrew W. Nosenko  <andrew w nosenko gmail com
<mailto:andrew w nosenko gmail com>>
 > [...]
 > Some words about removed '#define stat _stat':
 > 1. this define is just wrong because replaces declarations like
 >     struct stat stat_buff;
 > by
 >     struct _stat stat_buff;
 > and we have either compilation error (if no 'struct _stat' exists) or
 > unpredictable behavior because of no guarantee that these two
 > structures are compatible.
As a matter of fact, complete replacement of 'stat' on '_stat' was
proposed, both for function and for structure.
I assumed, that 'struct _stat' is always used as argument
for _stat().

You are wrong in 2 things:

1. You assume that if _stat() exists, then 'struct _stat' exists also.
It's obviously not true on the my system (FreeBSD-5.4).  And
compilation break as consequence.

2. For some, unknown for me reason, you prefer non-standard and
undocumented _stat(?) over standard and well documented stat(2).
Sorry, may be under Windows such behavior have good reason, but why
you do it on the non-windows systems also?????

Why do you thing that '_stat' have the same amount of parameters, the
same or compatible behavior on the _my_ system?  Why do you think that
this symbol points to the function at all and not, for example, some
global variable or mutex? :-)

Yes, in this concrete case I think that this is just an alternative
entry point to the same syscall, but in general case?

At least, in tested libraries it just so.

You tested on the Windows.  But, windows is not an only one system on
the plannet ;-)

Can you tell, where were problems with compilation?

Every usage of the 'struct stat' in the xmlIO.c.  Please, read above:
there no 'struct _stat' at all.

The replacement was convenient, because there is no
variant of _wstat(), using 'struct stat' as argument.

Without macro 'stat' it should to add more #ifdef / #else.

Sorry, I prefer more ifdefs on the windows-related part, than
compilation error or unpredictable behavior on the Unix.

 > 2. existence of the non-standard function _stat() is not a reason for
 > replacing by it the standard function stat() that exists also
 > (please, pay attention that this is '#else' part of the
 >  '#ifndef HAVE_STAT' condition).
If they are equivalent, why not?

Who say to you that they are equivalent?  Please, point me to the any
standard, which have matter on Unix and say that _stat() and stat()
should be equivalent.  OK.  I remove "have matter on Unix"
restriction.  Just point my to the _any_ standard, that [...]

Andrew W. Nosenko <andrew w nosenko gmail com>

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