List Info

Thread: libxml2.xmlIO.awn.1.patch




libxml2.xmlIO.awn.1.patch
user name
2006-09-07 13:15:31
 > 2006-09-06  Andrew W. Nosenko 
<andrew.w.nosenkogmail.com 
<mailto:andrew.w.nosenkogmail.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(). At least, in tested libraries it just so.
Can you tell, where were problems with compilation?

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.

 > 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?

_______________________________________________
xml mailing list, project page  http://xmlsoft.org/
xmlgnome.org
http://mai
l.gnome.org/mailman/listinfo/xml
libxml2.xmlIO.awn.1.patch
user name
2006-09-08 08:29:15
On 9/7/06, Emelyanov Alexey <emallim.ru> wrote:
>  > 2006-09-06  Andrew W. Nosenko 
<andrew.w.nosenkogmail.com
> <mailto:andrew.w.nosenkogmail.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.nosenkogmail.com>
_______________________________________________
xml mailing list, project page  http://xmlsoft.org/
xmlgnome.org
http://mai
l.gnome.org/mailman/listinfo/xml
[1-2]

about | contact  Other archives ( Real Estate discussion Medical topics )