On Thu, 25 Jan 2024 20:29:55 -0000 (UTC), Kenny McCormack 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.

“You may say that I’m a dreamer;
But I’m not the only one.”

David Brown 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.

sizeof outbuf - strlen(outbuf)

--
Blue-Maned_Hawk│shortens to
Hawk│/
blu.mɛin.dÊ°ak/
│he/him/his/himself/Mr.
blue-maned_hawk.srht.site

On 25/01/2024 19:40, Keith Thompson wrote:
> 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.
>
The proposal is to replace strcat with strncat() to improve behaviour
when the bufffer overflows. So the premise is that the program is bugged
and the overflow is unintentional, and there is no ideal behaviour.
By calling strncat you force the program to truncate the string to fit
the buffer. Which in reality might often be the best thing to do,
because many strings are intended for human reading, and a human reader
can guess what has happened and supply the missing characters. But the
results are always wrong, they are defined to be wrong.
With undefined behaviour they are undefined (by C). But the two most
likely results are either than the buffer will in fact have room and the
program will works as intended, though it won't be correct, or that the
UB will be defined by the platform as to give a message that there has
been a memory access error. Which is the correct result, given the
constraint that the program itself is incorrect.

Occasionally, as in my example, string truncation can be catastrophic,
because it changes the string to a reasonable but incorrect meaning.

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

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>On 25/01/2024 19:40, Keith Thompson wrote:
>> 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.
>>
>The proposal is to replace strcat with strncat() to improve behaviour
>when the bufffer overflows. So the premise is that the program is bugged
>and the overflow is unintentional, and there is no ideal behaviour.
>By calling strncat you force the program to truncate the string to fit
>the buffer. Which in reality might often be the best thing to do,
>because many strings are intended for human reading, and a human reader
>can guess what has happened and supply the missing characters. But the
>results are always wrong, they are defined to be wrong.
>With undefined behaviour they are undefined (by C). But the two most
>likely results are either than the buffer will in fact have room and the
>program will works as intended, though it won't be correct, or that the
>UB will be defined by the platform as to give a message that there has
>been a memory access error.

Actually, it's highly _unlikely_ that an implementation would "give a
message that there has been a memory access error", unless the buffer access
crossed a page boundary and hit a not-present page. The majority
of cases, strcat would just corrupt whatever followed the buffer,
which often would be on the stack, where said corruption could lead
to exploits even leaving aside the UB whenever the corrupt data
is used.

strcat should not be used. strncat isn't a suitable substitute.

snprintf does work quite well as a substitute for strcat.

On 2024-01-25, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
> The proposal is to replace strcat with strncat() to improve behaviour
> when the bufffer overflows. So the premise is that the program is bugged
> and the overflow is unintentional, and there is no ideal behaviour.
> By calling strncat you force the program to truncate the string to fit
> the buffer. Which in reality might often be the best thing to do,
> because many strings are intended for human reading, and a human reader
> can guess what has happened and supply the missing characters. But the
> results are always wrong, they are defined to be wrong.

Yes; you have to pick one behavior for the function and ... USE
SOMETHING ELSE for the other behaviors. Wow, eh?

(Or have ioctl-like codes to select a behavior in one function,
which is really like multipel functions in one.)

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

On 26/01/2024 00:25, Kaz Kylheku wrote:
> On 2024-01-25, Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
>> The proposal is to replace strcat with strncat() to improve behaviour
>> when the bufffer overflows. So the premise is that the program is bugged
>> and the overflow is unintentional, and there is no ideal behaviour.
>> By calling strncat you force the program to truncate the string to fit
>> the buffer. Which in reality might often be the best thing to do,
>> because many strings are intended for human reading, and a human reader
>> can guess what has happened and supply the missing characters. But the
>> results are always wrong, they are defined to be wrong.
>
> Yes; you have to pick one behavior for the function and ... USE
> SOMETHING ELSE for the other behaviors. Wow, eh?
>
> (Or have ioctl-like codes to select a behavior in one function,
> which is really like multipel functions in one.)
>
You don't seem to understand that David Brown's premise was that the
program was bugged. And that's entirely reasonable. Programs do ship
with bugs. The question is whether there are any strategies we can use
to limit the damage.

And strncat rather than strcat is one such strategy. And David Brown is
probably right that, in many cases, it will be a good strategy. But I
was pointing out that this won't always hold.

But there is no way of making an incorrect program correct without
correcting the error. It's not so much a case of picking a behaviour, as
choosing what is likely to be the least damaging wrong behaviour.

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

On Fri, 26 Jan 2024 00:15:32 GMT, Scott Lurndal wrote:

> strcat should not be used. strncat isn't a suitable substitute.

The BSDs tried to come up with some alternatives, e.g. strlcat(3).

See also the code for stpecpy here
<https://manpages.debian.org/7/string_copying.en.html>.

> snprintf does work quite well as a substitute for strcat.

I’m assuming you’re not suggesting passing an arbitrary string (e.g. user-
entered) for the format ...

On 26/01/2024 00:36, Malcolm McLean wrote:
> On 25/01/2024 19:40, Keith Thompson wrote:
>> 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.
>>
> The proposal is to replace strcat with strncat() to improve behaviour
> when the bufffer overflows.

Yes.

> So the premise is that the program is bugged
> and the overflow is unintentional,

Yes.

> and there is no ideal behaviour.

Incorrect.

You started out okay, but then drew an unwarranted conclusion from your
premises.

Buffer overflow means the original "strcat" program had a bug if it was
expected to deal correctly with longer strings - longer strings caused
UB, and that is never correct execution.

Let's say the program is trying to concatenate two strings into a 10
character buffer. There are, roughly, three was to specify this :

1. It should give the concatenation for any two strings whose total
length does not exceed 9 characters.

2. It should give the concatenation for any two strings.

3. It should up to the first 9 characters of the hypothetical unlimited
length concatenation of any two strings.

If the specification is 1, then the "strcat" version is fine - it is
ideal behaviour. Garbage in, garbage out - programs are only required
to be used according to their specifications.

If the specification is 2, then it is impossible to write a program with
the required behaviour.

If the specification is 3, then strncat will give the ideal behaviour.

The "ideal behaviour" is dependent on the specification for the program,
and that has not been given here. Without the specification or
requirements, it makes no sense to talk about whether there is or is not
an "ideal behaviour", whether it is possible or not, or whether any
given program fulfils it.

On 26/01/2024 01:15, Scott Lurndal wrote:

> strcat should not be used. strncat isn't a suitable substitute.
>

Either can be used, if you know exactly what they do and they are
suitable for the task.

> snprintf does work quite well as a substitute for strcat.
>

It is a completely useless substitute in some situations - it has
massively greater overhead, rendering it unusable in situations where
efficiency is important.

There is no single "right" answer here, nor are there "always wrong"
answers. "stcat should not be used" is as wrong a generalisation as
"strcat is always fine". Understand the functions, and use them
appropriately - just like any other programming task.

I am slightly surprised to be writing this in reply to a post by you -
you are not exactly a newbie to programming, or to understanding that
sometimes efficiency is critical, or to understanding that it's safe to
use a function if and only if you have ensured it is safe to use that
function.

On 25/01/2024 19:59, Keith Thompson wrote:
> 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().
>

I would go for a longer name - perhaps strncpy_padded(). Other than
that, I agree with you.

On 25/01/2024 23:46, Blue-Maned_Hawk wrote:
> David Brown 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.
>
> sizeof outbuf - strlen(outbuf)
>

sizeof outbuf - strlen(outbuf) - 1

strncat adds a \0 to the end, after copying up to n characters.

And you have to check this to make sure it is not less than zero -
remembering that all the types here are "size_t" and thus unsigned -
before deciding if you can call strncat at all.

As I said, nasty.

And for a naïve use, you are scanning through the string currently
"outbuf" to find its current length, then calling strncat on it which
will re-scan the same string again to find the end point for starting
the copy. And it will uselessly return the pointer to "outbuf", so that
if you want to find the length of the combined string (perhaps for
concatenating another string), you have to re-scan the whole thing again.

Nasty and inefficient.

