[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Portability of Lua
- From: Roberto Ierusalimschy <roberto@...>
- Date: Wed, 1 May 2013 11:00:18 -0300
> On Tue, Apr 30, 2013 at 06:51:23PM -0700, Tim Hill wrote:
> >
> > But the point is that the C "standard" leaves some things so open that
> > it's very difficult to write code without making some guesses. Width of an
> > integer?
>
> If you could provide concrete examples, then it would be easier to discuss.
I already mentioned one: pointer difference and ptrdiff_t. According to
the standard, they are mostly useless:
When two pointers are subtracted, both shall point to elements of
the same array object, or one past the last element of the array
object; the result is the difference of the subscripts of the two
array elements. The size of the result is implementation-defined,
and its type (a signed integer type) is ptrdiff_t defined in the
<stddef.h> header. IF THE RESULT IS NOT REPRESENTABLE IN AN OBJECT OF
THAT TYPE, THE BEHAVIOR IS UNDEFINED.
(emphasis added.) Nothing in the standard connects the minimum size of
ptrdiff_t with size_t. So, an arbitrary subtraction of pointers to
an array larger than 64K can fail. (To make things worse, note that
it does not cause an undefined result, but an undefined behavior! Your
program can simply crash for doing the subtraction.)
In Lua, we assume that the size of ptrdiff_t is at least the size of
size_t and avoid pointer subtraction of pointers to chars. (As size_t
works with chars and ptrdiff_t works with elements, elements with
size >= 2 will fit.) But the standard does not garantee our
hypothesis.
-- Roberto