Re: AC_C_LONG_DOUBLE is obsolescent.

[Harlan Stenn]

Eric Blake wrote:
> Harlan Stenn <stenn <at> ntp.org> writes:
> > A bunch of stuff 
> ... (T)here are platforms that do indeed have 'long double', but where
> it is not wider than 'double' - should HAVE_LONG_DOUBLE be defined or
> not?

IMO, yes.  If folks care about the actual size we have SIZEOF_ things we
can use.

> What you should do instead is use AC_TYPE_LONG_DOUBLE (which will
> probably succeed and define HAVE_LONG_DOUBLE, since most compilers
> support a long double type), or more likely, AC_TYPE_LONG_DOUBLE_WIDER
> (which is actually useful information on modern targets and
> conditionally define HAVE_LONG_DOUBLE_WIDER - in other words, a test
> that is more accurately named for what AC_C_LONG_DOUBLE is currently
> testing).

I have a small dislike for names like _WIDER because they make sense
today, but when there is another "change in technology" the name can
suddenly look silly.  For some reason HAVE_WIDER_LONG_DOUBLE does not
bother me as much.

And again, I wonder if SIZEOF_LONG_DOUBLE and SIZEOF_DOUBLE are useful
and/or sufficient.  I bet for many things they are, and for some things
they are not.

For me, the issue is exactly how will this be used and what are the best
ways to write code where these issues are important?

> > Are you saying autoconf has a primary target audience of systems that
> > use gnulib?
> 
> No, that's not the intent either.  Autoconf intends to remain portable to a 
> much wider audience (both projects and platforms) than what gnulib
> targets

OK, I was just checking, and as Benjamin Reed (RangerRick) pointed out,
I was confused about gnulib/glibc.

> Autoconf MUST continue to care about projects that do not use gnulib.
> I'm only stating that IF you use gnulib, then AC_C_LONG_DOUBLE buys
> you nothing, and you are better off using modern macros like
> AC_TYPE_LONG_DOUBLE_WIDER instead.

'k.

> > I do care very much that the packages I have autoconfiscated will
> > support the widest possible range of running systems.
> 
> As do I.

I thought so, and I'm glad this bit of confusion is over.

H