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

An intro to Zig's integer casting for C programmers

lagerdata.com

Post reply on HN
Print view View original

71–80 of 135 posts

Re: An intro to Zig's integer casting for C programmers

#71

Post by elcritch »

gilnaa wrote: post #10
lionkor wrote: post #2

> If runtime safety is turned off, you get undefined behavior You already know someone will teach their students to always have it off because its "slower" or something. Make something idiot-proof and the world invents a better idiot. Another language that does safety like this incredibly well is Ada (Ada/SPARK), and I'm unsure why people aren't more hyped about it. So many people hype Rust or Zig or whatever new lan…

Not to sound too aggressive, I'm not sure why ada programmers keep being surprised at the hype. Safety (of all kinds) is not the only selling point of Rust and Zig, and the fact that Ada also have safety measures doesn't mean that it's instantly an option for me. For example, I keep seeing people hype about Zig/Rust, for all kinds of reasons; and the way that they present their arguments is very compelling. While I'v…

From what I can tell, safety isn't a selling factor of Zig. From a "safety" perspective Zig seems like a step backwards compared to the latest generation of languages, and Rust in particular. Zig's ergonomics seem decent but its memory safety tact appears to basically be to include valgrind-like tools into debug builds with good PR.

Re: An intro to Zig's integer casting for C programmers

#72

Post by p0nce »

dgrunwald wrote: post #61
p0nce wrote: post #45

Earlier quoted context omitted.

> adding two int16_t together to get a int16_t in return is really hard Because the first thing people will do is: int16_t a, b; a = (int16_t) ((b * 157) >> 12); and then if b * 157 doesn't promote to 32-bit it overflows in the negative and then the code is incorrect.

You're assuming `int` is 32-bits. The fact that C implicitly promotes to `int` makes it extremely hard to use the stdint.h typedefs without accidentally making platform-specific assumptions. uint16_t a, b, c; a = 50000; b = 40000; c = a * b; This simple code may or may not have undefined behavior depending on the target platform. (it's fine for 16-bit int, UB for 32-bit int, and fine again for 64-bit int) Numeric pro…

Well there is the integer promotion issue, and the integers-have-unknown-size issue.

Re: An intro to Zig's integer casting for C programmers

#73

Post by dnautics »

elcritch wrote: post #71
gilnaa wrote: post #10

Earlier quoted context omitted.

Not to sound too aggressive, I'm not sure why ada programmers keep being surprised at the hype. Safety (of all kinds) is not the only selling point of Rust and Zig, and the fact that Ada also have safety measures doesn't mean that it's instantly an option for me. For example, I keep seeing people hype about Zig/Rust, for all kinds of reasons; and the way that they present their arguments is very compelling. While I'v…

From what I can tell, safety isn't a selling factor of Zig. From a "safety" perspective Zig seems like a step backwards compared to the latest generation of languages, and Rust in particular. Zig's ergonomics seem decent but its memory safety tact appears to basically be to include valgrind-like tools into debug builds with good PR.

Putting valgrind into the stdlib is really clever, and also, I like memory safety being the carrot to get you to write tests. I worry having a 'safe' system like rust sometimes causes very smart (TM) developers, especially less experienced ones, to be complacent and write less tests.

Re: An intro to Zig's integer casting for C programmers

#74

Post by elcritch »

arc619 wrote: post #69
TchoBeer wrote: post #44

Earlier quoted context omitted.

I don't understand why there aren't any solutions like this. Why aren't there any languages with a good garbage collector but also let you turn it off and work with memory manually. Maybe there is and I don't know of it? Maybe garbage collected languages and manual memory languages require different design? I don't know.

Nim is built like this. The gc is opt-in by type and manual memory management is simple. All other types are stack allocated by default. The new gc is pretty much compiler assisted scope managed smart pointers as well. Also when using the gc you can build your own types with custom create/free/copy/move operators to do what you want without worrying about a stop the world gc. Using the arc gc pretty much compiles dow…

+1 for Nim and being usable without a GC or for manual memory management like dealing with C apis. Though to be fair, quite a few types in the stdlib are heap based. But you can make your own static heap pool.

With the new ARC & move semantics, Nim has hit a sweet spot, IMHO. It's like the language struggled to find a fit for a long time. But ARC allows very low overhead memory safety, perfect for mcu's and wasm in particular.

Though perhaps Swift could be a contender in this arena as well with its ARC, but it's development is so Apple centric.

What's interesting to me is that with move semantics and smarter compiler analysis, an ARC based GC overhead approaches that of Rust's compile time lifetime memory management. For any non-trivial program Rust seems to use a lot of Rc's or copies to get around lifetime analysis issues. So if the compiler can automatically figure out lifetimes in code it can eliminate many ARC operations.

I hope more languages adopt more flexible ARC based gc's or improve on rusts ergonomics.

Re: An intro to Zig's integer casting for C programmers

#75

Post by losvedir »

Shadonototro wrote: post #65

casting, one of the reason i gave up with Zig quickly, it just is painful and solves nothing, it makes the code hard to decipher

