On 2013-06-20 19:53 +0100, 'Chris Hall' wrote:
> Nick Bowler wrote (on Thu 20-Jun-2013 at 19:06 +0100):
> > On 2013-06-20 10:51 -0700, Russ Allbery wrote:
> > > Nick Bowler <nbow...@elliptictech.com> writes:
> > > > C11 also provides max_align_t, which is *probably* what you are
> > > > looking for but obviously isn't available everywhere.  Anyway,
> > > > on older implementations without max_align_t, the following
> > > > type is probably a "good enough" substitute for it:
> > > >
> > > >   union {
> > > >     char a;
> > > >     short b;
> > > >     int c;
> > > >     long d;
> > > >     long long e;
> > > >     float f;
> > > >     double g;
> > > >     long double h;
> > > >     void *i;
> > > >   }
> 
> > > I would add a function pointer, but yes.
> 
> > Good idea.
> 
> Hmmm.  Up to a point...
> 
> ...I confess this approach makes me feel more than a little queasy.  I
> checked the C99 standard and the above appears to cover all the types
> mentioned in 6.2.5... except for _Bool (!).

Indeed, _Bool is reasonable to add as well (after checking for its
existence).

> I note that the _Complex types are defined to have the same alignment
> as the corresponding floats.  Similarly unsigned integers are defined
> to align the same as the corresponding signed ones.  There's wchar_t,
> size_t, intptr_t, ...  which I suppose one is justified in supposing
> are the same as one of the ordinary integers.

I would only add the extra types if you actually encounter an
implementation where it matters.  Feel free to add an intmax_t
member to the union as well (after checking for its existence).

> But then there are the "implementation defined extended integer
> types"... which aren't on the list, of course -- uint256_t, anybody ?
> (I cannot spot anything in the standard which says that long long is
> definitely bigger than long, or that it definitely has a larger
> alignment... similarly long double etc...  otherwise the list could be
> shortened somewhat.)

A few points to consider:

1) This union was suggested as a replacement for max_align_t on
   implementations which do not provide it.  Future implementations
   will provide max_align_t, so going forward you won't depend on the
   union.

2) Larger integer types are probably not going to have stricter
   alignment requirements than "long long" on current processors.

3) Don't let the perfect be the enemy of the good enough.

> ...I cannot help feeling that this would be wonderfully portable,
> except where it wasn't -- and in the second of these cases you'd be in
> it up to your neck, without warning.

Unfortunately, it's likely the best you can do without something like
max_align_t, or __BIGGEST_ALIGNMENT__, or whatever.

> Actually, for what I am trying to do, I have decided to fake
> alignof().  It takes a bit of dicking-about, but it occurred to me
> that alignof(foo_t) may be constructed as offsetof(struct { char x;
> foo_t q; }, q)... Sadly gcc throws an unhelpful (in this case)
> warning... which requires some scrubbing around :-(

This pattern is essentially the same as how AC_CHECK_ALIGNOF actually
works.  There is also an alignof module in Gnulib which may be of
interest to you.

But I'm not sure this (by itself) helps you, since you'd still need a
suitable definition of foo_t.

Cheers,
-- 
Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/)

_______________________________________________
Autoconf mailing list
Autoconf@gnu.org
https://lists.gnu.org/mailman/listinfo/autoconf

Reply via email to