On 26/01/2024 15:12, David Brown wrote:
> On 26/01/2024 00:36, Malcolm McLean wrote:
>> On 25/01/2024 19:40, Keith Thompson wrote:
>>> 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.
>>>
>> The proposal is to replace strcat with strncat() to improve behaviour
>> when the bufffer overflows.
>
> Yes.
>
>> So the premise is that the program is bugged and the overflow is
>> unintentional,
>
> Yes.
>
>> and there is no ideal behaviour.
>
> Incorrect.
>
> You started out okay, but then drew an unwarranted conclusion from your
> premises.
>
> Buffer overflow means the original "strcat" program had a bug if it was
> expected to deal correctly with longer strings - longer strings caused
> UB, and that is never correct execution.
>
> Let's say the program is trying to concatenate two strings into a 10
> character buffer.  There are, roughly, three was to specify this :
>
> 1. It should give the concatenation for any two strings whose total
> length does not exceed 9 characters.
>
> 2. It should give the concatenation for any two strings.
>
> 3. It should up to the first 9 characters of the hypothetical unlimited
> length concatenation of any two strings.
>
> If the specification is 1, then the "strcat" version is fine - it is
> ideal behaviour.  Garbage in, garbage out - programs are only required
> to be used according to their specifications.
>
> If the specification is 2, then it is impossible to write a program with
> the required behaviour.
>
> If the specification is 3, then strncat will give the ideal behaviour.
>
>
> The "ideal behaviour" is dependent on the specification for the program,
> and that has not been given here.  Without the specification or
> requirements, it makes no sense to talk about whether there is or is not
> an "ideal behaviour", whether it is possible or not, or whether any
> given program fulfils it.
>
>
No. The program is trying to concatentate "strcat " and "strncat" into a
ten byte buffer, and the specification is that the buffer shall hold
"strcat strncat". But since that is more than ten bytes that is
impossible, the specification cannot be met and therefore the program is
bugged.
Now of course you can say "we can only deal with ten characters,
threefore the specification is that the program should output "strcat
st". The user will figure it out." Which he may well do and that would
be fair enough. And now you have no bug.

But often that wouldn't be acceptable as plan. The program is bugged and
it will need to be fixed. So the question is, what is the least bad
thing we can do. And instead of specifications, we have stratgems. Throw
out the contents of the buffer and report some sort of error message.
May or may not be acceptable. Truncate and hope that the truncated
message is not too catastrophic. Or push the whole message past the end
of the buffer, cross your fingers, and hope. And there's quite a bit to
be said for the last strategy.

A bugged program is incorrect and cannot be made correct by declaring
defined but wrong behaviour to be correct, unless it is genuinely the
case that, in the act of so declaring, we make it correct.

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

On 27/01/2024 06:37, Malcolm McLean wrote:
> On 26/01/2024 15:12, David Brown wrote:
>> On 26/01/2024 00:36, Malcolm McLean wrote:
>>> On 25/01/2024 19:40, Keith Thompson wrote:
>>>> 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.
>>>>
>>> The proposal is to replace strcat with strncat() to improve behaviour
>>> when the bufffer overflows.
>>
>> Yes.
>>
>>> So the premise is that the program is bugged and the overflow is
>>> unintentional,
>>
>> Yes.
>>
>>> and there is no ideal behaviour.
>>
>> Incorrect.
>>
>> You started out okay, but then drew an unwarranted conclusion from
>> your premises.
>>
>> Buffer overflow means the original "strcat" program had a bug if it
>> was expected to deal correctly with longer strings - longer strings
>> caused UB, and that is never correct execution.
>>
>> Let's say the program is trying to concatenate two strings into a 10
>> character buffer.  There are, roughly, three was to specify this :
>>
>> 1. It should give the concatenation for any two strings whose total
>> length does not exceed 9 characters.
>>
>> 2. It should give the concatenation for any two strings.
>>
>> 3. It should up to the first 9 characters of the hypothetical
>> unlimited length concatenation of any two strings.
>>
>> If the specification is 1, then the "strcat" version is fine - it is
>> ideal behaviour.  Garbage in, garbage out - programs are only required
>> to be used according to their specifications.
>>
>> If the specification is 2, then it is impossible to write a program
>> with the required behaviour.
>>
>> If the specification is 3, then strncat will give the ideal behaviour.
>>
>>
>> The "ideal behaviour" is dependent on the specification for the
>> program, and that has not been given here.  Without the specification
>> or requirements, it makes no sense to talk about whether there is or
>> is not an "ideal behaviour", whether it is possible or not, or whether
>> any given program fulfils it.
>>
>>
> No. The program is trying to concatentate "strcat " and "strncat" into a
> ten byte buffer, and the specification is that the buffer shall hold
> "strcat strncat".

Says who?

Why do /you/ get to decide details of what the program is supposed to
do? You can't just pick a specification after the fact as an attempt to
justify your claims that the program is buggy!

> But since that is more than ten bytes that is
> impossible, the specification cannot be met and therefore the program is
> bugged.

