Improvements to static analysis in GCC 14
developers.redhat.com
Improvements to static analysis in GCC 14
1–10 of 147 posts
Re: Improvements to static analysis in GCC 14
#2Very cool stuff!
I haven't done much C development lately, so I'm curious how often `strcpy` and `strcat` are used. Last I checked they're almost as big no-nos as using goto. (Yes, I know goto is often preferred in kernel dev...) Can anyone share on how helpful the c-string analyses are to them?
Re: Improvements to static analysis in GCC 14
#3Very cool stuff! I haven't done much C development lately, so I'm curious how often `strcpy` and `strcat` are used. Last I checked they're almost as big no-nos as using goto. (Yes, I know goto is often preferred in kernel dev...) Can anyone share on how helpful the c-string analyses are to them?
There's nothing wrong with simple usages of goto.
The strxcpy family on the other hand is complete garbage and should never be used for any reason. I'm horrified that they're used in the kernel at all. All of those functions (and every failed attempt at "fixing" them) should have been nuked from orbit.
Re: Improvements to static analysis in GCC 14
#4Very cool stuff! I haven't done much C development lately, so I'm curious how often `strcpy` and `strcat` are used. Last I checked they're almost as big no-nos as using goto. (Yes, I know goto is often preferred in kernel dev...) Can anyone share on how helpful the c-string analyses are to them?
There's nothing wrong with simple usages of goto. The strxcpy family on the other hand is complete garbage and should never be used for any reason. I'm horrified that they're used in the kernel at all. All of those functions (and every failed attempt at "fixing" them) should have been nuked from orbit.
What's wrong with `strncpy`?
Re: Improvements to static analysis in GCC 14
#5Earlier quoted context omitted.
There's nothing wrong with simple usages of goto. The strxcpy family on the other hand is complete garbage and should never be used for any reason. I'm horrified that they're used in the kernel at all. All of those functions (and every failed attempt at "fixing" them) should have been nuked from orbit.
What's wrong with `strncpy`?
It doesn't guarantee that the output is null terminated. Big source of exploits.
Re: Improvements to static analysis in GCC 14
#6Earlier quoted context omitted.
There's nothing wrong with simple usages of goto. The strxcpy family on the other hand is complete garbage and should never be used for any reason. I'm horrified that they're used in the kernel at all. All of those functions (and every failed attempt at "fixing" them) should have been nuked from orbit.
What's wrong with `strncpy`?
strncpy won't always write a trailing nul byte, causing out of bounds reads elsewhere. It's a nasty little fellow. See the warning at https://linux.die.net/man/3/strncpy
strlcpy() is better and what most people think strncpy() is, but still results in truncated strings if not used carefully which can also lead to big problems.
Re: Improvements to static analysis in GCC 14
#7Very cool stuff! I haven't done much C development lately, so I'm curious how often `strcpy` and `strcat` are used. Last I checked they're almost as big no-nos as using goto. (Yes, I know goto is often preferred in kernel dev...) Can anyone share on how helpful the c-string analyses are to them?
Some usage of goto is still idiomatic in C if used in ways logically equivalent to structured programming constructs C lacks. It requires some care, but I mean, it's C.
(I'm not however fond at all of longjmp)
Re: Improvements to static analysis in GCC 14
#8Very nice. I’m glad to see these all have detailed reports explaining what’s wrong!
Re: Improvements to static analysis in GCC 14
#9Very cool stuff! I haven't done much C development lately, so I'm curious how often `strcpy` and `strcat` are used. Last I checked they're almost as big no-nos as using goto. (Yes, I know goto is often preferred in kernel dev...) Can anyone share on how helpful the c-string analyses are to them?
gotos are fine if used judiciously. strcpy and strcat are “fine” in that they work when you know your code is correct and you have big problems if you don’t. But this describes most of C, unfortunately.
Re: Improvements to static analysis in GCC 14
#10Earlier quoted context omitted.
What's wrong with `strncpy`?
strncpy won't always write a trailing nul byte, causing out of bounds reads elsewhere. It's a nasty little fellow. See the warning at https://linux.die.net/man/3/strncpy strlcpy() is better and what most people think strncpy() is, but still results in truncated strings if not used carefully which can also lead to big problems.
Speaking of strlcpy, Linus has some colorful opinions on it:
> Note that we have so few 'strlcpy()' calls that we really should remove that horrid horrid interface. It's a buggy piece of sh*t. 'strlcpy()' is fundamentally unsafe BY DESIGN if you don't trust the source string - which is one of the alleged reasons to use it. --Linus
Maybe strscpy is finally the one true fixed design to fix them all. Personally I think the whole exercise is one of unbeliavable stupidity when the real solution is obvious: using proper string buffer types with length and capacity for any sort of string manipulation.