Why Is Escaping Data Considered So Magical?

[Carl Banks]

On Jun 30, 2:55 am, Cameron Simpson <c... at zip.com.au> wrote:
> On 29Jun2010 21:49, Carl Banks <pavlovevide... at gmail.com> wrote:
> | On Jun 28, 2:44 am, Gregory Ewing <greg.ew... at 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, which inclines me to disbelieve this convention ever
> | really existed.  If it did, there would be functions to support it.
> |
> | For that matter, I'm not really inclined to believe bytes were *that*
> | precious in those days.
>
> Jeez. PDP-11s, 16 bit addressing, tiny tiny disc drives!
>
> The original V7 (and probably earlier) UNIX filesystem has 16 byte directory
> entries: 2 bytes for an inode and 14 bytes for the name. You could use 14
> bytes of that name, and strncpy makes it effective to work with that data
> structure.  
>
> Shortening something already only 14 bytes (the name) _is_ a big ask,
> and it is well work the unusual convention in play.

You are talking about fixed-length memory records, not strings.

I'm saying that bytes were not so precious that, when you operate on
*actual strings*, that you need to desperately cut off nul terminators
to save space.


> | The obvious rationale behind strncpy's stupid behavior is that it's
> | not a string function at all, but a memory block function, that stops
> | at a NUL in case you don't care what's after the NUL in a block.  But
> | it leads you to believe it's a string function by it's name.
>
> Bah. It's for copying a _string_ into a _buffer_! Strangely, since it
> starts with a string (NUL-terminated byte sequence) it begins with
> "str". And it _is_ copying, but not into another string.

I'm going to disagree.  The input of strncpy can be either a string or
a memory block, and the output can only a memory block.  In other
words, neither the source nor destination has to be a string.  This is
a memory block function, not a string function.  The correct name for
this function should have been memcpytonul.

Even if you disagree, then you must admit it should have been called
strcpytobuf.  Nothing about the name strncpy gives the slightest
suggestion that the destination is not a string.  Based on analogy
from other str functions, none of which have any sources or
destinations that are memory blocks, one would logically expect that
strncpy's destination was a string.  It defies common sense.

And there should have been an actual, correctly working strncpy in the
standard library that copies and truncates actual strings.


> It is special purpose but perfectly reasonable for the problem at hand.

The usefulness of strncpy's behavior for writing fixed-length memory
blocks is not in question here.  The thing that's mind-bogglingly
stupid is that the function that does this is called "strncpy".


Carl Banks