On 23/01/2024 22:48, Lawrence D'Oliveiro wrote:
> On Tue, 23 Jan 2024 15:27:25 GMT, Scott Lurndal wrote:
>
>> Huge security hole.
>
> That was the point I was trying to make, but it seemed to go over
> somebody’s head ...

If that "somebody" was me, then the it did not go over my head - it went
far to the side of it.

Chained strcat has no more and no less of a risk of buffer overflows
than any other way of combining strings without checking their size and
ensuring you have an appropriately sized destination buffer. There is
no more and no less danger in doing "strcat(strcat(strcat(..." than in
doing "strcat" at all - either you have ensured your buffers and sizes
are safe and that all your pointers really are terminated strings, or
you have a risk of overrun.

And a risk of overrun is not in any way synonymous with "huge security
hole". It is a risk of failure. How big that risk is depends on the
likelihood of the strings being too big for the target buffer, which is
totally impossible to estimate without real code - "huge" is no more
appropriate than "tiny". Similarly, the consequences of an overrun are
impossible to judge without much more information - thus "security hole"
is no more appropriate than guessing any other kind of failure. "Huge
security hole" and "tiny risk of pixel colour glitches" are equally
valid, due to a total lack of knowledge of the rest of the program.

So when someone has used "strcat" in a Usenet post, I would assume that
real-world code would take appropriate care to be sure the arguments
point to valid strings, and the destinations have enough space. It's
not unlikely that the real code actually uses "strncat" to reduce the
risk of failures.

And I assumed that you, too, know all this and considered it a side
issue, orthogonal to the actual interesting point about nested strcat
calls. That is, concatenating strings with nested strcat calls scales
as O(n²), while alternatives such as "sprintf" or nested "stpcpy" (POSIX
but not standard C) scales O(n).

But you might not have known that gcc will convert a set of nested
"strcat" calls into a call to "strlen" followed by calls to "stpcpy".

On 24/01/2024 00:31, Lawrence D'Oliveiro wrote:
> On Tue, 23 Jan 2024 22:28:03 -0000 (UTC), Blue-Maned_Hawk wrote:
>
>> strncat
>
> If you can figure out how to use it properly.

strncat is nasty, as "n" is the maximum number of characters to copy,
not the size of the destination buffer. strncpy is nasty as it wastes
effort needlessly writing null characters once the string is copied, and
does not guarantee a terminating null.

The common standard C str* functions are, IMHO, extraordinarily poorly
specified, and could easily have been very much easier to use correctly
and efficiently.

On 24.01.2024 09:40, David Brown wrote:
>
> [...] That is, concatenating strings with nested strcat calls scales
> as O(n²), while alternatives such as "sprintf" or nested "stpcpy" (POSIX
> but not standard C) scales O(n).

First I mistook "stpcpy" for a typo, but hey, it's there. - Nice, and
good to know it's there. Thanks.

> But you might not have known that gcc will convert a set of nested
> "strcat" calls into a call to "strlen" followed by calls to "stpcpy".

Interesting.

Janis

On 24/01/2024 13:53, Janis Papanagnou wrote:
> On 24.01.2024 09:40, David Brown wrote:
>>
>> [...] That is, concatenating strings with nested strcat calls scales
>> as O(n²), while alternatives such as "sprintf" or nested "stpcpy" (POSIX
>> but not standard C) scales O(n).
>
> First I mistook "stpcpy" for a typo, but hey, it's there. - Nice, and
> good to know it's there. Thanks.

Note that it exists in POSIX (and therefore in most C libraries), but it
is not standard C.

>
>> But you might not have known that gcc will convert a set of nested
>> "strcat" calls into a call to "strlen" followed by calls to "stpcpy".
>
> Interesting.
>

gcc (and clang, and no doubt other compilers) can optimise a number of
standard library calls. This is, IME, very useful.

