"Charlie Gordon" <news@chqrlie.org> writes:
> "Keith Thompson" <kst-u@mib.org> a écrit dans le message de news:
> lnd4unt6i8.fsf@nuthaus.mib.org...
>> Richard <rgrdev@gmail.com> writes:
[...]
>>> ,----
>>> | The strncpy() function is similar, except that at most n bytes of src
>>> | are copied. Warning: If there is no null byte among the first n
>>> | bytes of src, the string placed in dest will not be null
>>> | terminated.
>>> `----
>>>
>>> The "string placed in dest" is the clue.
>>
>> It's a clue that the person who wrote that description of strncpy()
>> got it wrong. A "string" in C is null terminated by definition; if
>> it's not null terminated; it's not a string. C99 7.1.1p1: "A string
>> is a contiguous sequence of characters terminated by and including the
>> first null character."
>>
>> The portion you quoted also doesn't say that null characters are
>> appended if the source array is a string shorter than n characters;
>> perhaps you just didn't include that part.
>>
>> The existence of documentation that incorrectly describes the
>> strncpy() function doesn't prove that it's a "string function". Out
>> of curiosity, where did you get that description? If it's from a
>> current system, you might consider submitting a bug report.
>
> The linux man page for strncpy contains that language. Shame on them.

Some Linux systems have that wording, but at least one (RHEL 3) has:

The strncpy() function is similar, except that not more than n
bytes of src are copied. Thus, if there is no null byte among the
first n bytes of src, the result will not be null-terminated.

[snip]

>> In other words, this:
>> strncpy(dest, source, n);
>> would be equivalent to this:
>> dest[0] = '\0';
>> strncat(dest, source, n);
>
> NO! strncat is misleading too, but in a different way: it copies no more
> than n characters to the end of dest, and appends a '\0' terminator. Thus
> strlcpy(dest, source, n) would be equivalent to

I think you mean "strncpy(dest, source, n).

> if (n > 0) {
> dest[0] = '\0';
> strncat(dest, source, n - 1);
> }

You're right.

[snip]

>> Some questions:
>>
>> What *exactly* do you mean by the phrase "string function"?
>
> Pretty much yours.

Do you mean that you don't know (or much care) what the phrase "string
function" means? Because that's my definition.

>> Does strncpy() meet your definition?
>
> Not really: it fits my definition of broken, ill-fated, useless,
> to-be-deprecated function.
>
>> Do you use strncpy() in your own code?
>
> I most certainly don't ! I have a #define in our in house include files to
> prevent any use of this function a few other ones such as gets.

The above questions were actually meant to be directed at Richard Riley.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Keith Thompson <ks...@mib.org> wrote:
> > > > For: the name starts with str and it is described
> > > > in 7.21 String Handling
> > > >
> > > > Against: the fact that it does not take or produce
> > > > a string
> > >
> > > s/does/need/. It _can_ be used to work exclusively with
> > > real C strings - it just takes more work and attention
> > > than should be necessary.
> > >
> > > IMO it _is_ a string function, but a severely broken one.
> >
> > Hence my advice: just don't use it.
>
> I disagree.
>
> A string function deals with a certain data structure, called
> a "string" by the C standard, consisting of "a contiguous
> sequence of characters terminated by and including the first
> null character" (C99 7.1.1p1).
>
> strncpy() deals with a different data structure,

But still caters for strings.

> one that has no name that I'm aware of, consisting of an
> array of N characters of which the first M are significant,
> and the remaining N-M characters are all set to '\0',
> where M may be equal to N. Such a data structure happens
> to contain a "string" *unless* M==N.

In the old days, this is what I called a record field, though
in some cases a space was used for padding rather than 0.
Fixed width fields, and checksums too apparently, are a thing
of the past.

<snip>
> The facts that this relatively obscure data structure is
> supported in the standard, that there's only one standard
> function that supports it,

Huh? fread, fwrite, scanf, printf, memcpy, memcmp... to name
a few. And that's obviously excluding other constructs like
zero initialisation.

> and that that function has a name that misleadingly implies
> that it's a string function, are all historical accidents.

Merely historical in my opinion. I don't believe they were
an accident at the time. In those days, people were using
fixed width fields, and they were squeezing as much out of
limited memory as possible.

The function _can_ be used to copy prefixes of strings to
a string. And it _will_ terminate the destination with a
sufficiently large enough buffer. If you're going to say
that it's not a string function because you can't guarantee
the source or destination will be strings, then you may as
well say that strcpy is not a string function!

> I don't recall anyone claiming that the standard C library
> is a model of coherent design.

Although apparently single byte character constants being
int and not single byte characters is perfectly coherent!

--
Peter

Peter Nilsson wrote:
> Keith Thompson <ks...@mib.org> wrote:
....
>> one that has no name that I'm aware of, consisting of an
>> array of N characters of which the first M are significant,
>> and the remaining N-M characters are all set to '\0',
>> where M may be equal to N. Such a data structure happens
>> to contain a "string" *unless* M==N.
....
>> The facts that this relatively obscure data structure is
>> supported in the standard, that there's only one standard
>> function that supports it,
>
> Huh? fread, fwrite, scanf, printf, memcpy, memcmp... to name

Neither fread() nor scanf() stops reading at a null character, nor does
either one fill the rest of a character array with null characters after
having read one. Neither fwrite() nor memcpy() stop writing at a null
character, nor does either one write extra null characters from that
point onward. memcmp() doesn't pay any special attention to null
characters. printf() can be forced to stop writing a string at a fixed
number of bytes, but the corresponding argument is still required to be
a null-terminated string, which is not guaranteed for this data
structure. Only strncpy() does these things, which makes it a very
anomalous function.

....
> The function _can_ be used to copy prefixes of strings to
> a string. And it _will_ terminate the destination with a
> sufficiently large enough buffer. If you're going to say
> that it's not a string function because you can't guarantee
> the source or destination will be strings, then you may as
> well say that strcpy is not a string function!

strcpy() requires that its input be a string, and guarantees, when all
of it's requirements have been met, that it's output is also a string.

>> I don't recall anyone claiming that the standard C library
>> is a model of coherent design.
>
> Although apparently single byte character constants being
> int and not single byte characters is perfectly coherent!

Well, the standard C languange isn't exactly a model of coherent design
either; it has too much history to cope with to allow that.

On Nov 12, 10:00 pm, Peter Nilsson <ai...@acay.com.au> wrote:

> The function _can_ be used to copy prefixes of strings to
> a string. And it _will_ terminate the destination with a
> sufficiently large enough buffer. If you're going to say
> that it's not a string function because you can't guarantee
> the source or destination will be strings, then you may as
> well say that strcpy is not a string function!
>


Hardly. If you use strcpy correctly, then you *can* guarantee that
that the source and destination will be strings. (If you do not
use it correctly you can guarantee exactly nothing, don't stop the
presses) If you use strncpy correctly then you cannot guarantee that
the source and destination will be strings.

- William Hughes