[tex-live] TeXLive2007: Bug in (Xe)TeX for 64bit and big endianess

[Dr. Werner Fink]

On Tue, May 08, 2007 at 02:50:07PM +0100, Jonathan Kew wrote:
> On 8 May 2007, at 1:00 pm, Dr. Werner Fink wrote:
> 
> >Hi,
> >
> >just to be noted, I've detected some pointer issues which
> >cause XeTeX to fail on e.g. ppc64 and s390x.  The problem
> >is that a cast from long to int will loose the four lower
> >bytes due to the natural nature of the memory management
> >of big endian systems.  I've attached a patch which fix this
> >issue and get XeTeX on work on ppc64 and s390x.
> 
> Thanks for this; I'll take a look at it and integrate into the main  
> code. I think there's one error in the patch, though: in the hunk  
> that reads
> 
> -#define casttoptr(x)		(void*)(x)
> -#define casttointeger(x)	(long)(x)
> +#define casttoptr(x)		(void*)(&(x))
> +#define casttointeger(x)	(int)(x)
> 
> the semantics will be incorrect. The old code assumed that a (TeX)  
> "integer" variable was large enough to store the value of a C  
> pointer, and that it can then cast back and forth between these  
> (which may be a bad assumption!), but taking the *address* of the  
> integer is not the solution here.

The problem is that casttointeger is used in the resulting
C file web2c/xetex0.c at line 2009 with

  mem[dest+5].hh.v.RH = casttointeger(xmallocarray(char, glyphcount*10));

and yes it would be nice to use an unsigned long or better
an `uintptr_t' as defined in <stdint.h> which is autoamtically
the correct type on all architectures at least on an glibc
based system.  To avoid large changes within the full texk
tree I've shorten this down to an cast on an 4 byte integer.
Otherwise this would require a large change by setting the
type `halfword' to `long' or `unsigned long'.

The underlying problem is that the cweb interface is very
oldish and doesn't know about 8 byte longs ... and also does
things like

       if (x)
         if (y)
	   a;
         else
           b;

which cause always warnings with gcc due missing braces
to make the code unambiguous.
        
> >Next is that I've found during debugging a lot of mixed
> >long and int assignments which may also cause trouble
> >e.g. in high memory loaded ia64 systems due to the large
> >address spaces for virtual memory handling.  IMHO this
> >should be fixed overall the source code not only the XeTeX.
> >
> >One wish I'd like to put here around: is there a way to use
> >libpoppler instead of xpdf?  This would allow to use the
> >system libpoppler and reduce any maintenance effort in any
> >case of a security leak in xpdf/poppler because only the
> >system libpoppler has to be replaced.  For the current
> >libpoppler and XeTeX I've to disable the pdftosrc utility
> >because I've found no way to use this together with libpoppler.
> 
> I don't know, but this is something to investigate. Doesn't pdftex  
> also use xpdf? In fact, pdftosrc has nothing to do with xetex (AFAIK)...

In the official TeXLive tree this is true, nevertheless some
bug reports from customers/users on security issues on xpdf
code, even if not relevant for XeTeX or pdfTeX, have driven
me to use the system shared libpoppler instead of the builtin
xpdf code.


      Werner

-- 
  "Having a smoking section in a restaurant is like having
          a peeing section in a swimming pool." -- Edward Burr