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

Catch-23: The New C Standard Sets the World on Fire

queue.acm.org

Post reply on HN
Print view View original

181–190 of 275 posts

Re: Catch-23: The New C Standard Sets the World on Fire

#181

Post by heywhatupboys »

chongli wrote: post #63
mjevans wrote: post #49

Earlier quoted context omitted.

That's exactly why a compiler shouldn't be able to 'optimize' in the face of UB, it should be an ERROR and the section of undefined behavior highlighted in the error message.

This would mean you’d have to insert a check every time you add two signed integers together, because signed overflow is UB. You’d also have to wrap every memory access with bounds checks, because OOB memory access is UB. There are also tons and tons of loop optimizations compilers do for side-effect free loops which would have to be removed completely. This is because infinite loops without side effects are UB. So i…

> because signed overflow is UB

no longer

Re: Catch-23: The New C Standard Sets the World on Fire

#182

Post by heywhatupboys »

pjmlp wrote: post #141

And zero focus on improving the root causes of memory corruption due to strings and array indexing errors. The security world will keep burning it seems.

> The security world will keep burning it seems.

There is no alternative to network protocols and IPC that the stringtypes C has. You get a length and a byte array. If you trust the user, you can assume length is correct. Otherwise no.

Re: Catch-23: The New C Standard Sets the World on Fire

#183

Post by bongobingo1 »

shagie wrote: post #72
wizzwizz4 wrote: post #68

Earlier quoted context omitted.

> I wonder if somewhere along the chain there was an automated tool to convert frequently abused mental-health related terms like “insane” into something leas hurtful, or something along those lines? And yet again, these Lincoln systems mess up. While giving advice to the author can avoid Great Grimsby mistakes, making the replacements automatically is an utterly Scunthorpe decision, with failures as Slough as they a…

As an aside, this is one of the spots where GPT does a really good job of fixing things. Reword the following passage. Change euphemisms to wording that has similar meaning though no negative conotations. Indicate changed words by putting them in "{{word}}" ### Standards are supposed to lead ... Why are such requests made? Often because of arithmetic bugs. And what is a non-null pointer from malloc(0) good for? Absol…

Sorry, `unconventional` is also offensive.

> Reword the following passage. Change euphemisms to wording that has similar meaning though no negative conotations. Indicate changed words by putting them in "{{word}}"

>

> The couples were of unconventional make up, including male and female pairings, male and male pairings as well as female and female.

>> The couples had non-traditional compositions, with pairings consisting of men and women, men and men, and women and women.

So's male and female apparently.

Re: Catch-23: The New C Standard Sets the World on Fire

#184

Post by rini17 »

adrian_b wrote: post #154
chongli wrote: post #118

Earlier quoted context omitted.

Those things aren’t up to the language, they’re up to hardware. C is a portable language that runs on many different platforms. Some platforms might have protected memory and trap on out of bounds memory access. Other platforms have a single, flat address space where out of bounds memory access is not an error, it just reads whatever is there since your program has full access to all memory. The same goes for integer…

The problem is that here is a vicious circle. Most old computer architectures had a much more complete set of hardware exceptions, including cases like integer overflow or out-of-bounds access. In modern superscalar pipelined CPUs, implementing all the desirable hardware exceptions without reducing the performance remains possible (through speculative execution), but it is more expensive than in simple CPUs. Because…

I don't believe adding simple checks against data already present in L1 caches and marked as "unlikely to fail" should be so onerous.

Re: Catch-23: The New C Standard Sets the World on Fire

#185

Post by mafuy »

chongli wrote: post #63
mjevans wrote: post #49

Earlier quoted context omitted.

That's exactly why a compiler shouldn't be able to 'optimize' in the face of UB, it should be an ERROR and the section of undefined behavior highlighted in the error message.

This would mean you’d have to insert a check every time you add two signed integers together, because signed overflow is UB. You’d also have to wrap every memory access with bounds checks, because OOB memory access is UB. There are also tons and tons of loop optimizations compilers do for side-effect free loops which would have to be removed completely. This is because infinite loops without side effects are UB. So i…

> you’d have to insert a check every time you add two signed integers together,

This is exactly what is done in serious code. It is typically combined with contracts and static analysis (often human), e.g. "it is guaranteed that this input is in range 10-20, so adding it with this other 16 bit int can be assumed to be below sint32_max".

Re: Catch-23: The New C Standard Sets the World on Fire

#186

Post by Arch-TK »

codethief wrote: post #120
im3w1l wrote: post #16

Earlier quoted context omitted.