On 2024-01-24, David Brown <david.brown@hesbynett.no> wrote:
> On 24/01/2024 00:31, Lawrence D'Oliveiro wrote:
>> On Tue, 23 Jan 2024 22:28:03 -0000 (UTC), Blue-Maned_Hawk wrote:
>>
>>> strncat
>>
>> If you can figure out how to use it properly.
>
> strncat is nasty, as "n" is the maximum number of characters to copy,
> not the size of the destination buffer. strncpy is nasty as it wastes
> effort needlessly writing null characters once the string is copied, and
> does not guarantee a terminating null.

I always assumed strncpy was intended for the following kind of
situation: placing a string into a non-null-terminated array intended
for data communication or storage.

struct rec {
char first_name[15]; // null padded, not terminated
char last_name[15]; // likewise
// ...
};

Internally, you work with these as null terminated strings,
copying them out to [16] buffers.

These get written to disk, so the data has to be cleanly
padded with nulls, even if a single null is enough to
terminate short fields. You don't want random garbage
from memory written out; it could be a security problem.

strncpy helps to prepare the fields:

char fn[16]; // null terminated
/* ... */
strncpy(rec->first_name, fn, 15); // correct in all cases

as well as in the other direction

strncpy(fn, rec->first_name, 15); // could use strcpy

I'm using hard-coded constants for simplicity.

If fn was initialized to zeros, and always used correctly to
store a null-terminated string, there is nothing to do;
a null is guaranteed to always be present at fn[15].
Otherwise we need fn[15] = 0.

So I think that's the nice use case for strncpy; unfortunately, over
most of its life, it got clumsily used for other use cases.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

Kaz Kylheku <433-929-6894@kylheku.com> writes:
>On 2024-01-24, David Brown <david.brown@hesbynett.no> wrote:
>> On 24/01/2024 00:31, Lawrence D'Oliveiro wrote:
>>> On Tue, 23 Jan 2024 22:28:03 -0000 (UTC), Blue-Maned_Hawk wrote:
>>>
>>>> strncat
>>>
>>> If you can figure out how to use it properly.
>>
>> strncat is nasty, as "n" is the maximum number of characters to copy,
>> not the size of the destination buffer. strncpy is nasty as it wastes
>> effort needlessly writing null characters once the string is copied, and
>> does not guarantee a terminating null.
>
>I always assumed strncpy was intended for the following kind of
>situation: placing a string into a non-null-terminated array intended
>for data communication or storage.
>
>struct rec {
> char first_name[15]; // null padded, not terminated
> char last_name[15]; // likewise
> // ...
>};
>
>Internally, you work with these as null terminated strings,
>copying them out to [16] buffers.
>
>These get written to disk, so the data has to be cleanly
>padded with nulls, even if a single null is enough to
>terminate short fields. You don't want random garbage
>from memory written out; it could be a security problem.
>
>strncpy helps to prepare the fields:
>
> char fn[16]; // null terminated
> /* ... */
> strncpy(rec->first_name, fn, 15); // correct in all cases

snprintf(fn, sizeof(fn), "%s", rec->first_name) is also correct in
all cases (and can tell you if it would have overflowed, if you're
interested).

