| |||||||||||||
A turning point for GNU libcA turning point for GNU libcPosted Mar 28, 2012 16:47 UTC (Wed) by nix (subscriber, #2304)In reply to: A turning point for GNU libc by cmorgan Parent article: A turning point for GNU libc
Deprecating strcat/strcpy is vanishingly unlikely. They're unpleasant functions, but they are ubiquitous. Adding __attribute__((deprecated)) to them or making the linker warn at link time (as is done for e.g. gets()) would do nothing other than cause those warnings to be universally ignored.
(Log in to post comments)
A turning point for GNU libc Posted Mar 29, 2012 2:05 UTC (Thu) by apoelstra (subscriber, #75205) [Link]
Is there an ANSI C alternative to strcat and friends? Because if not, such warnings will greatly irritate programmers who compile with -Werror (as well as the usual -W -Wall -Wextra and friends) and -ansi.
Plus, these sorts of pedantic programmers are certainly capable of using strcat safely (which is possible to do, unlike with gets()).
A turning point for GNU libc Posted Jan 1, 2013 13:25 UTC (Tue) by shentino (subscriber, #76459) [Link]
They are here to stay, just like the win32 api, x86 architecture, and the qwerty keyboard layout.
anyone trying to replace them will do nothing more than just rock the boat.
|
|||||||||||||