Thanks for the reply.
I work on Chromium and there many good reasons why it should be a 64-bit
application - security being one of them. Since libxml is being compiled
into Chromium we need it to support 64-bit.
> I run AIX mostly and it's compiler defaults to unsigned.
I'm not sure that's relevant. The only problem I'm hitting is with the
assumption that sizeof(long) == sizeof(void*), which is not a portable
assumption.
I can't fix with compiler switches because there is no option to change the
size of 'long'. I can suppress the warnings, but since some of the warnings
appear to be real issues, that would just be ignoring the problem, not
solving it. I don't know how serious the issues are since it's not clear to
me what the pointer comparisons are for.
On Tue, Nov 10, 2015 at 1:26 PM, Eric S. Eberhard <e...@vicsmba.com> 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.
>
> 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:
>
> Resending 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
>
>
> _______________________________________________
> xml mailing list, project page
> http://xmlsoft.org/xml@gnome.orghttps://mail.gnome.org/mailman/listinfo/xml
>
>
> --
> 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)
>
>
--
Bruce Dawson
_______________________________________________
xml mailing list, project page http://xmlsoft.org/
xml@gnome.org
https://mail.gnome.org/mailman/listinfo/xml
