Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
A turning point for GNU libc
Posted Mar 28, 2012 22:47 UTC (Wed) by wahern (subscriber, #37304)
Saying "just use glib" is cargo cult programming, IMNSHO. Why would I use a 300k SLoC library just for a saner way to copy a string? Some people like coding in plain, vanilla C, especially when our code has to be ported to many different environments. Getting strlcpy into glibc would be just one less extra burden to carry when trying to write sane, simple, secure code.
And also, why do I need a dynamic string object? Is Linux generally ever going to support file names longer than NAME_MAX characters, or paths longer than PATH_MAX characters? Are DNS labels magically going to become longer than 63 characters, or domains longer than 255 characters? Do my enum-to-human-readable-string mappings need an indefinite buffer?
Most people who code in C aren't doing unbounded string operations. Not every C application or library is an editor or a text processor. In fact, very few are. Don't confuse "C-strings" with "strings". People don't use strcpy or strlcpy to manipulate "strings" (the abstract computer science concept); they use them to manipulate C-strings, a very narrow and well-defined data type which in practice is almost always bounded by a rather small limit.
Posted Mar 29, 2012 0:48 UTC (Thu) by geofft (subscriber, #59789)
Because it's a saner way to do _everything_. If you just want strings, you can go use the Better String Library (bstring), but then you need to go find a better everything else library, too.
Besides, you're cargo-culting a one million SLoC library called glibc, and arguing for the inclusion of more functions in it... if you like "plain, vanilla C", you're welcome to copy strings without glibc. :) (Or with another standard library like dietlibc.)
Posted Mar 29, 2012 11:47 UTC (Thu) by jnareb (subscriber, #46500)
Nb. Git went the way of creating own 'strbuf' micro-library for string manipulation.
Posted Mar 29, 2012 7:13 UTC (Thu) by BenHutchings (subscriber, #37955)
Is Linux generally ever going to support file names longer than NAME_MAX characters, or paths longer than PATH_MAX characters?
Absolutely - PATH_MAX is a totally meaningless value.
Posted Mar 30, 2012 3:55 UTC (Fri) by wahern (subscriber, #37304)
But let people continue to use strcpy, and let the exploits continue to roll in. Fortunately they've slowed down over the years, thanks to alternatives like snprintf and people copy+pasting strlcpy, and not so much because people are passing glib string objects to library routines.
Posted Mar 29, 2012 16:12 UTC (Thu) by HelloWorld (guest, #56129)
> Some people like coding in plain, vanilla C, especially when our code has to be ported to many different environments.
Well, you don't seem to be one of them, as strlcpy is clearly *not* standard C. Besides, how is providing strlcpy going to help with portability? Microsofts C implementation doesn't include it either, so you can't rely on it either way.
> Do my enum-to-human-readable-string mappings need an indefinite buffer?
Of course not, but for that use case, strcpy is perfectly sufficient as the required buffer length is known at compile time.
Posted Mar 30, 2012 22:24 UTC (Fri) by jengelh (subscriber, #33263)
I agree - it has utterly pointless typedefs like gchar (char is standardized by C, you know). Hiding an indirection (behind gpointer) is not nice either.
Posted Apr 5, 2012 15:32 UTC (Thu) by welinder (guest, #4699)
What, exactly, is standardized about char in C?
* it's a numeric type.
* it is distinct from signed char and unsigned char, but has the same
range of values as one of the two
* it's a magic type for aliasing
* it's the element type of "foo"
char c = 0; /* valid */
char c = -1; /* valid, but might not read as -1 */
char c = 128; /* implementation dependent: either valid or undefined */
Posted Apr 5, 2012 16:33 UTC (Thu) by nybble41 (subscriber, #55106)
If you want guaranteed ranges, uint8_t and int8_t are standardized in C99 as integer types with exactly eight bits and (in the signed case) two's-complement representation. Both definitions are required unless the implementation has no compatible integer type.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds