Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Improvements to static analysis in GCC 14

developers.redhat.com

Post reply on HN
Print view View original

101–110 of 147 posts

Re: Improvements to static analysis in GCC 14

#101

Post by bvrmn »

sirwhinesalot wrote: post #19
jandrewrogers wrote: post #14

Earlier quoted context omitted.

The use of goto is unambiguously correct and elegant in some contexts. Unwavering avoidance of goto can lead to unnecessarily ugly, convoluted code that is difficult to maintain. It usually isn't common but it has valid uses. While use of functions like `strcpy` are less advisable, there are contexts in which they are guaranteed to be correct unless other strong (e.g. language-level) invariants are broken, in which c…

strcpy and friends don't really have any benefits beyond just being there. The "safer" versions are still unsafe in many cases, while being less performant and more annoying to use. Writing a strbuffer type and associated functions isn't particularly hard and the resulting interface is nicer to use, safer, and more efficient.

I argue strview (non-owning) is almost always what is needed. Most of string operations are searching and slicing.

Re: Improvements to static analysis in GCC 14

#102

Post by sirwhinesalot »

jjav wrote: post #83
sirwhinesalot wrote: post #60

Earlier quoted context omitted.

> If it were obvious it would have been done already. Witness the many variants that try to make it better but don't. Every other language with mutable strings, including C++, does it like that. It is obvious. The reason it is not done in C is not ignorance, it is laziness. > Which you then can't pass to any other library. String management is very easy to solve within the boundaries of your own code. But you'll need…

> The reason it is not done in C is not ignorance, it is laziness. Of course not. C has been around since the dawn of UNIX and the majority of important libraries at the OS level are written in it. Compatibility with such a vast amount of code is a lot more important than anything else. If it were so easy why do you think nobody has done it? > Ignoring the also obvious solution of just keeping a null terminator aroun…

> If it were so easy why do you think nobody has done it?

People have done it, there are plenty strbuf implementations to go around. Even the kernel has seq_buf. How you handle string manipulation internally in your codebase does not matter for compatibility with existing libraries.

> That's not very useful for the general case. If your code relies on the extra metadata (length, size) being correct and you're passing that null-terminated buffer around to libraries outside your code, it won't be correct since nothing else is aware of it.

You can safely pass the char* buffer inside a std::string to any C library with no conversion. You're making up issues in your head. Don't excuse incompetence.

Re: Improvements to static analysis in GCC 14

#103

Post by sirwhinesalot »

bvrmn wrote: post #101
sirwhinesalot wrote: post #19

Earlier quoted context omitted.

strcpy and friends don't really have any benefits beyond just being there. The "safer" versions are still unsafe in many cases, while being less performant and more annoying to use. Writing a strbuffer type and associated functions isn't particularly hard and the resulting interface is nicer to use, safer, and more efficient.

I argue strview (non-owning) is almost always what is needed. Most of string operations are searching and slicing.

You also need a strview. Not really relevant for avoiding strcpy and strcat though.

Re: Improvements to static analysis in GCC 14

#104

Post by sirwhinesalot »

lelanthran wrote: post #85
sirwhinesalot wrote: post #60

Earlier quoted context omitted.

> If it were obvious it would have been done already. Witness the many variants that try to make it better but don't. Every other language with mutable strings, including C++, does it like that. It is obvious. The reason it is not done in C is not ignorance, it is laziness. > Which you then can't pass to any other library. String management is very easy to solve within the boundaries of your own code. But you'll need…

> you should only worry about it at the boundary with the other library. If this was a mitigation, it would solve all problems with nul-terminated strings i.e. do strict and error-checked conversions to nul-terminated strings at all boundaries to the program, and then nul-terminated strings and len-specified strings are equivalently dangerous (or safe, depending on your perspective). The problem is precisely that uns…

It's impossible to avoid "sanitizing" input if you have a conversion step from a library provided char* to a strbuf type. Any use of the strbuf API is guaranteed to be correct.

That's very different from needing to be on your toes with every usage of the strxcpy family.

Re: Improvements to static analysis in GCC 14

#105

Post by gpderetta »

bregma wrote: post #65
mgaunard wrote: post #39

-Wstringop-overflow is the first warning I disable because of all the false positives. I doubt the analyze variant would fare any better.

Isn't sort of like pulling the battery out of your carbon monoxide detector because the constant beeping is giving you a headache and making you sleepy?

No. -Wstringop-overflow is really broken with a huge amount of false positives.

At $JOB we disable it on a line by line basis, but I'm not sure it is worth the effort.

Re: Improvements to static analysis in GCC 14

#107

Post by raverbashing »

sirwhinesalot wrote: post #10
i80and wrote: post #6

Earlier quoted context omitted.

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…

Wow yeah this seems to summarize well the usual api flakiness and just shuffling of C

It seems people come with "one more improvement" that's broken in one way or the other

Re: Improvements to static analysis in GCC 14

#108

Post by jjgreen »

Ar-Curunir wrote: post #76
darby_eight wrote: post #70

Earlier quoted context omitted.

> The borrow checker attracts some, but it could have easily been done in a way with terrible usability. Why would anyone use the resulting language over C? What you're describing is C with a slightly friendlier compiler.

I have never heard C as being described to have a good type system.

To this day, many C programmers believe that strong typing just means pounding extra hard on the keyboard.

Peter van der Linden, "Expert C Programming"

Re: Improvements to static analysis in GCC 14

#109

Post by tialaramex »

estebank wrote: post #94
kolbe wrote: post #81

Earlier quoted context omitted.

"Copilot explain this error" has made this whole discussion irrelevant for me.

An issue is immediacy: problems are better the earlier they are pointed out (why online errors are better than compile errorswl, which are better than CI errors, which are runtime errors). Having to copy paste an error adds a layer of indirection that gets in the way of the flow. Another is reproducibility and accuracy: LLMs have a tendency to confidently state things that are wrong, and to say different things to di…

Certainly for the only new diagnostic I wrote for Rust, I expect an LLM's hallucinations are likely to have undesirable consequences. When you write 'X' where we need a u8, my diagnostic says you can write b'X' which is likely what you meant, but the diagnostic deliberately won't do this if you wrote '€' or '£' or numerous other symbols that aren't ASCII - because b'€' is an error too, so we didn't help you if we advised you to write that, you need to figure out what you actually meant. I would expect some LLMs to suggest b'€' there anyway.

Re: Improvements to static analysis in GCC 14

#110

Post by tialaramex »

Ar-Curunir wrote: post #76
darby_eight wrote: post #70

Earlier quoted context omitted.

> The borrow checker attracts some, but it could have easily been done in a way with terrible usability. Why would anyone use the resulting language over C? What you're describing is C with a slightly friendlier compiler.

I have never heard C as being described to have a good type system.

"Strongly typed, weakly checked". Which is a funny way to say "Not strongly typed" or perhaps more generously "The compilers aren't very good and neither are the programmers but other than that..." (and yes I write that as a long time C programmer)

But hey, C does have types:

First it has several different integers with silly names like "long" and "short".

Then it has the integers again but wearing a Groucho mask and with twice as many zeroes, "float" and "double".

Then an integer that's probably one byte, unless it isn't, in which case it is anyway, and which doesn't know whether it's signed or not, "char".

Then a very small integer that takes up too much space ("_Bool" aka bool)

Finally though, it does have types which definitely aren't integers, unfortunately they participates in integer arithmetic anyway and many C programmers believe they're integers, but the compiler doesn't so that's... well it's a disaster, I speak of course of the pointers.

Post reply on HN