Re: [PATCH] _BSD_SOURCE in math.h; MAXFLOAT is XOPEN only

[Isaac Dunham <idunham@lavabit.com>]

On Fri, 6 Apr 2012 09:14:48 -0400
Rich Felker <dalias@aerifal.cx> wrote:

> On Thu, Apr 05, 2012 at 10:32:27PM -0700, Isaac Dunham wrote:
> > This is pretty minor for the most part.
> > There was one issue I noticed: 
> > _GNU_SOURCE defines MAXFLOAT here, but glibc only defines it if
..
> To clarify the general policy: In musl, _GNU_SOURCE or _BSD_SOURCE
> should not break or remove functionality specified by the actual
> standards. They should just add the missing nonstandard stuff
> associated with GNU or BSD.
The patch does not copy glibc logic, since I agree with that policy:
 
+#if defined(_XOPEN_SOURCE)
+#define MAXFLOAT        3.40282347e+38F
+#endif
+
I agree entirely with not removing functionality when a legacy _SOURCE
macro is defined; but... 
> Further, so far _GNU_SOURCE has been a superset of _XOPEN_SOURCE (i.e.
> anything under defined(_XOPEN_SOURCE) has ||defined(_GNU_SOURCE) with
> it). If it turns out this is a bad idea, I'm not entirely opposed to
> changing that, but just matching the exact set of definitions provided
> by glibc for its own sake is not a good enough reason to change. The
> goal is always compatibility with applications, not matching glibc.

I excluded _GNU_SOURCE in this one case because for some reason, GNU
wants to exclude MAXFLOAT in favor of HUGE--the excerpt:
#else	/* !SVID */
# ifdef __USE_XOPEN
/* X/Open wants another strange constant.  */
#  define MAXFLOAT	3.40282347e+38F
# endif
#endif	/* SVID */
I think that using SVID interfaces in favor of X/Open is brain-damaged,
but I'm not interested in automatically defining something if
_GNU_SOURCE is defined when GNU takes pains to exclude it under the
same conditions; that approach is deliberate breakage.

Unlike glibc, -D_XOPEN_SOURCE -D_GNU_SOURCE still activates the full
X/Open logic with this patch.

Isaac Dunham