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

41–50 of 135 posts

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

#41

Post by roblabla »

nine_k wrote: post #21
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…

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 glacially slow (though that also doubles as a feature). It also lacks a vibrant ecosystem like we can find in other popular languages.

Furthermore, SPARK in particular takes the concept of safety much further than Rust or Zig do right now, as it allows proving the correctness of a program according to a formal specification. Rust/Zig only care about proving the absence of UB. This makes SPARK much more complex, and thus have a much higher barrier of entry.

[0]: https://www.gnu.org/software/gnat/

[1] https://learn.adacore.com/index.html

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

#42

Post by p0nce »

SuchAnonMuchWow wrote: post #28
p0nce wrote: post #5

Earlier quoted context omitted.

D doesn't try to "fix" C integer promotion/casts. It's because they aren't bad defaults. As a bonus you can port code from C with less risk. Soon you'll be able to compile it directly. I contributed to found the only discrepancy in D vs C code wrt integer (-byte would yield byte instead of int), and it was fixed so that they match exactly C _conventions_.

C integer promotions are what remains of old computers systems which couldn't handle anything but a 'word'. It result in things highly inconsistent on modern 64-bit machines: For example, char/short are automatically promoted to int or unsigned int when an operation is performed on them, but this doesn't happen between int and long. Simple things like adding two int16_t together to get a int16_t in return is really h…

> This is a bad default behavior

I don't think so. A lot of existing C code relies on this, and removing the promotion will prime this code to be copy/pasted without fix. Who will rewrite all the C and C++ codecs code out there?

A lot of C and C++ programmers actually ignore the int promotion rule, but their code relies on it involuntarily.

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

#44

Post by TchoBeer »

AnIdiotOnTheNet wrote: post #6
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…

> Make something idiot-proof and the world invents a better idiot. Sure, but if you only ever give people safety scissors then you're severely limiting the kinds of things that they can build. You have to let people who know what they are doing be able to do what they need to do, so you have to be able to turn the runtime safety off. Zig can do this at the scope level.

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.

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

#45

Post by p0nce »

SuchAnonMuchWow wrote: post #28
p0nce wrote: post #5

Earlier quoted context omitted.

D doesn't try to "fix" C integer promotion/casts. It's because they aren't bad defaults. As a bonus you can port code from C with less risk. Soon you'll be able to compile it directly. I contributed to found the only discrepancy in D vs C code wrt integer (-byte would yield byte instead of int), and it was fixed so that they match exactly C _conventions_.

C integer promotions are what remains of old computers systems which couldn't handle anything but a 'word'. It result in things highly inconsistent on modern 64-bit machines: For example, char/short are automatically promoted to int or unsigned int when an operation is performed on them, but this doesn't happen between int and long. Simple things like adding two int16_t together to get a int16_t in return is really h…

> 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.

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

#46

Post by flohofwoe »

SuchAnonMuchWow wrote: post #28
p0nce wrote: post #5

Earlier quoted context omitted.

D doesn't try to "fix" C integer promotion/casts. It's because they aren't bad defaults. As a bonus you can port code from C with less risk. Soon you'll be able to compile it directly. I contributed to found the only discrepancy in D vs C code wrt integer (-byte would yield byte instead of int), and it was fixed so that they match exactly C _conventions_.

C integer promotions are what remains of old computers systems which couldn't handle anything but a 'word'. It result in things highly inconsistent on modern 64-bit machines: For example, char/short are automatically promoted to int or unsigned int when an operation is performed on them, but this doesn't happen between int and long. Simple things like adding two int16_t together to get a int16_t in return is really h…

Not my idea, but: expanding all values used in expressions to "native word size" (e.g. int64_t on modern machines), and only treat "bit width" and "signedness" as load/store attributes doesn't seem like such a bad idea.

The problem seems to be that (AFAIK) C stopped at 32-bit integers.

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

#47

Post by AndresNavarro »

logicchains wrote: post #16

It says Zig eliminates "implicit conversions unless they are guaranteed to be safe (for example, assigning a u8 value to a u16 variable cannot fail or lose data)", but then suggests that @as should be used when "casting an int to a larger-size int of the same sign". Why should @as be used if it's safe to implicitly convert?

What I took from the article is that it's useful when combined with type inference. So in Zig you could do:

  var x : u8 = 5;
  var y = @as(u32, x);
OR

  var x : u8 = 5;
  var y : u32 = x;
The cast is needed in the first case to force the inference y: u32, otherwise it would be y: u8

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

#48

Post by p0nce »

flohofwoe wrote: post #46
SuchAnonMuchWow wrote: post #28

Earlier quoted context omitted.

C integer promotions are what remains of old computers systems which couldn't handle anything but a 'word'. It result in things highly inconsistent on modern 64-bit machines: For example, char/short are automatically promoted to int or unsigned int when an operation is performed on them, but this doesn't happen between int and long. Simple things like adding two int16_t together to get a int16_t in return is really h…

Not my idea, but: expanding all values used in expressions to "native word size" (e.g. int64_t on modern machines), and only treat "bit width" and "signedness" as load/store attributes doesn't seem like such a bad idea. The problem seems to be that (AFAIK) C stopped at 32-bit integers.

The hardware match C, in x86 using 32-bit integers is not slower than using 64-bit integers.

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

#49

Post by ArtifTh »

TchoBeer wrote: post #44
AnIdiotOnTheNet wrote: post #6

Earlier quoted context omitted.

> Make something idiot-proof and the world invents a better idiot. Sure, but if you only ever give people safety scissors then you're severely limiting the kinds of things that they can build. You have to let people who know what they are doing be able to do what they need to do, so you have to be able to turn the runtime safety off. Zig can do this at the scope level.

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.

C# has GC by default, but you can do manual memory management in "unsafe" blocks

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

#50

Post by darthrupert »

pornel wrote: post #38
themulticaster wrote: post #24

Earlier quoted context omitted.

Could you give some examples where the same value needs to be used in integer and floating-point math? I'm not quite sure if I understood you correctly, but in case you propose that integer float conversion should happen implicitly I have to disagree. While implicitly converting from integer to float/double would probably be fine, implicitly converting from float/double to integer sounds like a recipe for headaches:…

I agree that float int conversions are evil. I would make an exception for int to float conversion for literals. When switching from C to Rust I was annoyed by: if x > 0 not compiling, because that's an integer zero, not a float zero! This makes the compiler feel very petty.

To me that seems equivalent to complaining that the following fails to compile:

    if 0 == "0"
... which is obviously broken code.
Post reply on HN