Kaz Kylheku <433-929-6894@kylheku.com> writes:
> On 2024-01-24, David Brown <david.brown@hesbynett.no> wrote:
>> On 24/01/2024 00:31, Lawrence D'Oliveiro wrote:
>>> On Tue, 23 Jan 2024 22:28:03 -0000 (UTC), Blue-Maned_Hawk wrote:
>>>
>>>> strncat
>>>
>>> If you can figure out how to use it properly.
>>
>> strncat is nasty, as "n" is the maximum number of characters to copy,
>> not the size of the destination buffer. strncpy is nasty as it wastes
>> effort needlessly writing null characters once the string is copied, and
>> does not guarantee a terminating null.
>
> I always assumed strncpy was intended for the following kind of
> situation: placing a string into a non-null-terminated array intended
> for data communication or storage.
>
> struct rec {
> char first_name[15]; // null padded, not terminated
> char last_name[15]; // likewise
> // ...
> };
>
> Internally, you work with these as null terminated strings,
> copying them out to [16] buffers.
>
> These get written to disk, so the data has to be cleanly
> padded with nulls, even if a single null is enough to
> terminate short fields. You don't want random garbage
> from memory written out; it could be a security problem.
>
> strncpy helps to prepare the fields:
>
> char fn[16]; // null terminated
> /* ... */
> strncpy(rec->first_name, fn, 15); // correct in all cases
>
> as well as in the other direction
>
> strncpy(fn, rec->first_name, 15); // could use strcpy
>
> I'm using hard-coded constants for simplicity.
>
> If fn was initialized to zeros, and always used correctly to
> store a null-terminated string, there is nothing to do;
> a null is guaranteed to always be present at fn[15].
> Otherwise we need fn[15] = 0.
>
> So I think that's the nice use case for strncpy; unfortunately, over
> most of its life, it got clumsily used for other use cases.

Agreed. The name "strncpy" suggests that it's just "strcpy" with bounds
checking, but it isn't. "strncat", on the other hand, pretty much *is*
"strcat" with bounds checking. (And calling strncat() after setting the
initial character of the target to '\0' actually does what some people
assume strncpy should do.)

I wrote about this a few years ago:

https://github.com/Keith-S-Thompson/the-flat-trantor-society/blob/master/002-strncpy.md

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

On 1/19/2024 9:59 AM, Malcolm McLean wrote:
> Who has actually used a variadic function for any purpose other than
> implementing printf-style format strings?
>

Iirc, I used variadic parameters back during my experiments with C99
generics a while back. IIRC, I posted about them on this group. They
should be on topic for this thread if I can find my old posts.

On Wed, 24 Jan 2024 09:40:34 +0100, David Brown wrote:

> Chained strcat ...

Not that you chained it, but that you used it at all.

On Wed, 24 Jan 2024 09:52:59 +0100, David Brown wrote:

> The common standard C str* functions are, IMHO, extraordinarily poorly
> specified, and could easily have been very much easier to use correctly
> and efficiently.

True. Which is why it is better to look a little beyond them
<https://manpages.debian.org/7/string_copying.en.html>.

On 1/24/24 14:50, Kaz Kylheku wrote:
....
> I always assumed strncpy was intended for the following kind of
> situation: placing a string into a non-null-terminated array intended
> for data communication or storage.
>
> struct rec {
> char first_name[15]; // null padded, not terminated
> char last_name[15]; // likewise
> // ...
> };
>
> Internally, you work with these as null terminated strings,
> copying them out to [16] buffers.
>
> These get written to disk, so the data has to be cleanly
> padded with nulls, even if a single null is enough to
> terminate short fields. You don't want random garbage
> from memory written out; it could be a security problem.

That is precisely the situation that led to me using strncpy().
Apparently, the need to pad the space with nulls is the part that most
people find odd. In addition to the security issues you mention, there's
also a problem with comparing test output files from different runs - if
they don't get nulled out, the unused parts get garbage in them, and
routines for comparing the files will find different garbage in two
files that should be identical.
The other aspect of the situation I was working with that people found
odd was that I was sometimes copying a string that might be too long for
the destination, and it was OK if I had to truncate it to fit. That was
due to the fact that the relevant string served essentially as a
comment, rather than being a critical part of the output file.

On 25/01/2024 01:11, Lawrence D'Oliveiro wrote:
> On Wed, 24 Jan 2024 09:40:34 +0100, David Brown wrote:
>
>> Chained strcat ...
>
> Not that you chained it, but that you used it at all.

If you think people are missing your points, perhaps you should try
expressing them rather than berating people for not reading your mind.

"strcat" is a perfectly good and useful library function. Like every
function, without exception, you need to know what it does and that it
is appropriate and correct to use it in your code.

On 24/01/2024 20:50, Kaz Kylheku wrote:
> On 2024-01-24, David Brown <david.brown@hesbynett.no> wrote:
>> On 24/01/2024 00:31, Lawrence D'Oliveiro wrote:
>>> On Tue, 23 Jan 2024 22:28:03 -0000 (UTC), Blue-Maned_Hawk wrote:
>>>
>>>> strncat
>>>
>>> If you can figure out how to use it properly.
>>
>> strncat is nasty, as "n" is the maximum number of characters to copy,
>> not the size of the destination buffer. strncpy is nasty as it wastes
>> effort needlessly writing null characters once the string is copied, and
>> does not guarantee a terminating null.
>
> I always assumed strncpy was intended for the following kind of
> situation: placing a string into a non-null-terminated array intended
> for data communication or storage.
>
> struct rec {
> char first_name[15]; // null padded, not terminated
> char last_name[15]; // likewise
> // ...
> };
>
> Internally, you work with these as null terminated strings,
> copying them out to [16] buffers.

(I'd consider using 16 char arrays and saying that they /are/ null
terminated. (Of course you don't trust that when you read records from
files - you either check it, or force it, before using the record.)
Much of your copying can then be very efficient inlined memcpy()'s - if
you even need to copy data into and out of buffers. I understand this
is about good use-cases for strncpy, rather than about ideal
implementations of record storage. But if good uses of strncpy could be
replaced by better code that does not use it, it weakens the
justification for strncpy being defined the way it is.)

>
> These get written to disk, so the data has to be cleanly
> padded with nulls, even if a single null is enough to
> terminate short fields. You don't want random garbage
> from memory written out; it could be a security problem.

Certainly strncpy would be good for such purposes. It is quite common,
however, to use memset to first zero out such structs - that is simple,
efficient (usually more efficient than strncpy would be), and also
clears any padding.

But I am not saying that strncpy, as it is defined, has no uses - I am
saying that it would be more useful if it had been defined to copy a
string with a hard limit on the number of characters to avoid any risk
of overrun, without copying or padding unnecessarily, and with a
guaranteed zero termination:

char * string_copy(char * restrict dest,
const char * restrict src, size_t n)
{ while (n--) {
char c = *src++;
*dest++ = c;
if (!c) return dest - 1;
}
*(dest - 1) = '\0';
return dest - 1;
}

(This also returns a pointer to the terminating null, which I see as
more useful than a copy of "dest".)

>
> strncpy helps to prepare the fields:
>
> char fn[16]; // null terminated
> /* ... */
> strncpy(rec->first_name, fn, 15); // correct in all cases
>
> as well as in the other direction
>
> strncpy(fn, rec->first_name, 15); // could use strcpy

"strcpy" might be a risk if you have read the record from a file and
can't be sure it is null terminated. "strncpy" avoids that risk, but
inefficiently and unnecessarily does extra padding. I would say it is
better here to use memcpy(), then "fn[15] = '\0';".

>
> I'm using hard-coded constants for simplicity.

Sure.

>
> If fn was initialized to zeros, and always used correctly to
> store a null-terminated string, there is nothing to do;
> a null is guaranteed to always be present at fn[15].
> Otherwise we need fn[15] = 0.
>
> So I think that's the nice use case for strncpy; unfortunately, over
> most of its life, it got clumsily used for other use cases.
>

I certainly do think strncpy, as it is defined, has its uses. And in
many situations it is a better choice than strcpy, even if it is less
efficient. But I think it was a wasted opportunity - I think "strncpy"
should have been defined the way I defined "string_copy" above (though
for consistency it should return its first argument - and a matching
stpncpy function could be made that returns an end pointer).

Then a separate "strpad(char * s, size_t n)" function could be made that
takes a string pointer and ensures that everything beyond the
terminating '\0' is cleared to zero up to a total of n characters. (If
there is no zero in those n characters, the data is left unchanged.)

On 24/01/2024 21:14, Keith Thompson wrote:

> Agreed. The name "strncpy" suggests that it's just "strcpy" with bounds
> checking, but it isn't. "strncat", on the other hand, pretty much *is*
> "strcat" with bounds checking. (And calling strncat() after setting the
> initial character of the target to '\0' actually does what some people
> assume strncpy should do.)
>
> I wrote about this a few years ago:
>
> https://github.com/Keith-S-Thompson/the-flat-trantor-society/blob/master/002-strncpy.md
>

You could add a paragraph about how strncat also does not do what people
might expect it to do. The "n" is the maximum number of characters to
copy, not including the terminating zero. The most obvious user
expectation would be that "n" is the size of the destination buffer, and
the second most obvious expectation would be that it is the maximum
number of characters copied /including/ the terminating zero.

So IMHO, strncat does /roughly/ what you expect when you have set the
first character of the target to 0 (once you remember to subtract 1 from
the size), but is otherwise surprising in its behaviour. It should have
been better.

Oh, and there should have been a "strnlen" too. It would do the same as
"memchr(s, '\0', n)", but have a better name. It's in POSIX and should
be in the C standards.

On 25/01/2024 01:12, Lawrence D'Oliveiro wrote:
> On Wed, 24 Jan 2024 09:52:59 +0100, David Brown wrote:
>
>> The common standard C str* functions are, IMHO, extraordinarily poorly
>> specified, and could easily have been very much easier to use correctly
>> and efficiently.
>
> True. Which is why it is better to look a little beyond them
> <https://manpages.debian.org/7/string_copying.en.html>.

Yes.

Unfortunately, most of these are not standard C library functions. Some
are common extensions in many libraries, others are, AFIAK, not so common.

Still, thanks for that reference. I'll have a look at them and see if
they are potentially useful to me and available with the C libraries I
usually use.

On 24/01/2024 08:40, David Brown wrote:
>
> So when someone has used "strcat" in a Usenet post, I would assume that
> real-world code would take appropriate care to be sure the arguments
> point to valid strings, and the destinations have enough space.  It's
> not unlikely that the real code actually uses "strncat" to reduce the
> risk of failures.
>
By doing that you are replacing undefined behaviour with defined incorrect
behaviour. Now undefined behaviour will often be correct behaviour, in the
context that the program as whole is bugged. The result "segmentation fault"
is less wrong than "the answeer to the life, universe and everything is 4"
(we added an extra e to "answer" and so ran out of buffer).
Not always and sometimes wrong results are better than no results, for
example in video game. Better send 4 baddies rather than 42 than shut
down the game.

--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On 2024-01-25, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
> On 24/01/2024 08:40, David Brown wrote:
>>
>> So when someone has used "strcat" in a Usenet post, I would assume that
>> real-world code would take appropriate care to be sure the arguments
>> point to valid strings, and the destinations have enough space.  It's
>> not unlikely that the real code actually uses "strncat" to reduce the
>> risk of failures.
>>
> By doing that you are replacing undefined behaviour with defined incorrect
> behaviour. Now undefined behaviour will often be correct behaviour, in the
> context that the program as whole is bugged. The result "segmentation fault"
> is less wrong than "the answeer to the life, universe and everything is 4"
> (we added an extra e to "answer" and so ran out of buffer).

You're only saying that a documented extension which traps undefined
behavior is better than a silent incorrect result.

The crude memory violation checks resulting in a segmentation fault are
not even remotely close to a reliable trap for undefined behavior.

If you think that the situation when some datum does not fit into a
buffer is a grave situation, such that the program must not continue
executing, then you should use a copying function that issues a
diagnostic and aborts in that situation (like an assert failure).

I work on embedded firmware where that is the case. For string copying,
we have have functions that will abort if truncation would take place,
that return an indication that truncation took place, allowing the
caller to decide what to do, and ones that silently truncate.

