This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v2 4/8] float128: Add public _Float128 declarations to libm.
On Thu, 4 May 2017, Gabriel F. T. Gomes wrote:
> Let me confirm that I understood this correctly...
>
> On the one hand, the macros __HAVE_FLOAT128 (meaning ((b) && (c))) and
> __HAVE_DISTINCT_FLOAT128 (meaning ((b) &&(d))) are not to be tested by
> the users, explicitly. On the other hand, these macros are to be
> present in the installed header (floatn.h), so that, when a user
> includes math.h, the user will get the declarations for *f128 functions
> (if __HAVE_FLOAT128 = 1) and will indirectly access __*f128 functions
> (e.g. __isinff128) through __MATH_TG macros (if
> __HAVE_DISTINCT_FLOAT128 = 1).
Yes. They are in installed headers, but as with all __* symbols in
installed headers, they do not form a public API, should not be used
directly by users, and so are liable to change at any time if a different
approach seems more convenient in future.
(And there is no guarantee that any future support for other _FloatN /
_FloatNx types would use such macros, although the design is intended to
be suitable for other such types as well. __HAVE_FLOAT32 might end up
always being defined to 1 when *f32 support is added, since float always
has a suitable ABI, but if you have a macro __GLIBC_USE_FLOAT such as I
suggested, you'd still want to have __HAVE_FLOAT32 defined so that
__GLIBC_USE_FLOAT (32) can be used. There might be no need for
__HAVE_DISTINCT_FLOAT32, however.)
--
Joseph S. Myers
joseph@codesourcery.com