On 8/24/16 1:30 PM, Bryan Drewery wrote: > 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 <bdrew...@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 cause >>>>> 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. >> >> /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 stuff. > > 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.
Ah no it is specific, great: > xinstall.o: In function `makelink': > /root/svn/releng/11.0/usr.bin/xinstall/xinstall.c:688: warning: warning: this > program uses basename(const char *), which is deprecated and thread-unsafe. Not sure what I think about it though. > > We would need to move old_dirname/basename into their own .c files to > use this I think. Playing around with that... > >> >>> 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 the >>> __old_dirname() prototype via __generic and errors in the wrong case. > > -- Regards, Bryan Drewery
signature.asc
Description: OpenPGP digital signature