On Tue, Nov 10, 2015 at 2:21 PM, Bruce Dawson <brucedaw...@google.com> wrote:
> 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. >> > 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
