Re: [patch] Minor improvement to typeclass.h

["Joseph S. Myers" <jsm@polyomino.org.uk>]

On Thu, 10 Jun 2004, Zack Weinberg wrote:

> Ah.  tgmath.h.  Yeah, that's good enough reason to keep the extension,
> although here's a place where a dialogue with glibc people could
> probably result in a better implementation.  (Same sort of icky macros
> you find in altivec.h.)

Though I helped with the design of the built-ins used to implement
altivec.h, having seen the resulting altivec.h and the problems associated
with it I don't think it's proved to be a good direction to go in.  (Part
of the blame must be laid at the designers of an Altivec specification
that didn't give its extensions as amendments to ISO C fitting cleanly
within the text and spirit of the document.)  I'd still prefer the sort of
overloaded built-ins described in projects/index.html to implement
<tgmath.h> (in particular, to avoid the explosion of nested macro text
expansions, each parameter should appear once only in the macro text).  
OTOH I don't really care for adding new extensions either, though this
sort of extension (rather than the mess we have) is clearly envisaged by
ISO C.

(The __builtin_classify_type uses were in Ulrich's part of

2000-08-01  Ulrich Drepper  <drepper@redhat.com>
            Joseph S. Myers  <jsm28@cam.ac.uk>

        * math/tgmath.h: Make standard compliant.  Don't ask how.

<http://sources.redhat.com/ml/libc-alpha/2000-08/msg00014.html>; I had
expected Ulrich to have better taste for comprehensibility of code than to
consider such obscure code as
<http://sources.redhat.com/ml/libc-alpha/2000-07/msg00288.html> a serious
candidate for inclusion in glibc rather than proof that something *could*
be done with GCC as is but you wouldn't want to use the necessary code.)

-- 
Joseph S. Myers
jsm@polyomino.org.uk