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

Tell HN: C Experts Panel – Ask us anything about C

news.ycombinator.com

Post reply on HN
Print view View original

761–770 of 978 posts

Re: Tell HN: C Experts Panel – Ask us anything about C

#761

Post by scaredginger »

userbinator wrote: post #745
cataphract wrote: post #109

Earlier quoted context omitted.

Signed overflow being undefined behavior allows optimizations that wouldn't otherwise be possible Quoting http://blog.llvm.org/2011/05/what-every-c-programmer-should-... > This behavior enables certain classes of optimizations that are important for some code. For example, knowing that INT_MAX+1 is undefined allows optimizing "X+1 > X" to "true". Knowing the multiplication "cannot" overflow (because doing so would be…

I've always thought that assuming such things should be wrong, because if you were writing the Asm manually, you would certainly think about it and NOT optimise unless you had a very good reason why it won't overflow. Likewise, I think that unless the compiler can prove that it, it should, like the sane human, refrain from making the assumption.

Well, by that reasoning, if you were coding in C, you would certainly think about it and ensure overflows won't happen.

The fact is that if the compiler encounters undefined behaviour, it can do basically whatever it wants and it will still be standard-compliant.

Re: Tell HN: C Experts Panel – Ask us anything about C

#763

Post by saagarjha »

quelsolaar wrote: post #627
clarry wrote: post #616

Earlier quoted context omitted.

> Why not mandate a warning every time the compiler detects and makes use of UB? It would solve SO many issues. Because that's hardly ever what happens, except when it actually does, and compilers do an increasingly good job of issuing diagnostics in that case. If you actually mandated it, no compiler today would come close to being standards compliant. This comes close to making the language unimplementable. The mos…

They need to do better then remove NULL checks silently. You can read all about Linus rants on this. Every time the compiler breaks things they blame the C standard for letting them do what ever. Thats whats wrong with C today. The C standard hasn't put its foot down.

Most compilers will no longer do this, FWIW.

Re: Tell HN: C Experts Panel – Ask us anything about C

#764

Post by saagarjha »

quelsolaar wrote: post #723
clarry wrote: post #684

Earlier quoted context omitted.

Huh? I just want performant code. That's why I write C, and that's why I use an optimizing compiler, and that's why I ask my compiler to optimize. I also want to write code that is reasonably generic. Thus, it will have checks and branches that cover important corner cases; they are required for completeness and correctness. But very often, all of these checks turn out to be redundant in a specific context, and an op…

This is a very naive view of how C works in reality. Take this example: if(a == NULL) log_error_and_exit(); *a = 0; Compilers, have been known to silently remove the NULL check in code like this. Does that seem clear to you? Is this your definition of compilers delivering for you? NULL checks dont just get removed in cases where you NULL check the same value multiple times, they get removed for some very non obvious…

You probably mean -fno-delete-null-pointer-checks?

Re: Tell HN: C Experts Panel – Ask us anything about C

#765

Post by flatfinger »

favorited wrote: post #719
tropo wrote: post #703

Earlier quoted context omitted.

C has strayed very far from the original intent because compiler authors prioritized benchmark results at the expense of real-world use cases. This bad trend needs to be reversed. Consider signed integer overflow. The intent wasn't that the compiler could generate nonsense code if the programmer overflowed an integer. The intent was the the programmer could determine what would happen by reading the hardware manual.…

If most C developers wanted to trade the performance they get from the compiler being able to assume `n+1 > n` for signed integer n, it would happen.

Most of the useful optimizations that could be facilitated by treating integer overflow as jump the rails optimization could be facilitated just as well by allowing implementations to behave as though integers may sometimes, non-deterministically, be capable of holding values outside their range. If integer computations are guaranteed never to have side effects beyond yielding "weird" values, programs that exploit that guarantee may be processed to more efficient machine code than those which must avoid integer overflow at all costs.

Re: Tell HN: C Experts Panel – Ask us anything about C

#766

Post by flatfinger »

dooglius wrote: post #286
Someone1234 wrote: post #239

Earlier quoted context omitted.

- In your example there's no guarantee that the length will be accurate, or that the data hasn't been modified independently elsewhere in the program. - In other words you've created a fantastic shoe-gun. One update line missed (either length or data, or data re-used outside the struct) and your "simple" struct is a huge headache, including potential security vulnerabilities. - Re-implementing a common error prone th…

>In your example there's no guarantee that the length will be accurate, or that the data hasn't been modified independently elsewhere in the program. And having a special data-and-length type would make these guarantees... how? You're ultimately going to need to be able to create these objects from bare data and length somehow, so it's a case of garbage-in-garbage-out.

How about having an attribute which, if applied to a structure that contains a `T*` and an integer type, would allow a `T[]` to be implicitly converted to that structure type?

Re: Tell HN: C Experts Panel – Ask us anything about C

#768

Post by tropo »

DougGwyn wrote: post #585
pornel wrote: post #511

Would you consider adding a built-in way to safely multiply two numbers? Numeric overflows in things like calculation of buffer sizes can lead to vulnerabilities. Signed overflow is UB, and due to integer promotion signs creep in unexpected places. It's not trivial to check if overflow happened due to UB rules. A naive check can make things even worse by "proving" the opposite to the optimizer. And all of that is to…

There are a lot of arithmetic conditions for which C could generate special code. There are div_t-related functions for the other direction. I for one would like a good way to obtain, using some Standard C coding pattern, fast "carry" for multiple-precision integer arithmetic. Several places in support functions, I have coded unusually to avoid wrap-around etc. I bet you could devise something like that for (unsigned…

A horrifying case was multiplication in an x86 emulator. The opcode handler needed to multiply a pair of unsigned 16-bit values, then return a 64-bit result.

The uint16_t got promoted to an int for the multiplication, causing undefined behavior. (if I remember right, the result was assigned to a uint16_t as well, making the intent clear) The compiler then assumed that the 32-bit intermediate couldn't possibly have the sign bit set, so it wouldn't matter if promotion to a 64-bit value had sign extension or zero extension. Depending on the optimization level, the compiler would do one or the other.

This is truly awful behavior. It should not be permitted.

Re: Tell HN: C Experts Panel – Ask us anything about C

#770

Post by saagarjha »

loeg wrote: post #410
rseacord wrote: post #37

Earlier quoted context omitted.

No one has proposed making these standard. I doubt they would gain much support as they are similar to the Annex K Bounds Checked Interface functions strcpy_s and strcat_s but not quite as good IMHO.

Well, I am informally proposing making those standard :-). IMO they're a lot more ergonomic than the Annex K functions, and do the thing most programmers think the strncat/strncpy functions do (admittedly, not part of ISO C). Annex K should be forgotten as the mistake it is and we can move on with existing real-world interfaces instead of inventing features from whole-cloth. I thought that was generally the C standar…

I disagree, because they return a value that nobody really wants and thus perform poorly: https://saagarjha.com/blog/2020/04/12/designing-a-better-str...
Post reply on HN