Re: [xml] VC10\config.h and include\win32config.h

[Peter Kasting]

I echo Bruce's request for a single upstream Windows config file.  It looks
like include/win32config.h is older; win32/VC10/config.h seems to have only
its initial addition in its log.  It looks like that addition happened here:

https://git.gnome.org/browse/libxml2/commit/?id=066c69777207436e3517d1b930a97f0e0a8aa060

This seems to have been a convenience for
https://bugzilla.gnome.org/show_bug.cgi?id=666491 (see
https://bugzilla.gnome.org/show_bug.cgi?id=666491#c3 , "This is a different
and more convenient approach to libxml2 usage, than the nmake approach"),
but it's not clear to me that libxml wants to do this sort of thing.  In
https://bugzilla.gnome.org/show_bug.cgi?id=666491#c5 , Daniel notes "Adding
a VC10 subdir under win32 is a bit heavy, I hope there won't be a new one
for each new version of the Microsoft tools."  Those fears seem to me to be
somewhat confirmed; because Microsoft has changed things about the project
format, I believe the .vcxproj files in this directory wouldn't serve
directly for all later versions of MSVC.  So this is really a "Visual
Studio 2010 only" directory.

To me, this whole directory should be nuked, and include/win32config.h
updated (see my notes below).  People using this directory should either
carry their own project/build files (as Chromium does) or use the existing
nmake method. libxml2 shouldn't be responsible for carrying this sort of
thing, especially when it's for one version of one compiler on one platform.

Another possibility is for this directory to remain, and further
directories be added for other MSVC versions (which seems unappealing).

In any case, I think win32config.h should be updated; see below for my
responses to Bruce's comments about the differences between the configs.

On Mon, Mar 7, 2016 at 1:47 PM, Bruce Dawson  wrote:

> #define HAVE_STDINT_H
>

I believe this line is correct for MSVC 2010+.  If libxml doesn't support
anything earlier, then that line should be in win32config.h as-is.
Otherwise, it should probably be in but with an appropriate _MSC_VER check.

#define SEND_ARG2_CAST
> #define GETHOSTBYNAME_ARG_CAST
>

I think these must be defined if nano{http,ftp}.* are built.  If these are
ever built on Windows, win32config.h should include these lines.

PK
___
xml mailing list, project page  http://xmlsoft.org/
xml@gnome.org
https://mail.gnome.org/mailman/listinfo/xml

Re: [xml] Possible 64-bit issues in xml 2.9.2

[Peter Kasting]

On Tue, Nov 10, 2015 at 2:21 PM, Bruce Dawson 
wrote:

> On Tue, Nov 10, 2015 at 1:26 PM, Eric S. Eberhard 
> wrote:
>
>> I am not 100% sure this applies but I'd check into it.  I run AIX mostly
>> and it's compiler defaults to unsigned.  When moving my products to VC++ I
>> had to set some switches so that unspecified (e.g. char x; instead of
>> unsigned char x;) would default to unsigned.  Then my stuff compiles fine.
>> I did make my own projects for VC++ and libxml2 and they do have the
>> unsigned/signed switches set.  It is fairly current libxml2 on VS 2008.
>> Which you are welcome to the projects if you want I can drop a tarball onto
>> my public FTP site.
>>
>> My point is you  may be able to fix with compiler switches.
>>
>
The signedness of "char" is implementation-specific per the C standard,
hence the ability to change with switches.  The bugs in question here are
not related to the char type, so these sorts of switches don't apply.

As Bruce notes, it is not possible to address the actual issues here with
switches.

Another idea -- I believe that I also compiled them as 32 bit apps.
>> libxml2 has no need to be a 64 bit app.  It need to run on a 64 bit
>> computer which is no problem.  But libxml2 will never address that much
>> space and the O/S is decent in Windows at handling that (and great in AIX
>> and pretty good in Linux and OS/X and HP/UX).
>>
>
Unfortunately, because Chromium is 64-bit, we may not be passing a >2GB
buffer to libxml, but we definitely could be passing in virtual addresses
whose upper 32 bits are not zero- or sign-extensions of the lower 32 bits.
In that case it doesn't matter what amount of memory libxml needs to
address; the input addresses are sufficient to trigger problems even with
small buffer sizes.

PK
___
xml mailing list, project page  http://xmlsoft.org/
xml@gnome.org
https://mail.gnome.org/mailman/listinfo/xml

