[xml] Possible 64-bit issues in xml 2.9.2

2015-11-10 Thread Bruce Dawson
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

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

2015-11-10 Thread 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

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

2015-11-10 Thread Bruce Dawson
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

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

2015-11-10 Thread Bruce Dawson
Sure. I'll do that. On old architectures it would be easy enough to use a typedef to 'create' intptr_t, so any compatibility problems that such a patch introduces will be easily fixed. On Tue, Nov 10, 2015 at 5:32 PM, Daniel Veillard wrote: > On Tue, Nov 10, 2015 at

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

2015-11-10 Thread Daniel Veillard
On Tue, Nov 10, 2015 at 05:34:45PM -0800, Bruce Dawson wrote: > Sure. I'll do that. okay, thanks > On old architectures it would be easy enough to use a typedef to 'create' > intptr_t, so any compatibility problems that such a patch introduces will > be easily fixed. the problem is to know

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

2015-11-10 Thread 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: > > >