Eric Blake wrote (on 04-Dec-2013 at 17:43 +0000):
> What are you expecting to do with the biggest alignment, anyways?

Arrange for memory to be allocated such that, just like malloc(), one can know 
that it is suitably aligned for all eventualities.

> The most you can portably do is determine the alignment of the
> types you plan on using ('long long', 'long double', or if you
> probe for extension types such as __int128_t and then check 
> the alignment of that).

Which strikes me a deeply un-portable... how do I tell from machine to machine 
whether 'long long' is bigger or smaller than 'long double' or any other type ?

Also, what I had in mind was some general purpose (library-like) code which has 
not a clue what types its client code may use.... and if it starts making 
assumptions, something, somewhere, sometime, is going to break horribly.

...
> Without a good use case for what you expect to do with it that you
> cannot already determine by checking the alignments of the biggest
> types your code uses, I'm not sure that autoconf needs an extra
> macro.

As above... I don't see how (a) I can tell for any given machine which is the 
biggest of any type the code currently uses -- other than by enumerating all 
the types it currently uses... but the "library" code I was working on, cannot 
possibly know what types its clients use, and enumerating all currently known 
types on any system I might have access to is an horrible hostage to (a) 
systems I don't have access to, (b) future systems, (c) new uses of the 
"library" which do not realise the limitations and use a type with an 
unsupported alignment requirement.

Since malloc() claims to be able to allocate to a maximum alignment boundary, 
this information is clearly not a state secret.

It does not seem unreasonable to me for a tool which is intended to aid 
portability -- so deal with local system properties -- to provide this small 
piece of local system knowledge.

Thanks,

Chris


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

Reply via email to