Prev: Build unordered list in HTML from a python list
Next: 1.5.1 Py_XDECREF Core
From: Jorgen Grahn on 30 Jun 2010 05:18
On Wed, 2010-06-30, Carl Banks wrote:
> On Jun 28, 2:44�am, Gregory Ewing <greg.ew...(a)canterbury.ac.nz> wrote:
>> Carl Banks wrote:
>> > Indeed, strncpy does not copy that final NUL if it's at or beyond the
>> > nth element. �Probably the most mind-bogglingly stupid thing about the
>> > standard C library, which has lots of mind-boggling stupidity.
>>
>> I don't think it was as stupid as that back when C was
>> designed. Every byte of memory was precious in those days,
>> and if you had, say, 10 bytes allocated for a string, you
>> wanted to be able to use all 10 of them for useful data.
>>
>> So the convention was that a NUL byte was used to mark
>> the end of the string *if it didn't fill all the available
>> space*.
>
> I can't think of any function in the standard library that observes
> that convention,

Me neither, except strncpy(), according to above.

> which inclines me to disbelieve this convention ever
> really existed. If it did, there would be functions to support it.

Maybe others existed, but got killed off early. That would make
strncpy() a living fossil, like the Coelacanth ...

> For that matter, I'm not really inclined to believe bytes were *that*
> precious in those days.

It's somewhat believable. If I handled thousands of student names in a
big C array char[30][], I would resent the fact that 1/30 of the
memory was wasted on NUL bytes. I'm sure plenty of people have done what
Gregory suggests ... but it's not clear that strncpy() was designed to
support those people.

I suppose it's all lost in history.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
 | 
Pages: 1
Prev: Build unordered list in HTML from a python list
Next: 1.5.1 Py_XDECREF Core