Not logged in
Log in now
Create an account
Subscribe to LWN
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
PostgreSQL 9.3 beta: Federated databases and more
LWN.net Weekly Edition for May 9, 2013
A turning point for GNU libc
Posted Mar 28, 2012 16:25 UTC (Wed) by JoeBuck (subscriber, #2330)
If you want to use strlcpy/strlcat, you already can; you just have to link with a different library (libbsd). If your project standards forbid strncat, #define it to DONT_USE_strncat_YOU_IDIOT in some widely-included header.
Posted Mar 28, 2012 16:47 UTC (Wed) by nix (subscriber, #2304)
Posted Mar 29, 2012 2:05 UTC (Thu) by apoelstra (subscriber, #75205)
Plus, these sorts of pedantic programmers are certainly capable of using strcat safely (which is possible to do, unlike with gets()).
Posted Jan 1, 2013 13:25 UTC (Tue) by shentino (subscriber, #76459)
anyone trying to replace them will do nothing more than just rock the boat.
Posted Mar 28, 2012 17:17 UTC (Wed) by arjan (subscriber, #36785)
(and btw the glibc version of strcpy and co actually do buffer overflow checks with the help of the gcc compiler for various cases)
Posted Mar 28, 2012 17:47 UTC (Wed) by jzbiciak (✭ supporter ✭, #5246)
Posted Mar 28, 2012 19:17 UTC (Wed) by cmorgan (guest, #71980)
Posted Mar 28, 2012 21:00 UTC (Wed) by atai (subscriber, #10977)
Posted Mar 29, 2012 12:38 UTC (Thu) by nix (subscriber, #2304)
Posted Mar 29, 2012 12:57 UTC (Thu) by mina86 (subscriber, #68442)
Posted Mar 29, 2012 20:30 UTC (Thu) by nix (subscriber, #2304)
Posted Mar 29, 2012 0:02 UTC (Thu) by Richard_J_Neill (subscriber, #23093)
A leading zero practically NEVER means the user intentionally wants to work in base 8, it just means they did something naive with string-splitting or data-entry. Perhaps the user entered the reading from a digital-scale, complete with leading zero. Or they took a string such as $7.09 and parsed it as "trim off the leading '$', split at the decimal point, multiply the first number by 100, and add the two together, to get a result in cents".
I'd consider that leading-zero-means-octal is a nasty case of technical debt that we still be causing bugs in 100 years if we don't fix it.
One way would be to support a new notation, similar to the "0x" notation. Numbers beginning "0o" (that's a letter 'o') would be recognised as octal. Then we spend 5 years transitioning the existing legitimate instances of octal numbers (file permissions) to the new syntax, then for 5 years, make the old format illegal, then in 10 years time, we can start treating leading zeros as they were meant to be treated.
[At the same time, can I plead for a "streq()" function, being defined as "!strcmp()" ]
Posted Mar 29, 2012 4:52 UTC (Thu) by slashdot (guest, #22014)
AFAICT POSIX 2008 forbids that, and requires atoi to support only decimal numbers.
At any rate, changing that is probably highly unwise, as it might break stuff.
Posted Mar 29, 2012 10:37 UTC (Thu) by Richard_J_Neill (subscriber, #23093)
I agree that we can't change it right away. That's why I suggest adding a new prefix, "0o" to be used in the very rare case where the programmer deliberately intends to use octal. That wouldn't break anything, and over perhaps 5 years, people could migrate.
Posted Mar 29, 2012 20:53 UTC (Thu) by cmccabe (guest, #60281)
It's a standard, like the QWERTY keyboard and the English language. Sorry, it's not going anywhere.
> At the same time, can I plead for a "streq()" function, being defined
> as "!strcmp()"
Why don't you define it yourself? It's a one-line function.
Posted Mar 29, 2012 21:03 UTC (Thu) by cmccabe (guest, #60281)
However, strcpy also has its uses. Sometimes you really do know the length of the source string, and you know it fits in the destination.
strcpy() / strlcpy() / asprintf()
Posted Mar 30, 2012 11:07 UTC (Fri) by abacus (guest, #49001)
Posted Mar 30, 2012 12:50 UTC (Fri) by nix (subscriber, #2304)
Posted Mar 30, 2012 15:56 UTC (Fri) by nybble41 (subscriber, #55106)
It seems to me like asprintf() should be easy to implement in terms of two calls to vsnprintf():
int vasprintf(char **strp, const char *fmt, va_list ap)
/* Determine the amount of memory required to format the string */
/* vsnprintf() returns the space required, but only stores the NUL. */
bytes = vsnprintf(&nul, 1, fmt, ap_copy);
if (bytes <= 0)
str = (char*)malloc(bytes);
/* Format the string into the destination buffer */
bytes = vsnprintf(str, bytes, fmt, ap);
if (bytes <= 0)
/* No errors; store pointer to destination buffer and return its size. */
*strp = str;
int asprintf(char **strp, const char *fmt, ...)
bytes = vasprintf(strp, fmt, ap);
Is there any reason this implementation wouldn't work? (Ignoring minor issues/typos; I'm making this up as I go.)
Posted Mar 30, 2012 17:50 UTC (Fri) by nix (subscriber, #2304)
Posted Mar 31, 2012 21:10 UTC (Sat) by lacos (subscriber, #70616)
(SUSv1 doesn't have snprintf(). Once I needed to compile a glibc-oriented program on OSF/1 4.0E, which one might have consider a reference implementation of SUSv1, even though it wasn't formally certified. The program needed snprintf() and there was none, so I printed the string first to /dev/null (for the size), then fully to a malloc()'d area, then copied the bytes that had room, then free()'d the area. ... Sorry if this sounds trivial and/or retarded :))
Posted Apr 5, 2012 8:36 UTC (Thu) by nix (subscriber, #2304)
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds