Whether a program with strcat, or a program with strncat, is correct or
not depends on the specifications for the program.
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 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.
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?
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>
The latter contains a size. But you have to trust the size is correct.
Yes, you can introduce a buffer overflow if you
modify the code carelessly. So don't do that.
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 ...
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/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:For me security vulnerablities of that type aren't a big issue. Whilst
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.
;
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... ;^)
Don't. Use an alternative function instead.
<https://manpages.debian.org/7/string_copying.en.html>
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 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 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.
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 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.
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 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.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 307 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 94:33:54 |
| Calls: | 6,849 |
| Files: | 12,352 |
| Messages: | 5,414,804 |