Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 24 Aug 2016 13:30:37 -0700
From:      Bryan Drewery <bdrewery@FreeBSD.org>
To:        Eric van Gyzen <vangyzen@FreeBSD.org>, Ed Schouten <ed@nuxi.nl>
Cc:        svn-src-head@freebsd.org, jilles@freebsd.org, svn-src-all@freebsd.org, src-committers <src-committers@freebsd.org>, Ed Schouten <ed@freebsd.org>
Subject:   Re: svn commit: r303988 - head/lib/libc/gen
Message-ID:  <7d2b7798-d444-427e-4790-3133977d339c@FreeBSD.org>
In-Reply-To: <8ef5b79d-5e7e-d5be-db8e-ae5284abdc31@FreeBSD.org>
References:  <201608120703.u7C73whf007189@repo.freebsd.org> <d23b295a-1902-193c-dee6-ba49ebd77280@FreeBSD.org> <9ae1c2eb-02ad-b8fe-6aff-7e17e955607a@FreeBSD.org> <CABh_MKkxD3OTF7VO9Rq_eZyqHPN%2BxVws3q3dsH2R3DfZ343kFw@mail.gmail.com> <2632f5f8-d765-3df7-74d7-da878eb4b7a8@FreeBSD.org> <CABh_MKm_YQ3bJD19Cz1vBCGr=YxuzctXV6F1iqMASkSx-PsVMw@mail.gmail.com> <d606b841-dda9-488e-ab35-a9289668d2c4@FreeBSD.org> <CABh_MKmg9XqSg44P8i_S0jit_2tV8-Zyknu6gefMaxXN9piyxQ@mail.gmail.com> <62adcb77-490e-0691-0942-9218c1d55b68@FreeBSD.org> <b53255ae-9afc-dbee-1b60-d3b9619dde3c@FreeBSD.org> <8ef5b79d-5e7e-d5be-db8e-ae5284abdc31@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--PFHHruc4sOWS1kGAoJvSJxwO2RxXRV2ha
Content-Type: multipart/mixed; boundary="GIenxGvqghToVuSqx75NenGlQqTLrGtu7"
From: Bryan Drewery <bdrewery@FreeBSD.org>
To: Eric van Gyzen <vangyzen@FreeBSD.org>, Ed Schouten <ed@nuxi.nl>
Cc: svn-src-head@freebsd.org, jilles@freebsd.org, svn-src-all@freebsd.org,
 src-committers <src-committers@freebsd.org>, Ed Schouten <ed@freebsd.org>
Message-ID: <7d2b7798-d444-427e-4790-3133977d339c@FreeBSD.org>
Subject: Re: svn commit: r303988 - head/lib/libc/gen
References: <201608120703.u7C73whf007189@repo.freebsd.org>
 <d23b295a-1902-193c-dee6-ba49ebd77280@FreeBSD.org>
 <9ae1c2eb-02ad-b8fe-6aff-7e17e955607a@FreeBSD.org>
 <CABh_MKkxD3OTF7VO9Rq_eZyqHPN+xVws3q3dsH2R3DfZ343kFw@mail.gmail.com>
 <2632f5f8-d765-3df7-74d7-da878eb4b7a8@FreeBSD.org>
 <CABh_MKm_YQ3bJD19Cz1vBCGr=YxuzctXV6F1iqMASkSx-PsVMw@mail.gmail.com>
 <d606b841-dda9-488e-ab35-a9289668d2c4@FreeBSD.org>
 <CABh_MKmg9XqSg44P8i_S0jit_2tV8-Zyknu6gefMaxXN9piyxQ@mail.gmail.com>
 <62adcb77-490e-0691-0942-9218c1d55b68@FreeBSD.org>
 <b53255ae-9afc-dbee-1b60-d3b9619dde3c@FreeBSD.org>
 <8ef5b79d-5e7e-d5be-db8e-ae5284abdc31@FreeBSD.org>
