Re: Old topic(s) again [was: Re: Proposal: immediate strings]

[Paul Eggert <eggert@cs.ucla.edu>]

On 07/04/2012 06:08 AM, Stefan Monnier wrote:
>> +dnl Determine the basic type of ptrdiff_t.
>> +AC_CHECK_SIZEOF([int])
>> +...
> 
> I really would much rather avoid such things.  Why do we need it?

We shouldn't need it.  Instead of sizeof (TYPE_PTRDIFF_T), the code
can use sizeof (ptrdiff_t).  And instead of a member declaration:

      unsigned TYPE_PTRDIFF_T size : BITS_PER_PTRDIFF_T - 1;

the code should be able to use size_t:

      size_t size : BITS_PER_PTRDIFF_T - 1;

The C standard doesn't guarantee this to work, but compilers generally
support it and if we run into any exceptions we can deal with them the
same way that ENUM_BF deals with enum bitfields.

> while I'm quite willing to believe that this placement
> of gcmarkbit at the end of both structs (placed after differently-sized
> bit fields) works fine in practice, I'd be interested to know to what
> extent the C language guarantees that it will work.

There's no guarantee.  The only guarantees are that members are laid
out in increasing address order, that they're aligned, and that the
first member is at offset zero.  There's no guarantee about where
later members are placed: there can be padding pretty much anywhere
after the first member.

We can easily verify at compile-time that the two layouts have the
same overall size and alignment; that should catch many potential
errors in this area, though not all.

I did not review the meat of the patch carefully, but
I noticed some minor Emacs style indenting issues, e.g.:

      nbytes = s->u.imm.size_byte == STRING_UNIBYTE_IMM_MARK ?
	s->u.imm.size : s->u.imm.size_byte;

should be:

      nbytes = (s->u.imm.size_byte == STRING_UNIBYTE_IMM_MARK
                ? s->u.imm.size : s->u.imm.size_byte);