No. I the specification is impossible to meet, then the specification
is at fault, not the program.

Whether a program with strcat, or a program with strncat, is correct or
not depends on the specifications for the program. The specifications
were never given. So all we can do is look at what might or might not
be correct for various plausible choices of specifications. We cannot
conclude that a particular implementation is buggy, nor can we conclude
that it is correct.

On Sat, 27 Jan 2024 15:44:22 +0100, David Brown wrote:

> Whether a program with strcat, or a program with strncat, is correct or
> not depends on the specifications for the program.

Can a program that uses strcat be “correct”? In theory, yes. In practice,
code that uses such misbegotten functions has a high probability of having
associated security vulnerabilities like buffer overflows in it. That’s
why we avoid same.

On 1/27/2024 12:48 PM, Lawrence D'Oliveiro wrote:
> On Sat, 27 Jan 2024 15:44:22 +0100, David Brown wrote:
>
>> Whether a program with strcat, or a program with strncat, is correct or
>> not depends on the specifications for the program.
>
> Can a program that uses strcat be “correct”?

Indeed! For sure.

> In theory, yes. In practice,
> code that uses such misbegotten functions has a high probability of having
> associated security vulnerabilities like buffer overflows in it. That’s
> why we avoid same.

Well, if you cannot use it correctly, perhaps, well, don't use it until
you learn how?

Patient: it hurts when I do that...

Humm...

On 27/01/2024 20:48, Lawrence D'Oliveiro wrote:
> On Sat, 27 Jan 2024 15:44:22 +0100, David Brown wrote:
>
>> Whether a program with strcat, or a program with strncat, is correct or
>> not depends on the specifications for the program.
>
> Can a program that uses strcat be “correct”? In theory, yes. In practice,
> code that uses such misbegotten functions has a high probability of having
> associated security vulnerabilities like buffer overflows in it. That’s
> why we avoid same.

So how would you write such a function in a safe manner?

At some point you will need to trust the parameters that the caller
provides. Then that is no different to an implementation of strcat.

BTW you seem to like Python. Cpython uses strcpy() quite a bit, and also
strcat(). Does that make CPython unsafe?

In article <up3q66$3hbk7$5@dont-email.me>,
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>On Sat, 27 Jan 2024 15:44:22 +0100, David Brown wrote:
>
>> Whether a program with strcat, or a program with strncat, is correct or
>> not depends on the specifications for the program.
>
>Can a program that uses strcat be correct? In theory, yes. In practice,
>code that uses such misbegotten functions has a high probability of having
>associated security vulnerabilities like buffer overflows in it. Thats
>why we avoid same.

I'm very happy for you.

--
"Only a genius could lose a billion dollars running a casino."
"You know what they say: the house always loses."
"When life gives you lemons, don't pay taxes."
"Grab 'em by the p***y!"

On Sat, 27 Jan 2024 21:15:54 +0000, bart wrote:

> On 27/01/2024 20:48, Lawrence D'Oliveiro wrote:
>
>> Can a program that uses strcat be “correct”? In theory, yes. In practice,
>> code that uses such misbegotten functions has a high probability of having
>> associated security vulnerabilities like buffer overflows in it. That’s
>> why we avoid same.
>
> So how would you write such a function in a safe manner?

Don’t. Use an alternative function instead.

<https://manpages.debian.org/7/string_copying.en.html>

On 27/01/2024 23:41, Lawrence D'Oliveiro wrote:
> On Sat, 27 Jan 2024 21:15:54 +0000, bart wrote:
>
>> On 27/01/2024 20:48, Lawrence D'Oliveiro wrote:
>>
>>> Can a program that uses strcat be “correct”? In theory, yes. In practice,
>>> code that uses such misbegotten functions has a high probability of having
>>> associated security vulnerabilities like buffer overflows in it. That’s
>>> why we avoid same.
>>
>> So how would you write such a function in a safe manner?
>
> Don’t. Use an alternative function instead.
>
> <https://manpages.debian.org/7/string_copying.en.html>

Which one from that page? It shows strcat and strlcat.

The latter contains a size. But you have to trust the size is correct.

This is little different from trusting the caller to not provide a
source string that is longer than the remaining capacity of the destination.

At some point, you have to trust something.

On Sat, 27 Jan 2024 23:49:42 +0000, bart wrote:

> The latter contains a size. But you have to trust the size is correct.

