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.
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). Windows simply puts 32 bit apps at the bottom of memory and 64 bit at the top ... which is fine if you don't run out of space. I heard that later Windows does it more like Unix. AIX actually intercepts addresses on 32 bit apps and makes a translation -- so I may or may not be using 64 bit addresses and it does not matter, it is always translated to a 32 bit. Again, I don't need to access a pointer more than 32 bits (excessive in all but the largest of systems). And horsepower on these boxes is so high that the translation is not hurting. I have sites that literally exchange 1.5 million - 2.0 million XML files per day (most in 10 hours) on a weenie little IBM using libxml2 to parse and create XML.
My point on this is you may be able to fix by making it a 32 bit application.
E
On 11/10/2015 2:04 PM, Bruce Dawson wrote:_______________________________________________ xml mailing list, project page http://xmlsoft.org/ xml gnome org https://mail.gnome.org/mailman/listinfo/xmlResending now that I've joined the mailing list...While building 64-bit Chromium with VC++ 2015 Update 1 I noticed a significant number of pointer truncation warnings in libxml, especially in xpath.c. A typical warning is:
warning C4311: 'type cast': pointer truncation from 'xmlChar *' to 'long'
which triggers on the last two lines of this block:
case XML_ELEMENT_NODE:if (node2->type == XML_ELEMENT_NODE) {if ((0 > (long) node1->content) && /* TODO: Would a != 0 suffice here? */(0 > (long) node2->content) &&
The intent is not entirely clear but if these are supposed to be NULL checks then they could easily give the wrong result. In the VC++ world 'long' is always a 32-bit type, so converting a pointer to a long both throws away the top 32 bits and also makes it a signed type. That means that pointers to the first 2 GB of address space will behave as expected, and pointers beyond that will have a 50% chance of behaving incorrectly!
Another example is these two conversions. The code is apparently trying to sort by content address, but on 64-bit Windows builds it will just be sorting by the bottom 32 bits of the content address.l1 = -((long) node1->content);l2 = -((long) node2->content);if (l1 < l2)return(1);if (l1 > l2)return(-1);}
This is not a problem with gcc or clang because their 64-bit builds have 64-bit long, but the C/C++ standard do not mandate and that is not the case with VC++.
I think that the correct type would be ptrdiff_t, or size_t, or intptr_t, or uintptr_t. I've attached the full set of warnings in case that is of any assistance. Even though some of these warnings do not indicate actual bugs it would still be best to use the correct type in order to avoid confusion and warnings.--
Bruce Dawson
-- Eric S. Eberhard VICS 2933 W Middle Verde Road Camp Verde, AZ 86322 928-567-3727 work 928-301-7537 cell http://www.vicsmba.com/index.html (our work) http://www.vicsmba.com/ourpics/index.html (fun pictures)