On Thu, 11 Jul 2013, David Chisnall wrote:
On 11 Jul 2013, at 19:52, Tijl Coosemans <t...@coosemans.org> wrote:
GCC doesn't support _Generic yet for -std=c11.
Ugh. Given that they also lack a fine-grained feature check mechanism, they
really should not advertise support for a language dialect if they don't
support it.
+#elif __GNUC_PREREQ__(5, 1)
GCC 3.1?
Ooops, I changed this to 5.1 to test the other code path and forgot to revert
it.
Last __fpclassifyd should be __fpclassifyl.
Fixed.
There are still many style bugs to fix:
- indentation of continuation lines. It was changed from the normal 4
spaces to 1 tab in macro definitions. The style rule for continuation
lines for #define's is not as clear as for statements, but math.h used
to use 4 spaces consistently.
- whitespace before backslashes. It is neither minimal, maximal, lines
up the backslashes to tab boundaries, lines up the backslashes across
macros, nor uses tabs. It repaces formatting that uses tabs to line
up all backslashes to the 7th tab stop.
- whitespace before macro bodies. It was changed from the normal 1 tab
to 1 space. The next block of macros (for __MATH_BUILTIN_RELOPS)
provides examples of normal formatting, and the block beginning with
isfinite() looks really ugly in comparison.
- verbose names, and resulting ugly formatting to avoid long lines
- the x parameter is missing parentheses in the main macros starting at
fpclassify(). __fp_type_select() supplies the necessary parentheses,
but this is fragile.
BTW, is it really permitted for the comparison macros to evaluate their
args more than once? This is done for the !__MATH_BUILTIN_RELOPS case.
I hoped that you replace all the inlines for isnan() by macros, but
now I can't see how to do this without using either multiple evaluation
of the arg or an unportable statement-expression. However, the relops
already use macros that are sloppy about multiple evaluation in the
!_MATH_BUILTIN_RELOPS case, so math.h would be no more broken if it did
the same for isnan(). isnan() is just a special relop that is even
simpler than the others, but its implementation is more complicated and
10-20 times larger in math.h alone (100 times larger counting all the
compatibility cruft for it in other files).
@@ -227,8 +250,6 @@ double expm1(double);
double fma(double, double, double);
double hypot(double, double);
int ilogb(double) __pure2;
-int (isinf)(double) __pure2;
-int (isnan)(double) __pure2;
I think they should stay for the C90 case.
That would completely defeat the point of this entire exercise and be redundant
unless we aim to support a compiler that only supports C90 and no GNU
extensions, in which case you'll hit errors in cdefs.h, long before you get to
this point in an include.
They aren't in C90. More in another reply.
Bruce
_______________________________________________
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