Under no circumstances do you want to just overflow the buffer and hope
that a segfault will catch it.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

On 2024-01-25, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
> On 24/01/2024 08:40, David Brown wrote:
>>
>> So when someone has used "strcat" in a Usenet post, I would assume that
>> real-world code would take appropriate care to be sure the arguments
>> point to valid strings, and the destinations have enough space.  It's
>> not unlikely that the real code actually uses "strncat" to reduce the
>> risk of failures.
>>
> By doing that you are replacing undefined behaviour with defined incorrect
> behaviour. Now undefined behaviour will often be correct behaviour, in the
> context that the program as whole is bugged. The result "segmentation fault"
> is less wrong than "the answeer to the life, universe and everything is 4"
> (we added an extra e to "answer" and so ran out of buffer).

That depends entirely upon what the correct behavior was supposed to be.
In the contexts where I used strncat(), the correct behavior specified
by the requirements for the program I was writing when the input string
was too big to fit in the output field was to put as much of the input
string as possible into the output field, including the start of the
string, even if that meant not having a terminating null character, but
that it must not go past the end of the field, even if that meant
chopping off the end of the string.

David Brown <david.brown@hesbynett.no> writes:
[...]
> I certainly do think strncpy, as it is defined, has its uses. And in
> many situations it is a better choice than strcpy, even if it is less
> efficient. But I think it was a wasted opportunity - I think
> "strncpy" should have been defined the way I defined "string_copy"
> above (though for consistency it should return its first argument -
> and a matching stpncpy function could be made that returns an end
> pointer).
>
> Then a separate "strpad(char * s, size_t n)" function could be made
> that takes a string pointer and ensures that everything beyond the
> terminating '\0' is cleared to zero up to a total of n characters.
> (If there is no zero in those n characters, the data is left
> unchanged.)

To summarize, the problem with strncpy() is not its behavior, but its
name. The name suggests that it's something that it isn't, a
bound-checked version of strcpy(). It *is* useful for certain niche
cases. For example, I think early Unix filesystems stored file names in
a 14-byte field padded with zero or more null characters; that may have
been *the* primary use case for strncpy().

