freetype-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ft-devel] Fw: details on iPhone exploit caused by FreeType?


From: Werner LEMBERG
Subject: Re: [ft-devel] Fw: details on iPhone exploit caused by FreeType?
Date: Fri, 15 Jul 2011 17:59:53 +0200 (CEST)

And again a reply from Mathias.

    Werner


======================================================================

> > > After the shift, the upper half is undefined.
> >
> > This is wrong.  Undefined means undefined in all halves.

The wording in the C standard (6.5.7.5) allows this interpretation,
but I think it is just poor wording.  Bit manipulation with masking,
shifting and ORing, as commonly done, usually just works with signed
integers as with unsigned integers.  It is not recommended to do this
with signed integers, but if it wouldn't behave reasonably, a lot of
code would break.

To look from the machine POV: There are logical and arithmetical shift
instructions.  The logical ones to the right thing for unsigned
numbers, the arithmetical for signed ones.  If shifting to the left,
both are identical.  If shifting right, the difference is whether the
new bits shifted in are filled with zero or a copy of the previously
leftmost bit.

I think the intention for the C standard to allow "implementation
defined" behaviour is to allow use of the logical shift machine
instruction in cases where the CPU doesn't implement the arithmetical
one.

Just had a look into a (german) textbook about C.  It says that shift
operators work for both signed and unsigned numbers in both
directions, but the compiler _may_ use arithmetical shifts for signed
numbers.

This both would mean that bits which are present before and after the
shift are not modified.  (If you know an implementation where this
doesn't hold, please tell me and I'll never shift a signed number
again.)

Attachment: sgntest.c
Description: sgntest.c


reply via email to

[Prev in Thread] Current Thread [Next in Thread]