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

11–20 of 275 posts

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

#11

Post by adgjlsfhk1 »

wahern wrote: post #6
__s wrote: post #2

tl;dr `realloc(p, 0)` is slated to be undefined behavior in C23, whereas it's been somewhat implementation defined until now, with recommendation being realloc(p, 0) is equivalent to free(p) Seems a bit tone deaf to create new undefined behavior in memory handling, especially when a sane default behavior seems to be de facto I've used that free-on-0 behavior myself. Unfortunately the code that uses this will often ha…

> Seems a bit tone deaf to create new undefined behavior in memory handling, It's only tone deaf to people who understand "undefined behavior" as an epithet or as synonymous with giving a license to compilers to screw you over. The term doesn't have either of those meaning to those on the C committee. In fact, one of the explicit rationales for the proposal is that, "Classifying a call to realloc with a size of 0 as…

> It's only tone deaf to people who understand "undefined behavior" as an epithet or as synonymous with giving a license to compilers to screw you over.

Unfortunately, this is the correct understanding of UB.

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

#12

Post by ericpauley »

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 is a horror show.

This seems in line with C conventions? Generally a 0 return code means success.

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

#13

Post by c4mpute »

ChancyChance wrote: post #4

Is the world finally realizing that "a + b" actually returns two values: pass/fail and the value if pass? "a + b = c;" is a fundamentally flawed operation from a computer architecture perspective.

First, you might have meant c = a+b;

The other way isn't really definable as an assignment mathematically.

And there is a lot more to it than just pass/fail. First, an addition doesn't fail, from a computer architecture perspective, the addition will always succeed, the only thing that could fail (in all the usual architectures) are possible memory fetch and store operations when not strictly dealing in register or immediate operands. Second, there is no fail flag. There is a overflow flag, an underflow flag, a zero flag, a sign and a few more that are irrelevant here. Any of overflow, underflow, zero or sign might mean that the operation "failed" depending on the types of your operand. Where the processor doesn't know anything about the type, so there won't be a straightforward 'fail' flag in any case. Only the library or compiler can use type information such as (un)signedness, bignum-ness, nonzeroness, desired wraparound (for modular types) and other possible types together with aforementioned flags to decide if that addition might have failed.

So nothing is fundamentally flawed, what you are describing is just insufficiently complex (because there is no fail flag, just a ton of other flags) or overly complex (because uint32_t c = a + b is modular 2^32 arithmetics and cannot fail).

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

#14

Post by firstlink »

> and that such changes may impose themselves on old code without recompilation when dynamically linked libraries are upgraded.

All I can do is laugh. This is what the dynamic linker fanatics wanted. This is what they explicitly advocate for to this day. Share and enjoy!!

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

#15

Post by firstlink »

solidsnack9000 wrote: post #10

"Looking forward, marijuana legalization will surely beget notions such as fractional-, imaginary-, and negative-length objects, each with as much potential for mayhem as zero-length objects." It's a funny thing to say.

Rust seems to do fine with ZSTs somehow.

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

#16

Post by im3w1l »

Arch-TK wrote: post #8
ChancyChance wrote: post #4

Is the world finally realizing that "a + b" actually returns two values: pass/fail and the value if pass? "a + b = c;" is a fundamentally flawed operation from a computer architecture perspective.

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.

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

#17

Post by bayindirh »

firstlink wrote: post #14

> and that such changes may impose themselves on old code without recompilation when dynamically linked libraries are upgraded. All I can do is laugh. This is what the dynamic linker fanatics wanted. This is what they explicitly advocate for to this day. Share and enjoy!!

I’d rather have small binaries and memory efficient systems instead of huge blobs having their own complete disconnected environments with non-coherent behavior on the same situation. Also, wasting tons of memory while at it.

If I have something that critical, I can always statically compile.

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

#18

Post by kibwen »

firstlink wrote: post #15
solidsnack9000 wrote: post #10

"Looking forward, marijuana legalization will surely beget notions such as fractional-, imaginary-, and negative-length objects, each with as much potential for mayhem as zero-length objects." It's a funny thing to say.

Rust seems to do fine with ZSTs somehow.

ZSTs work splendidly in Safe Rust, but you do need to consider them if you're writing unsafe generic code. Here's the relevant section of the Rustonomicon: https://doc.rust-lang.org/nomicon/exotic-sizes.html#zero-siz... .

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

#19

Post by AshamedCaptain »

firstlink wrote: post #14

> and that such changes may impose themselves on old code without recompilation when dynamically linked libraries are upgraded. All I can do is laugh. This is what the dynamic linker fanatics wanted. This is what they explicitly advocate for to this day. Share and enjoy!!

I really don't think anyone could possibly want the _specified behavior_ of a function changing below their feet.

However, the author is unlikely to be correct here. E.g., to this day, glibc contains _multiple implementations of memcpy_ just to satisfy those executables that depend on the older, memmove-like behavior that was once part of the unspecified behavior of glibc. The only way to get the dynamic linker to choose one of the newer versions is to, well, rebuild the executable. It is inconceivable that glibc would not use symbol versioning with an actual specification change.

The behavior is practically the same as with static linking, and you still get the benefits of dynamic linking.

Post reply on HN