I agree with most of the criticisms they make.

I agree that pointer and length is better than null-terminated strings (although it is difficult in C, and as they mention you will have to use a macro (or some additional functions) to work this in C).

Making the C standard library directly against syscalls is also a good idea, although in some cases you might have an implementation that needs to not do this for some reason, generally it is better for the standard library directly against syscalls.

FILE object is sometimes useful especially if you have functions such as fopencookie and open_memstream; but it might be useful (although probably not with C) to be able to optimize parts of a program that only use a single implementation of the FILE interface (or a subset of its functions, e.g. that does not use seeking).

▲

alfiedotwtf 15 minutes ago | parent | next [-]

Making every C call a system call is not a good idea at all - think about malloc() etc - the OS shouldn’t care about individual allocations and only worry about providing brk() etc. otherwise, performance will die if you’re doing a thousand system calls per second!

▲

fithisux an hour ago | parent | prev [-]

Null terminated strings have some merits but they should be a completely different data type like in Freebasic.

▲

Sankozi 30 minutes ago | parent [-]

Are there other merits than availability of literals in C?

It seems like one of the worst data structures ever - lookup complexity of a linked list with a expansion complexity of an array list with security problems added as a bonus.

	▲	boricj a few seconds ago \| parent [-]
		It's fine as a serialization/deserialization primitive for on-disk files, as long as the NULL character is invalid. String tables in most object file formats work like that, a concatenated series of ASCIIZ strings. One byte of overhead (NUL), requires only an offset into one to address a string and you can share strings with common suffixes. It's a very compact layout.