The point being, you can specify one.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Sat, 27 Jan 2024 15:44:22 +0100, David Brown wrote:
>> Whether a program with strcat, or a program with strncat, is correct or
>> not depends on the specifications for the program.
>
> Can a program that uses strcat be “correct”? In theory, yes. In practice,
> code that uses such misbegotten functions has a high probability of having
> associated security vulnerabilities like buffer overflows in it. That’s
> why we avoid same.

In theory, yes. In practice, also yes.

char s[20];
strcpy(s, "foo");
strcat(s, "bar");

That's perfectly safe. Yes, you can introduce a buffer overflow if you
modify the code carelessly. So don't do that. And yes, strcpy() and
strcat() certainly can be used unsafely. Nobody has denied that.

Similarly, adding two int value can cause undefined behavior if the
result overflows. Do you suggest using only bound-checking addition
operators (I think C23 is adding them to the standard library)?

--
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 Sat, 27 Jan 2024 17:05:27 -0800, Keith Thompson wrote:

> Yes, you can introduce a buffer overflow if you
> modify the code carelessly. So don't do that.

Adding an explicit buffer size provides an additional check. It helps
reduce the incidence of such “carelessness”. Not completely, but it helps.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
> On Sat, 27 Jan 2024 17:05:27 -0800, Keith Thompson wrote:
>> Yes, you can introduce a buffer overflow if you
>> modify the code carelessly. So don't do that.
>
> Adding an explicit buffer size provides an additional check. It helps
> reduce the incidence of such “carelessness”. Not completely, but it helps.

Sure. It also requires extra work, and introduce more opportunities for
errors if you specify the size incorrectly.

There are languages that handle this kind of thing differently, where
the size is inherently associated with each array or string object or
value, and therefore the programmer doesn't have to specify it at all.
C is not one of those languages.

You seemed to be implying that strcpy() and strcat() cannot ever be used
safely, and should not ever be used at all. It was that extreme
statement that I was trying to refute. Of course using strcpy() or
strcat() with user-provided input without checking:

char buf[80]
strcpy(buf, argv[1]);
strcat(buf, argv[2]);

is dangerous. Just as 1+1 is perfectly safe, but n+1 is potentially
dangerous if n might be equal to INT_MAX.

--
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 Sat, 27 Jan 2024 18:00:08 -0800, Keith Thompson wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>> On Sat, 27 Jan 2024 17:05:27 -0800, Keith Thompson wrote:
>>> Yes, you can introduce a buffer overflow if you modify the code
>>> carelessly. So don't do that.
>>
>> Adding an explicit buffer size provides an additional check. It helps
>> reduce the incidence of such “carelessness”. Not completely, but it
>> helps.
>
> Sure. It also requires extra work ...

Macros can help with that.

On 27/01/2024 21:48, Lawrence D'Oliveiro wrote:
> On Sat, 27 Jan 2024 15:44:22 +0100, David Brown wrote:
>
>> Whether a program with strcat, or a program with strncat, is correct or
>> not depends on the specifications for the program.
>
> Can a program that uses strcat be “correct”? In theory, yes. In practice,
> code that uses such misbegotten functions has a high probability of having
> associated security vulnerabilities like buffer overflows in it. That’s
> why we avoid same.

In theory, yes. In practice, yes.

The principle is the same for every program. If you have unknown input
from the outside, sanitize it so that you know enough about it to be
able to use it the way you want. If you know it is safe to use it in a
particular way, you can use it that way without introducing bugs.

Any program, function, or set of functions needs a specification (even
if it is informal). This gives the restrictions on the inputs for
anything using the code, and says what the output will be as long as
these restrictions are fulfilled. (It might also specify some error
detection for "bad" inputs, but that's really just an extension to the
specification of inputs and outputs.)

Sometimes a function will be specified for all possible values of its
input types. Sometimes it won't. (And sometimes details are hidden by
the language and implementation - the object code for a function
typically gets its inputs in registers or stack entries, and they may be
able to hold bit patterns that don't match any value of the logical type.)

The implementation of a function can, and should, assume that the input
values are within specification. Any incorrect input falls under
"garbage in, garbage out" - a principle that has been established in the
computing world since the first mechanical computers, and which extends
throughout countless aspects of life.

If the function uses strcat in a way that is safe and correct for inputs
as specified for the function, then it is safe and correct to use strcat.

If you have an alternative way to implement the function, that could be
just as good. You might have a way to do it more efficiently. But that
does not mean strcat is bad.