In-Reply-To: <8ef5b79d-5e7e-d5be-db8e-ae5284abdc31@FreeBSD.org>

--GIenxGvqghToVuSqx75NenGlQqTLrGtu7
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On 8/24/16 1:26 PM, Eric van Gyzen wrote:
> On 08/24/2016 15:16, Bryan Drewery wrote:
>> On 8/24/16 1:12 PM, Eric van Gyzen wrote:
>>> On 08/24/2016 15:01, Ed Schouten wrote:
>>>> 2016-08-24 21:53 GMT+02:00 Bryan Drewery <bdrewery@freebsd.org>:
>>>>> Is it possible to cause the use of these old prototypes to print a
>>>>> warning and note that they are deprecated/unsafe?
>>>>
>>>> That's a good question. In theory, we could annotate these functions=

>>>> with __attribute__((__deprecated__)):
>>>>
>>>> https://gcc.gnu.org/onlinedocs/gcc-3.3.4/gcc/Type-Attributes.html
>>>>
>>>> But I'm actually too afraid to use it. In the worst case it may caus=
e
>>>> the compiler to generate a warning even when basename()/dirname() is=

>>>> used correctly, as __old_* will still be part of the compiled
>>>> expression.
>>>
>>> Could __warn_references() be used, as libc currently does for gets() =
and
>>> others?
>>>
>>> Eric
>>>
>>
>> /usr/include/stdio.h:extern char *gets (char *__s) __wur
>> __attribute_deprecated__;
>> /usr/include/x86_64-linux-gnu/sys/cdefs.h:# define
>> __attribute_deprecated__ __attribute__ ((__deprecated__))
>>
>> __wur being warning about unused result.
>=20
> /usr/src/lib/libc/stdio/gets.c:__warn_references(gets, "warning: this
> program uses gets(), which is unsafe.");

Ah! Ours! I misunderstood and thought about the FORTIFY_SOURCE glibc stuf=
f.

This is a linker warning.  It would not be as obvious which line is the
problem but would still tell the user they have potentially unsafe code.
 They also may not care if not using threads.

We would need to move old_dirname/basename into their own .c files to
use this I think. Playing around with that...

>=20
>> As for actually using it here, I tried adding it onto the
>> _old_dirname/basename prototypes.  It produces an error, fine, in the
>> bootstrap build for xinstall it would not error, great.  However, for
>> building xinstall on head where it will not use the __old_dirname and
>> will use the new dirname@FBSD_1.5, it _still_ complains about using th=
e
>> __old_dirname() prototype via __generic and errors in the wrong case.


--=20
Regards,
Bryan Drewery


--GIenxGvqghToVuSqx75NenGlQqTLrGtu7--

--PFHHruc4sOWS1kGAoJvSJxwO2RxXRV2ha
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQEcBAEBCgAGBQJXvgPuAAoJEDXXcbtuRpfP3z0H/05MD7icwot25ALx+t9zntDA
GkVG7CK+yIRYxTAX0ml/NoHi4Y3xbzlj38QVovl7Sp76QOgHyQQWNqwLy20LbuH8
/O6TuNNLReAkr45RputjVND8Bc8F3bxhOxL/wMsO1M53UEwbKUtRYnxcpxXC1zxx
LwnTCyJTZu087r6vQDsJZuJeA3v5Fptw49U3B/sIAggndCHAOElQT4urCXqEAJqb
w+l/4W5OzzFVSuaHH31RYOjOO2TusIoVrjB5YVYTacDIdFPMFn0MgHX8jVefkdU7
n+ntKjOy1GRVRJQVD+YoaAW1+37IIcu9/cm5VEH9oCd/aMej/6YZXr8hSPgfBR4=
=YtwC
-----END PGP SIGNATURE-----

--PFHHruc4sOWS1kGAoJvSJxwO2RxXRV2ha--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7d2b7798-d444-427e-4790-3133977d339c>