| |||||||||||||
A turning point for GNU libcA turning point for GNU libcPosted Mar 28, 2012 22:47 UTC (Wed) by wahern (subscriber, #37304)In reply to: A turning point for GNU libc by HelloWorld Parent article: A turning point for GNU libc
By that logic, people would also be better off using C++. In many cases it'd be easier to port a C project to C++ than to adopt glib in all its monstrous glory.
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.
(Log in to post comments)
A turning point for GNU libc Posted Mar 29, 2012 0:48 UTC (Thu) by geofft (subscriber, #59789) [Link] 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?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.)
A turning point for GNU libc Posted Mar 29, 2012 11:47 UTC (Thu) by jnareb (subscriber, #46500) [Link]
> 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.
Nb. Git went the way of creating own 'strbuf' micro-library for string manipulation.
A turning point for GNU libc Posted Mar 29, 2012 7:13 UTC (Thu) by BenHutchings (subscriber, #37955) [Link] 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.
A turning point for GNU libc Posted Mar 30, 2012 3:55 UTC (Fri) by wahern (subscriber, #37304) [Link]
Fair enough. I was listing common buffer size macros off the top of my head. But that's beside the point. The others, and many more, are meaningful. Programming, like life, is full of arbitrary limits, and programming as if you'll ever need to meaningfully store a 1MB path name often leads to needless complexity, and complexity breeds bugs.
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.
A turning point for GNU libc Posted Mar 29, 2012 16:12 UTC (Thu) by HelloWorld (guest, #56129) [Link]
> 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?
Glib provides a hell of a lot more than just a sane (well, sane by C standards) string implementation.
> Some people like coding in plain, vanilla C, especially when our code has to be ported to many different environments.
> Do my enum-to-human-readable-string mappings need an indefinite buffer?
A turning point for GNU libc Posted Mar 30, 2012 22:24 UTC (Fri) by jengelh (subscriber, #33263) [Link]
>Glib provides a hell of a lot more than just a sane (well, sane by C standards) string implementation.
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.
A turning point for GNU libc Posted Apr 5, 2012 15:32 UTC (Thu) by welinder (guest, #4699) [Link]
> char is standardized by C, you know
Really?
What, exactly, is standardized about char in C?
* it's a numeric type.
char c = 0; /* valid */
A turning point for GNU libc Posted Apr 5, 2012 16:33 UTC (Thu) by nybble41 (subscriber, #55106) [Link]
True, but gchar is defined as a typedef for char, so it adds no additional guarantees. Why not just use char? At least "guchar" is shorter than "unsigned char"; I see no benefit at all in using gchar.
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.
|
|||||||||||||