Re: standards/51044 (NetBSD cdefs.h defines __func__ incompatibly with C99)

[John Nemeth <jnemeth%cue.bc.ca@localhost>]

The following reply was made to PR standards/51044; it has been noted by GNATS.

From: John Nemeth <jnemeth%cue.bc.ca@localhost>
To: Bruce Lilly <bruce.lilly%gmail.com@localhost>, gnats-bugs%netbsd.org@localhost
Cc: standards-manager%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost,
        gnats-admin%netbsd.org@localhost, dholland%netbsd.org@localhost
Subject: Re: standards/51044 (NetBSD cdefs.h defines __func__ incompatibly with C99)
Date: Wed, 10 Aug 2016 13:26:19 -0700

 On Aug 10,  2:48pm, Bruce Lilly wrote:
 } On Wed, Aug 10, 2016 at 2:17 PM,  <dholland%netbsd.org@localhost> wrote:
 } 
 } > You are seriously complaining about not conforming to C99 when you select
 } > C89?
 } 
 } No, I am complaining that the NetBSD headers trample on __func__ provided
 } by compilers, and redefine it as __PRETTY_FUNCTION__ instead of the
 } compiler's definition, based on a __GNUC_PREREQ__ macro, and that
 
      So, by defining that macro, you're claiming to be GNUC, or at
 least compatible...
 
 } results in different behavior when compiling with clang on NetBSD only
 } (Linux, illumos headers do not trample on __func__).  gcc happens to
 } define the non-standard __PRETTY_FUNCTION__ as equivalent to
 } __FUNCTION__, whereas clang does not.  As __PRETTY_FUNCTION__
 
 ...but you're not actually compatible.  That's your problem.
 
 } is non-standard, and differs among gcc-compatible compilers it should
 } probably not be used to redefine __func__, nor is it useful in assertion
 } messages, for the same reasons of incompatibility.
 } 
 }-- End of excerpt from Bruce Lilly