If I had a time machine, I might rename "strncpy()" to, say, "strpad()"
(not the same as the "strpad() you suggest above) and define a new
"strncpy()" that behaves like setting the first character of the target
to '\0' and then calling strncat().

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

David Brown <david.brown@hesbynett.no> writes:
> On 24/01/2024 21:14, Keith Thompson wrote:
>
>> Agreed. The name "strncpy" suggests that it's just "strcpy" with bounds
>> checking, but it isn't. "strncat", on the other hand, pretty much *is*
>> "strcat" with bounds checking. (And calling strncat() after setting the
>> initial character of the target to '\0' actually does what some people
>> assume strncpy should do.)
>> I wrote about this a few years ago:
>> https://github.com/Keith-S-Thompson/the-flat-trantor-society/blob/master/002-strncpy.md
>
> You could add a paragraph about how strncat also does not do what
> people might expect it to do. The "n" is the maximum number of
> characters to copy, not including the terminating zero. The most
> obvious user expectation would be that "n" is the size of the
> destination buffer, and the second most obvious expectation would be
> that it is the maximum number of characters copied /including/ the
> terminating zero.

Thanks, I've added that as a TODO.

When I get the proverbial Round Tuit, I'll also cite the C99 Rationale:

strncpy was initially introduced into the C library to deal
with fixed-length name fields in structures such as directory
entries. Such fields are not used in the same way as strings:
the trailing null is unnecessary for a maximum-length field,
and setting trailing bytes for shorter names to null assures
efficient field-wise comparisons. strncpy is not by origin a
"bounded strcpy," and the Committee preferred to recognize
existing practice rather than alter the function to better suit
it to such use.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

On 25/01/2024 18:46, Malcolm McLean wrote:
> On 24/01/2024 08:40, David Brown wrote:
>>
>> So when someone has used "strcat" in a Usenet post, I would assume
>> that real-world code would take appropriate care to be sure the
>> arguments point to valid strings, and the destinations have enough
>> space.  It's not unlikely that the real code actually uses "strncat"
>> to reduce the risk of failures.
>>
> By doing that you are replacing undefined behaviour with defined incorrect
> behaviour. Now undefined behaviour will often be correct behaviour, in the
> context that the program as whole is bugged. The result "segmentation
> fault"
> is less wrong than "the answeer to the life, universe and everything is 4"
> (we added an extra e to "answer" and so ran out of buffer).
> Not always and sometimes wrong results are better than no results, for
> example in video game. Better send 4 baddies rather than 42 than shut
> down the game.
>

That is all totally dependent on the situation, and the requirements.

A buffer overrun is always wrong. It might not have major consequences,
and those consequences might even be predictable (like a segmentation
fault), though it is highly unlikely.

Cutting a string short might also be an error - in which case, if it is
a possibility, you should add checking somewhere. (It's typically quite
easy to do here - if you want to limit your strings to 20 characters,
including the null terminator, make your buffer 21 characters, clear it,
and use that for your limits for strncat, strncpy or snprintf as
appropriate. Then when you are done, check index 19 of your buffer - if
it is not a null character, your string has been truncated.)

Or cutting a string short might be perfectly correct and acceptable
behaviour.

Any generalisation here will be wrong much of the time.

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On 24/01/2024 08:40, David Brown wrote:
>> So when someone has used "strcat" in a Usenet post, I would assume
>> that real-world code would take appropriate care to be sure the
>> arguments point to valid strings, and the destinations have enough
>> space.  It's not unlikely that the real code actually uses "strncat"
>> to reduce the risk of failures.
>>
> By doing that you are replacing undefined behaviour with defined incorrect
> behaviour.

What "incorrect behaviour" are you talking about?

David's premise is that the arguments point to valid strings and the
destinations have enough space. Given that premise, strcat() works.

char s[10];
strcat(s, "hello");
puts(s);

What incorrect behavior do you see in the above code?

Of course ensuring that the arguments are valid and the destination is
big enough is sometimes easier said than done, but that's not the point.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

On Thu, 25 Jan 2024 09:22:16 +0100, David Brown wrote:

> "strcat" is a perfectly good and useful library function.

Can’t think of any situation where it is worth using.

In article <uouejj$2ei7i$1@dont-email.me>,
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>On Thu, 25 Jan 2024 09:22:16 +0100, David Brown wrote:
>
>> "strcat" is a perfectly good and useful library function.
>
>Can't think of any situation where it is worth using.

Well, that's clearly your problem, not ours.

As the kids say, it's a "you problem".

--
The randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/ModernXtian

On 2024-01-25, Kenny McCormack <gazelle@shell.xmission.com> wrote:
> In article <uouejj$2ei7i$1@dont-email.me>,
> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>On Thu, 25 Jan 2024 09:22:16 +0100, David Brown wrote:
>>
>>> "strcat" is a perfectly good and useful library function.
>>
>>Can't think of any situation where it is worth using.
>
> Well, that's clearly your problem, not ours.
>
> As the kids say, it's a "you problem".

In the entire TXR project:

$ git grep strcat
stream.c: strcat(num_buf, ".0");

What's that? This is when the format function, in certain circumstances,
is printing a floating-point number that has no fractional part,
and the representation has to be machine-readable to reproduce the
same object (Lisp "print-read consistency").

This strcat is justified because num_buf is 512 characters. We know
in this line of code that that it holds a printed floating-point value
in decimal, and we know that double's exponent caps out at E+308. There
cannot be an IEEE 64 bit floating-point double with anywhere near 512
digits to the left of the decimal point on all the platforms.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca