A turning point for GNU libc [LWN.net]

A turning point for GNU libc

Posted Mar 29, 2012 16:12 UTC (Thu) by HelloWorld (guest, #56129)
In reply to: A turning point for GNU libc by wahern
Parent article: A turning point for GNU libc

> 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.
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.

(Log in to post comments)

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.
* 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"
* sizeof(char)==1

char c = 0; /* valid */
char c = -1; /* valid, but might not read as -1 */
char c = 128; /* implementation dependent: either valid or undefined */

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.