How quickly?

Like, you saw it in the docs when you were mildly interested and decided it wasn't for you? Or you started a project, had at least a "hello world" compiling, but then eventually gave up on it because you were tired of casting? In that case I'm curious what the project was since I haven't run into casting all that often, but it might vary by domain.

Re: An intro to Zig's integer casting for C programmers

#76

Post by meepmorp »

messe wrote: post #60
scoutt wrote: post #58

I am curious to know the reasons behind the @as() syntax. What's wrong with "i32 y = (i32) x;"? I look with interest to new languages but after so many years dealing with C, my parser crashes when I see the type after the variable name and at the end of functions declarations. var x : u8 = 5; What's wrong with "u8 x = 5;"? And I don't really like type inference very much (or when it's abused or cannot be avoided). Wh…

> Curious fact: the above code generates >40000 lines of assembly in godbolt: https://www.godbolt.org/z/fxfbb9jfn I took a quick glance at the ASM, and it seems that the majority of that is code from the stdlib run prior to main. Compiling with -OReleaseSafe brings that down to 15,000 lines of assembly. If you get rid of "main" and compile it as an exported function, you get far less code: https://www.godbolt.org/z/j…

> Compiling with -OReleaseSafe brings that down to 15,000 lines of assembly.

I tried it with -OReleaseFast to compare, and it's 500-ish lines. That's amazing.

Re: An intro to Zig's integer casting for C programmers

#77

Post by xfer »

roblabla wrote: post #41
nine_k wrote: post #21

Earlier quoted context omitted.

Ada / spark may be a great thing. But how do people know? Is there a good compiler that one can install for free? Are there a few good and comprehensive books / references / guides, available online for free? If you want something to become popular, give it away . Ideally, push it. At the very least, have a limited free version. Or turn a bling eye to small-time piracy, as many vendors did for a long time. Or make it…

Not sure why you think ADA/Spark isn't free. There's GNAT[0], an open source ADA compiler that's part of the GNU toolchain, a fairly good book teaching ADA and SPARK[1] by Ada Core, and plenty of tutorials. Accessibility is really not the problem. The problem is, Ada is an old language that has many similar problems to C: lack of a good package management story, and a design by committee making language evolution gla…

Judging the state of affairs there might as well go with ATS. http://www.ats-lang.org/

Re: An intro to Zig's integer casting for C programmers

#78

Post by dnautics »

losvedir wrote: post #75
Shadonototro wrote: post #65

casting, one of the reason i gave up with Zig quickly, it just is painful and solves nothing, it makes the code hard to decipher

How quickly? Like, you saw it in the docs when you were mildly interested and decided it wasn't for you? Or you started a project, had at least a "hello world" compiling, but then eventually gave up on it because you were tired of casting? In that case I'm curious what the project was since I haven't run into casting all that often, but it might vary by domain.

i just looked over some code I have which takes a complicated 3rd party binary format, parses, and extracts information from it. In about 2K LOC including tests there are no casting events except for some int-to-pointer and pointer-to-int at the boundary of passing reference to WASM.

Re: An intro to Zig's integer casting for C programmers

#79

Post by dapids »

lionkor wrote: post #2

> If runtime safety is turned off, you get undefined behavior You already know someone will teach their students to always have it off because its "slower" or something. Make something idiot-proof and the world invents a better idiot. Another language that does safety like this incredibly well is Ada (Ada/SPARK), and I'm unsure why people aren't more hyped about it. So many people hype Rust or Zig or whatever new lan…

Yes, sure, but have you actually used Ada in practice? It's not exactly ergonomic or straightforward either, it's not magic.

You don't hear about the struggles of using it in practice because the projects you've pointed out are usually confidential.

In my experience MISRA is a much more popular standard for secure programming in the defence industry versus Ada. MISRA is a C standard, and yes, it runs missile systems, Boeing braking systems, you name it.

Re: An intro to Zig's integer casting for C programmers

#80

Post by piaste »

pornel wrote: post #29
pjmlp wrote: post #9

Earlier quoted context omitted.

C programmers are well known to refer to such programming safety as straighjacket since the Pascal days anyway. There was more than enough time to learn why it was the right option to start with.

Rust does go overboard though, e.g. indexing requires `usize`. You either use `usize` for all your integers, or you end up with a cast-salad. arr[i as usize] This is actually risky, because even when you only meant to extend, you can also accidentally truncate or change sign. `as` does all of these things without a warning, and mixed with type inference it can easily lead to surprises. Rust makes it worse by insistin…

I'm not a Rust programmer, but AFAIK Rust has inline functions, so if your code has lots of indexing calls, could most of the pain go away with a few short helper functions?

    #[inline(always)]
    fn idx(i : u32) { usize::try_from(i).unwrap() }
or

    #[inline(always)]
    fn get(arr: [T], i : u32) { arr.[usize::try_from(i).unwrap()] }
Have to repeat the definition for each numeric type you use, I guess, but hopefully you aren't using _that_ many of them.
Post reply on HN