develooper Front page | perl.perl5.porters | Postings from June 2010

Re: ANSI requirement

Thread Previous | Thread Next
Nicholas Clark
June 12, 2010 05:26
Re: ANSI requirement
Message ID:
On Fri, Jun 11, 2010 at 07:59:53PM +0100, Zefram wrote:
> ??var Arnfj??r?? Bjarmason wrote:
> >I vaguely recall someone mentioning that we rely on some features of C
> >that aren't strictly guaranteed by ANSI C,
> Yes, we do.

For starters, we rely on a hosted environment, don't we?
[If I have the term correct - the one with all the header files, and all the
library functions]

> >                                           such as the the offset into
> >a struct being the sum of the sizeof() of the struct members that came
> >before in the struct.
> But not this particular one, which is almost never true across a whole
> implementation.  It would require that no data types have any alignment
> requirement.  Implementations almost always use padding in structs.

And some implementations have different alignment constraints on types when
they are in structs or arrays. (The ARM ABI, for 8 and I believe 16 bit types)
And we built on ARM systems.

> There is something similar, though: we do rely on the offset of a struct
> member being *a pure function of* the types of the preceding members.
> (That is, that where two structs begin with type-identical sequences
> of members, the layouts of those members will be compatible.)  This is
> almost always true.
> We rely on a few other things that are almost always true but not
> guaranteed by the standards.  Off the top of my head:

That's a better list than I was about to make.

> * that all data pointers have bitwise-compatible representations
> * that function pointers are the same size as data pointers

Do we? Or did we manage to use unions in the locations where this would matter?

> * that signed integers are represented in twos-complement

I think that Amdahl mainframes aren't, but it's a long time since we had
anyone building on one, so I don't remember how many tests failed on it due
to this assumption.

> * that signed integer arithmetic cleanly wraps on overflow

Do we? We certainly don't rely on branching after signed integer overflow,
as that is undefined behaviour, and SGI's compiler on 64 bit Irix knows that.

> * that the bits of multi-byte integers are divided up into bytes in
>   adjacent groups, with all bits of each byte participating in the
>   integer representation
> * that bytes consist of exactly eight bits
> * that all-bits-zero is a valid representation of a null pointer

* Something in Socket.xs relies on being able to take the address of the
  members of one of the socket structs, which doesn't work on (I forget
  which sort of) Crays, where its elements are implemented as bitfields,
  because there are only 8 and 64 bit types. But Cray don't make these any

[Gosh, Zefram's bullet points are way terser than mine]

Nicholas Clark

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About