I think the issue with this is that the worst-case bounds normally grow much faster than the actual values. And it can be easy to see for the programmer that the values can't actually grow that much because a is only big when b is small or some property like that, but then you have to convince the compiler of the same. I might be misremembering though.

> because a is only big when b is small or some property like that Exactly, the expressiveness of the type system then (typically) becomes the obstacle: How do you express that a and b could each reach INT_MAX but their sum never exceeds INT_MAX?

Those kinds of assumptions are where you explicitly cast to a smaller ranged type with the option of an error if the sum does exceed a limit. The point of this type system is not to be able to fully encode every possible interaction between numbers in a system, but rather to remove unnecessary bounds checking in a bunch of cases and make it explicit in the few cases where you ARE actually making an assumption.

Re: Catch-23: The New C Standard Sets the World on Fire

#187

Post by Arch-TK »

coliveira wrote: post #40
Arch-TK wrote: post #5

Earlier quoted context omitted.

I agree that realloc was poorly defined for the 0 size case, I think UB or IDB both would have worked in this case to really drive that point home, the WG chose UB. That being said, you're completely wrong about what UB means. Making use of UB may as well initiate the rise of zombie velociraptors. Except for the situation where your implementation explicitly specifies that it provides a predictable behaviour for a sp…

> this kind of mislead assumption is one of the major sources of bugs in C code. This is not even close to be true. Most bugs in C code are from programmer mistakes, not from UB behavior. The exaggeration that is spread by some people regarding UB is close to absurd. If something is UB, it may generate different results in different situations, even with the same compiler. The standard is just clarifying this problem…

> Most bugs in C code are from programmer mistakes

These most often lead to the triggering of UB. The reason why programmer mistakes lead to confusing bugs instead of simple and straightforward bugs which are easy to catch in the development process is mainly because UB imposes no restrictions on what the compiler should do. In the vast majority of UB cases the compilers simply don't do anything, and assume it can't happen. This is why dereferencing a pointer and then checking if it's null ends up eliding the null check (because if you've dereferenced it, it can't be null, that would be UB). Accessing past the end of an array is UB so it can't happen, therefore your compiler won't check for it. Accessing past the end of an array and accidentally reading from/writing to another variable - likewise.

UB encompasses ALL behavior for which the standard does not provide an explicit definition. The reason why the C standard provides explicit instances of UB usually boils down to clarifying situations where people were confused about whether something was UB or not. But if the behaviour is not defined in the standard, then it is by definition UB.

Re: Catch-23: The New C Standard Sets the World on Fire

#188

Post by ChancyChance »

ChancyChance wrote: post #121
notfed wrote: post #88

Earlier quoted context omitted.

It's a flaw that has a pretty good tradeoff: unparalleled readability.

It depends. If you want to study maths, yes. If you want to be a programmer: [status, value] = add(a, b); Is much more unparalleled-ly (?) readable from the perspective of how a computer actually operates. In reality, this: uint c = (uint)a + (uint)b; // (to make that other guy happy) is really: c = (a + b) % (sizeof(uint)); in "C", which is less readable but far more accurate.

That’s 2^sizeof(uint)

Re: Catch-23: The New C Standard Sets the World on Fire

#189

Post by Kamq »

RustyRussell wrote: post #9

Frankly, the C standards ctte went off the deep end when they effectively banned NULL to memset etc (obv with zero length). Not because these functions couldn't handle it, but because this assertion simplifies optimizations elsewhere . This has required adding extra checks in my code, found mainly by trial and error, and has made it less readable and less optimal. Finally, the checked arithmetic operations returning…

> Finally, the checked arithmetic operations returning false on success

That's what got you? C functions returning error flags (with zero meaning no error) isn't exactly new.

Re: Catch-23: The New C Standard Sets the World on Fire

#190

Post by wizzwizz4 »

im3w1l wrote: post #16
Arch-TK wrote: post #8

Earlier quoted context omitted.

There is actually another option. A more sophisticated type system. Let's say you had some pseudocode like this: let a = 5 let b = 12 let c = a + b The type of a would be Integer[5..5], the type of b would be Integer[12..12], the type of c would therefore be Integer[17..17]. In a more complex example: def foo(a: Integer[0..10], b: Integer[0..10]): return a + b The return type of this function would be Integer[0..20].…

I think the issue with this is that the worst-case bounds normally grow much faster than the actual values. And it can be easy to see for the programmer that the values can't actually grow that much because a is only big when b is small or some property like that, but then you have to convince the compiler of the same. I might be misremembering though.

> but then you have to convince the compiler of the same.

In conventional parlance, this is known as "handling overflow".

Post reply on HN