Re: [xml] Possible 64-bit issues in xml 2.9.2

[Peter Kasting]

On Tue, Nov 10, 2015 at 3:38 PM, Eric S. Eberhard  wrote:

> But I also found a /clr compiler switch which DOES allow a 64 bit
> application to call a 32 bit dll application ... with the implied
> assumption that the addressing will be taken care of:
>
>
> https://msdn.microsoft.com/en-us/library/windows/desktop/aa384231(v=vs.85).aspx
> https://msdn.microsoft.com/en-us/library/ms973190.aspx
>
> I am pretty I did not "solve" your problem but I may have given you some
> leads ... both of those sites are over my Windows knowledge threshold.  But
> if you solve it I would be curious to know the answer :-)
>

It's not feasible to run libxml as a separate service, wrapped using COM to
marshal calls to it.

This is not the sort of problem that is solvable with simple compiler
switches or the like.  The libxml code is fundamentally buggy.  It makes
assumptions that sizeof(long) >= sizeof(intptr_t), which is not guaranteed
by the standard and is in fact violated in practice on 64-bit Windows
builds.  The way to fix these is to change the code.

PK
___
xml mailing list, project page  http://xmlsoft.org/
xml@gnome.org
https://mail.gnome.org/mailman/listinfo/xml

[xml] [PATCH] Signed vs. unsigned comparison warnings in dict.c

[Peter Kasting]

When compiled in MSVC, dict.c triggers warning C4018 for comparing signed
and unsigned values in two places.

In both cases, the code basically does:

if (pool-end - pool-free  unsigned int) ...

The type of the LHS here is ptrdiff_t, which is signed.  When comparing
signed to unsigned values, the compiler will convert the signed value to an
unsigned value.  So if pool-end  pool-free, the comparison will almost
always succeed, which was probably not the intent.

The attached patch is one conservative way to fix this, which should be
correct in all cases on all platforms.  Another route, if you know that
pool-end = pool-free in all cases, would be to simply cast to size_t
without additional checks.  Yet another route, if you knew the above AND
that the difference would fit in an unsigned int, would be to
unconditionally cast to unsigned int.

This seems to be the only place preventing Chromium from compiling libxml
with this warning enabled (which is the default state for this warning), so
it would be nice to fix.  The attached patch was generated from an older
copy of the libxml sources, but I think should still apply (possibly with a
slight offset) to the current tree.

PK


xml_signedness.patch
Description: Binary data
___
xml mailing list, project page  http://xmlsoft.org/
xml@gnome.org
https://mail.gnome.org/mailman/listinfo/xml

Re: [xml] [PATCH] Signed vs. unsigned comparison warnings in dict.c

[Peter Kasting]

On Tue, Jul 21, 2015 at 11:19 AM, Peter Kasting pkast...@google.com wrote:

 The attached patch is one conservative way to fix this, which should be
 correct in all cases on all platforms.


For some reason on the archives the patch downloads as a .bin file instead
of a text file.  While you can simply rename the patch or apply it anyway
(the contents were OK), here's a re-attached version with a .txt file
ending in hopes the name won't get mangled.

PK
diff --git a/dict.c b/dict.c
index 5f71d55..a9ff53e 100644
--- a/dict.c
+++ b/dict.c
@@ -249,7 +249,7 @@ xmlDictAddString(xmlDictPtr dict, const xmlChar *name, 
unsigned int namelen) {
 #endif
 pool = dict-strings;
 while (pool != NULL) {
-   if (pool-end - pool-free  namelen)
+   if (pool-end  pool-free  (size_t)(pool-end - pool-free)  
namelen)
goto found_pool;
if (pool-size  size) size = pool-size;
 limit += pool-size;
@@ -317,7 +317,8 @@ xmlDictAddQString(xmlDictPtr dict, const xmlChar *prefix, 
unsigned int plen,
 #endif
 pool = dict-strings;
 while (pool != NULL) {
-   if (pool-end - pool-free  namelen + plen + 1)
+   if (pool-end  pool-free 
+  (size_t)(pool-end - pool-free)  namelen + plen + 1)
goto found_pool;
if (pool-size  size) size = pool-size;
 limit += pool-size;
___
xml mailing list, project page  http://xmlsoft.org/
xml@gnome.org
https://mail.gnome.org/mailman/listinfo/xml