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.
>
For me security vulnerablities of that type aren't a big issue. Whilst
someone could potentially exploit that vulnerability to run unspecified
code, he'd find it very difficult to deploy the exploit to a paying
customer. We've never had a case of that sort of thing.

But in some environments, yes this is a serious concern. You rely onthe
strings being checked for length eslewhere, and it's not at all unlikely
that those checks could be evaded somehow.

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

On 1/28/2024 8:43 AM, Malcolm McLean wrote:
> 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.
> >
> For me security vulnerablities of that type aren't a big issue. Whilst
> someone could potentially exploit that vulnerability to run unspecified
> code, he'd find it very difficult to deploy the exploit to a paying
> customer. We've never had a case of that sort of thing.
>
> But in some environments, yes this is a serious concern. You rely onthe
> strings being checked for length eslewhere, and it's not at all unlikely
> that those checks could be evaded somehow.
>

strcat can be used correctly. A person that juggles chainsaws, yet has
no arms and legs, well, shit happens... ;^)

On 28/01/2024 20:25, Chris M. Thomasson wrote:
> On 1/28/2024 8:43 AM, Malcolm McLean wrote:
>> 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.
>>  >
>> For me security vulnerablities of that type aren't a big issue. Whilst
>> someone could potentially exploit that vulnerability to run
>> unspecified code, he'd find it very difficult to deploy the exploit to
>> a paying customer. We've never had a case of that sort of thing.
>>
>> But in some environments, yes this is a serious concern. You rely
>> onthe strings being checked for length eslewhere, and it's not at all
>> unlikely that those checks could be evaded somehow.
>>
>
> strcat can be used correctly. A person that juggles chainsaws, yet has
> no arms and legs, well, shit happens... ;^)

The trick is to use juggling chainsaws, not regular ones (there are big
differences), and to know what you are doing with them. Accidents are
very rare. Juggling accidents come from people trying dangerous things
without proper training, or without appropriate safety precautions, or
because they think it will make them look smart.

So it is not /that/ different from programming!

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

[..how would one write a safe set of string functions?..]

> Don't. Use an alternative function instead.
>
> <https://manpages.debian.org/7/string_copying.en.html>

As documentation that page is truly horrendous.

On 1/28/2024 11:52 PM, David Brown wrote:
> On 28/01/2024 20:25, Chris M. Thomasson wrote:
>> On 1/28/2024 8:43 AM, Malcolm McLean wrote:
>>> 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.
>>>  >
>>> For me security vulnerablities of that type aren't a big issue.
>>> Whilst someone could potentially exploit that vulnerability to run
>>> unspecified code, he'd find it very difficult to deploy the exploit
>>> to a paying customer. We've never had a case of that sort of thing.
>>>
>>> But in some environments, yes this is a serious concern. You rely
>>> onthe strings being checked for length eslewhere, and it's not at all
>>> unlikely that those checks could be evaded somehow.
>>>
>>
>> strcat can be used correctly. A person that juggles chainsaws, yet has
>> no arms and legs, well, shit happens... ;^)
>
> The trick is to use juggling chainsaws, not regular ones (there are big
> differences), and to know what you are doing with them.  Accidents are
> very rare.  Juggling accidents come from people trying dangerous things
> without proper training, or without appropriate safety precautions, or
> because they think it will make them look smart.
>
> So it is not /that/ different from programming!
>

You got it! Big time David. :^)

On Mon, 29 Jan 2024 12:08:09 -0800, Tim Rentsch wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
> [..how would one write a safe set of string functions?..]
>
>> Don't. Use an alternative function instead.
>>
>> <https://manpages.debian.org/7/string_copying.en.html>
>
> As documentation that page is truly horrendous.

As with anything open-source, feel free to show us how you would do
better.

On 2024-01-29, Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
> On Mon, 29 Jan 2024 12:08:09 -0800, Tim Rentsch wrote:
>
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>
>> [..how would one write a safe set of string functions?..]
>>
>>> Don't. Use an alternative function instead.
>>>
>>> <https://manpages.debian.org/7/string_copying.en.html>
>>
>> As documentation that page is truly horrendous.
>
> As with anything open-source, feel free to show us how you would do
> better.

