NetBSD-Bugs archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: standards/51044: NetBSD cdefs.h defines __func__ incompatibly with C99
The following reply was made to PR standards/51044; it has been noted by GNATS.
From: Bruce Lilly <bruce.lilly%gmail.com@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc:
Subject: Re: standards/51044: NetBSD cdefs.h defines __func__ incompatibly
with C99
Date: Tue, 5 Apr 2016 09:44:19 -0400
--001a113eb424c56f20052fbd0a20
Content-Type: text/plain; charset=UTF-8
Dropping the quoted lines from cdefs.h would fix the problem for new
systems (i.e. with cdefs.h w/o those lines).
Agreed that the assumptions made by those lines may be (indeed in the case
documented, are) wrong.
Anybody compiling with gcc or (ostensibly) gcc-compatible compilers who
cares about __func__ with pre-C99 code is probably already using the
documented gcc work-around, and doesn't need to have cdefs.h foul that up.
The ideal is to have simple code (such as in the samples) that produces the
same result regardless of (POSIX-compliant) OS or compiler or whether C99
or classic C is specified.
Currently, that isn't that case when using clang on NetBSD due in part to
the quoted lines from cdefs.h.
Clang also has an issue w/ incompatibility with gcc, and that has been
reported as clang/llvm bug #27189.
The problem doesn't happen on other OSes (e.g. Linux, OpenIndiana) that do
not define __func__ as __PRETTY_FUNCTION__ as NetBSD cdefs.h does.
Minimizing the footprint of the issue requires fixing NetBSD cdefs.h *and*
matching the clang definition of __PRETTY_FUNCTION__ to that of gcc.
If the relevant lines in cdefs.h are dropped or suitably revised, new
NetBSD systems won't show the problem even with existing versions of clang.
If clang is modified to treat __PRETTY_FUNCTION__ exactly like gcc for
pre-C99 compilation, then users of the modified clang won't see the problem
even on NetBSD with cdefs.h having the quoted lines.
NetBSD systems in the wild with the quoted cdefs.h lines using existing
versions of clang will remain affected even if both contributing factors
are addressed, although there is a work-around
(-D__PRETTY_FUNCTION__=__FUNCTION__).
Ignoring C++ as:
1. not relevant to case discussed, which is compiling for C pre-C99.
2. C++ may well require something for __PRETTY_FUNCTION__ other than what
clang/gcc produce with -std=c89 (clang) or -std=c90 (gcc) [which is the
case under discussion].
3. C code and definitions should be protected from C++ by (not present in
the relevant part of cdefs.h)
#if __cplusplus
// C++ stuff here
#else
/* C stuff here */
#endif
On Tue, Apr 5, 2016 at 8:20 AM, Joerg Sonnenberger <joerg%britannica.bec.de@localhost>
wrote:
> The following reply was made to PR standards/51044; it has been noted by
> GNATS.
>
> From: Joerg Sonnenberger <joerg%britannica.bec.de@localhost>
> To: gnats-bugs%NetBSD.org@localhost
> Cc:
> Subject: Re: standards/51044: NetBSD cdefs.h defines __func__ incompatibly
> with C99
> Date: Tue, 5 Apr 2016 14:17:53 +0200
>
> On Tue, Apr 05, 2016 at 10:00:00AM +0000, bruce.lilly%gmail.com@localhost wrote:
> > >Fix:
> > Don't define __func__ as __PRETTY_FUNCTION__ (ever!)
>
> While this whole code drop can likely just be dropped nowadays, since we
> default to C99 in the base system, the PR is invalid as the behavior is
> entirely within the limits of an implementation. C89 doesn't contain
> __func__, so code making assumptions about it is wrong to depend on the
> implementation namespace. C++ before C++11 doesn't contain __func__, but
> gets __PRETTY_FUNCTION__, which is quite reasonable. C++11 itself
> doesn't specify what __func__ should give, so again __PRETTY_FUNCTION__
> is quite fine.
>
> Joerg
>
>
--001a113eb424c56f20052fbd0a20
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div><div><div><div><div><div><div>Dropping the quote=
d lines from cdefs.h would fix the problem for new systems (i.e. with cdefs=
.h w/o those lines).<br></div><br></div>Agreed that the assumptions made by=
those lines may be (indeed in the case documented, are) wrong.<br><br></di=
v><div>Anybody compiling with gcc or (ostensibly) gcc-compatible compilers =
who cares about __func__ with pre-C99 code is probably already using the do=
cumented gcc work-around, and doesn't need to have cdefs.h foul that up=
.<br><br></div><div>The ideal is to have simple code (such as in the sample=
s) that produces the same result regardless of (POSIX-compliant) OS or comp=
iler or whether C99 or classic C is specified.<br></div><div>Currently, tha=
t isn't that case when using clang on NetBSD due in part to the quoted =
lines from cdefs.h.<br></div><div>Clang also has an issue w/ incompatibilit=
y with gcc, and that has been reported as clang/llvm bug #27189.<br><br></d=
iv><div>The problem doesn't happen on other OSes (e.g. Linux, OpenIndia=
na) that do not define __func__ as __PRETTY_FUNCTION__ as NetBSD cdefs.h do=
es.<br></div><div><br></div><div>Minimizing the footprint of the issue requ=
ires fixing NetBSD cdefs.h *and* matching the clang definition of __PRETTY_=
FUNCTION__ to that of gcc.<br></div>If the relevant lines in cdefs.h are dr=
opped or suitably revised, new NetBSD systems won't show the problem ev=
en with existing versions of clang.<br><div>If clang is modified to treat _=
_PRETTY_FUNCTION__ exactly like gcc for pre-C99 compilation, then users of =
the modified clang won't see the problem even on NetBSD with cdefs.h ha=
ving the quoted lines.<br><div>NetBSD systems in the wild with the quoted c=
defs.h lines using=20
existing versions of clang will remain affected even if both contributing f=
actors are addressed, although there is a=20
work-around (-D__PRETTY_FUNCTION__=3D__FUNCTION__).<br></div></div><div><br=
></div>Ignoring C++ as:<br></div>1. not relevant to case discussed, which i=
s compiling for C pre-C99.<br></div>2. C++ may well require something for _=
_PRETTY_FUNCTION__ other than what clang/gcc produce with -std=3Dc89 (clang=
) or -std=3Dc90 (gcc) [which is the case under discussion].<br></div>3. C c=
ode and definitions should be protected from C++ by (not present in the rel=
evant part of cdefs.h)<br></div>=C2=A0=C2=A0=C2=A0 #if __cplusplus<br></div=
><div>=C2=A0=C2=A0=C2=A0 // C++ stuff here<br></div><div>=C2=A0=C2=A0=C2=A0=
#else<br></div><div>=C2=A0=C2=A0=C2=A0 /* C stuff here */<br></div>=C2=A0=
=C2=A0=C2=A0 #endif<br></div><div class=3D"gmail_extra"><br><div class=3D"g=
mail_quote">On Tue, Apr 5, 2016 at 8:20 AM, Joerg Sonnenberger <span dir=3D=
"ltr"><<a href=3D"mailto:joerg%britannica.bec.de@localhost"; target=3D"_blank">joer=
g%britannica.bec.de@localhost</a>></span> wrote:<br><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
>The following reply was made to PR standards/51044; it has been noted by G=
NATS.<br>
<br>
From: Joerg Sonnenberger <<a href=3D"mailto:joerg%britannica.bec.de@localhost";>joe=
rg%britannica.bec.de@localhost</a>><br>
To: gnats-bugs%NetBSD.org@localhost<br>
Cc:<br>
Subject: Re: standards/51044: NetBSD cdefs.h defines __func__ incompatibly<=
br>
=C2=A0with C99<br>
Date: Tue, 5 Apr 2016 14:17:53 +0200<br>
<br>
=C2=A0On Tue, Apr 05, 2016 at 10:00:00AM +0000, <a href=3D"mailto:bruce.lil=
ly%gmail.com@localhost">bruce.lilly%gmail.com@localhost</a> wrote:<br>
=C2=A0> >Fix:<br>
=C2=A0> Don't define __func__ as __PRETTY_FUNCTION__ (ever!)<br>
<br>
=C2=A0While this whole code drop can likely just be dropped nowadays, since=
we<br>
=C2=A0default to C99 in the base system, the PR is invalid as the behavior =
is<br>
=C2=A0entirely within the limits of an implementation. C89 doesn't cont=
ain<br>
=C2=A0__func__, so code making assumptions about it is wrong to depend on t=
he<br>
=C2=A0implementation namespace. C++ before C++11 doesn't contain __func=
__, but<br>
=C2=A0gets __PRETTY_FUNCTION__, which is quite reasonable. C++11 itself<br>
=C2=A0doesn't specify what __func__ should give, so again __PRETTY_FUNC=
TION__<br>
=C2=A0is quite fine.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
=C2=A0Joerg<br>
<br>
</font></span></blockquote></div><br></div>
--001a113eb424c56f20052fbd0a20--
Home |
Main Index |
Thread Index |
Old Index