The functions *are already documented* in glibc's manual.

https://sourceware.org/glibc/manual/html_mono/libc.html

where they are covered with much less pontification, belaboring and
rambling.

"The simplest character sequence copying function is mempcpy(3)"

What? According to what simplicity measure? This opinion bit,
like many others, adds no value.

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

In article <up9d6f$lmi3$2@dont-email.me>,
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>On Mon, 29 Jan 2024 12:08:09 -0800, Tim Rentsch wrote:
>
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>
>> [..how would one write a safe set of string functions?..]
>>
>>> Don't. Use an alternative function instead.
>>>
>>> <https://manpages.debian.org/7/string_copying.en.html>
>>
>> As documentation that page is truly horrendous.
>
>As with anything open-source, feel free to show us how you would do
>better.

This is such a crap argument.

Everything says shi - I mean, stuff like this, but it just such a
ridiculous argument.

--
In American politics, there are two things you just don't f*ck with:

1) Goldman Sachs
2) The military/industrial complex

On 2024-01-30, Kenny McCormack <gazelle@shell.xmission.com> wrote:
> In article <up9d6f$lmi3$2@dont-email.me>,
> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>On Mon, 29 Jan 2024 12:08:09 -0800, Tim Rentsch wrote:
>>
>>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>>
>>> [..how would one write a safe set of string functions?..]
>>>
>>>> Don't. Use an alternative function instead.
>>>>
>>>> <https://manpages.debian.org/7/string_copying.en.html>
>>>
>>> As documentation that page is truly horrendous.
>>
>>As with anything open-source, feel free to show us how you would do
>>better.
>
> This is such a crap argument.
>
> Everything says shi - I mean, stuff like this, but it just such a
> ridiculous argument.

Especially given that the Linux Man Pages Project could do better just
by abstaining from writing write poor documentation for which there
exist better sources.

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

On Tue, 30 Jan 2024 01:21:47 -0000 (UTC), Kenny McCormack wrote:

> In article <up9d6f$lmi3$2@dont-email.me>,
>
> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>>On Mon, 29 Jan 2024 12:08:09 -0800, Tim Rentsch wrote:
>>
>>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>>
>>> [..how would one write a safe set of string functions?..]
>>>
>>>> Don't. Use an alternative function instead.
>>>>
>>>> <https://manpages.debian.org/7/string_copying.en.html>
>>>
>>> As documentation that page is truly horrendous.
>>
>>As with anything open-source, feel free to show us how you would do
>>better.
>
> This is such a crap argument.

As the saying does: “put up or shut up”.

Keith Thompson ha scritto:
> 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]);

If someone writes a piece of code like this, then he is a programmer who
tries to use the C language and not a "C programmer". Code like that you
write it only when you do small tests for yourself.

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

On 30/01/2024 10:18, jak wrote:
> Keith Thompson ha scritto:
>> 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]);
>
> If someone writes a piece of code like this, then he is a programmer who
> tries to use the C language and not a "C programmer". Code like that you
> write it only when you do small tests for yourself.
>

It is fine as long as it is used according to specifications - just like
any other program.

You would not want to write code like this and release it to "the great
unwashed", who would not bother reading the specifications, and would
not follow them even if they read them. You would not release it
somewhere where using it outside the specifications could be a problem
for the security, or stability of a system, or otherwise cause trouble.

But there are a very large number of programs, not just trivial or
private test programs, which are written to be used only in particular
circumstances or in particular ways. They may only be run from other
front-end or driver programs - ones that run them appropriately. They
may be run only be qualified and trained people. And the programmer
could be perfectly justified in thinking that any sensible user will use
the program as intended, without problem. Ignorant users won't get
anywhere with it even if they find it, and malicious users can't do
worse than they could do with "sudo rm -rf /", which is easier to abuse.

As Keith said, code like that is dangerous - that does not mean it is wrong.

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