6 ms·

> Hannah: How is it possible that Zig applications run faster than C code while also having far better security guarantees? In a marketing interview with biase

> Hannah: How is it possible that Zig applications run faster than C code while also having far better security guarantees? In a marketing interview with biased questions, anything is possible. TBH, I have a positive impression of zig, but this kind of interviewing doesn't help it.

pjmlp 6y ago
Indeed, Zig still hasn't a story for use after free issues.
- MaxBarraclough 6y ago
  Not sure what 'story' is intended to mean here. Is use-after-free undefined behaviour in Zig?
  - blueblob 6y ago
    Is use-after-free ever really defined behavior?
    - MaxBarraclough 6y ago
      That would depend on the language and the libraries. You could roll your own 'safe' memory pool in C such that use-after-free doesn't produce undefined behaviour. You'd still have a bug, but it wouldn't have to invoke UB at the level of the C programming language.
    - matheusmoreira 6y ago
      Yes. Undefined behavior exists only in standards. It's perfectly possible for implementations to define everything. https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost-the-api-war/ https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost... > I first heard about this from one of the developers of the hit game SimCity, who told me that there was a critical bug in his application: > it used memory right after freeing it, a major no-no that happened to work OK on DOS but would not work under Windows where memory that is freed is likely to be snatched up by another running application right away. > The testers on the Windows team were going through various popular applications, testing them to make sure they worked OK, but SimCity kept crashing. > They reported this to the Windows developers, who disassembled SimCity, stepped through it in a debugger, found the bug, and added special code that checked if SimCity was running, and if it did, ran the memory allocator in a special mode in which you could still use memory after freeing it.
      - deleted 6y ago
        [deleted]
  - AnIdiotOnTheNet 6y ago
    There isn't really anything in the language that prevents use-after-free, partially because allocation isn't even part of the language and exists entirely in userland code. However, IIRC the standard library does include an allocator that tries to detect use-after-free.
    - skohan 6y ago
      Isn't that an intentional design decision in Zig? As far as I understood, Zig isn't trying to "solve" memory management, it's trying to provide manual memory management with better tools than C to help you do it right, but it's explicitly not trying to save you from yourself in this respect.
      - pjmlp 6y ago
        Except that C and C++ already provide similar tools, one just needs to actually enable them.
        MaxBarraclough 6y ago
        I don't follow. You recently pointed out to me that most of the serious security bugs in the Chromium codebase (C++) are rooted in memory-management. [0] It's no simple thing to fix these bugs. Not even Google can do so in their most treasured code. [0] https://news.ycombinator.com/item?id=26862330 https://news.ycombinator.com/item?id=26862330
        pjmlp 6y ago
        The point being that Zig improves very little regarding that, because it is based on the same kind of tooling.
    - matheusmoreira 6y ago
      > allocation isn't even part of the language It's not supposed to be. In most cases, memory allocation is an operating system concept. As a systems programming language, zig must not abstract this away from the programmer.
- smasher164 6y ago
  The question is if this should be done at the language-level or library-level. With sufficient metaprogramming capabilities, an enterprising programmer could write safe resource management abstractions for Zig. However, this wouldn't make the language "safe by default," which seems to be what Rust programmers are bringing with this criticism. Even if Zig doesn't bring safety by default to the language, however, I think you could get it in practice by making the standard library enforce safety. Then, unless someone goes out of their way to write their own libraries from scratch and eschew all of the safety mechanisms, they would likely live in this safety bubble.
  - pcwalton 6y ago
    Can you write a borrow checker that enforces alias-xor-mut using metaprogramming? I'm skeptical, because of the flow sensitivity you really want to make it practical.
    - smasher164 6y ago
      Not sure, but I became optimistic of there being some solution after I saw someone implement affine typing using stateful template metaprogramming: https://godbolt.org/z/PnPPrnPjY https://godbolt.org/z/PnPPrnPjY.
      - pcwalton 6y ago
        That's neat, but also flow-insensitive (and wow, generating a definition for every single use of a variable can't be good for compile-time memory usage).
        smasher164 6y ago
        Yeah, I'm unaware of any push to bring flow-sensitive typing, or a mechanism that affords flow-sensitive analysis, to Zig.
    - pron 6y ago
      You could with some changes to the type capabilities, but I don't think that's the right direction. The main question is do we want soundness or not? This is a general question for various correctness properties, and, at least in the formal methods space, the answer seems to be "not always." Soundness has a cost, and stopping 100% of UAF bugs for the cost of making the language more complex and even adding a few bugs of other kinds, might not be worth it if you can stop 99% of them for a fraction of the cost. I think the goal should be to not have soundness -- IMO it has more downsides than upsides in this case -- and make good runtime detection joined with fast compile/test cycle and even automatic test generation.
bsedlm 6y ago
I like to think Zig is what we would have if we knew back then (when desiging C) what we know now. (note: "we" excludes me personally but I mean it as "us who work and study comptuing at large")
- pjmlp 6y ago
  We already knew in 1981. "Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to--they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980, language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law." C.A.R Hoare on his Turing award speech in 1981.
- not2b 6y ago
  The difficulty is that in the days when C was being designed, computers were much more irregular than they are today. There were one's complement machines, machines that didn't have power-of-two word sizes, no standardization of character sets, IEEE floating point hadn't been invented yet. The irregular machines weren't fringe stuff, they were the dominant architectures (IBM 360/370, DEC PDP-10, Pr1me, just a big collection of weird stuff). And compiler technology was much less advanced. So C was a messy compromise.
  - dnautics 6y ago
    Iirc, C was also designed by committee, and a lot of industry players got some of their grubby hands on the spec... (I could be wrong) but I belive the utter mess that is short/long/char sizes arises from hardware manufacturers wanting their code to be "trivially portable" across platforms with different machine words.
    - not2b 6y ago
      No, the different sizes were done by the original creators, not by some committee. They had to: a PDP-11 is a 16-bit machine, a PDP-10 is 36-bit, etc.

pjmlp 6y ago

Indeed, Zig still hasn't a story for use after free issues.

MaxBarraclough 6y ago
Not sure what 'story' is intended to mean here. Is use-after-free undefined behaviour in Zig?
- blueblob 6y ago
  Is use-after-free ever really defined behavior?
  - MaxBarraclough 6y ago
    That would depend on the language and the libraries. You could roll your own 'safe' memory pool in C such that use-after-free doesn't produce undefined behaviour. You'd still have a bug, but it wouldn't have to invoke UB at the level of the C programming language.
  - matheusmoreira 6y ago
    Yes. Undefined behavior exists only in standards. It's perfectly possible for implementations to define everything. https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost-the-api-war/ https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost... > I first heard about this from one of the developers of the hit game SimCity, who told me that there was a critical bug in his application: > it used memory right after freeing it, a major no-no that happened to work OK on DOS but would not work under Windows where memory that is freed is likely to be snatched up by another running application right away. > The testers on the Windows team were going through various popular applications, testing them to make sure they worked OK, but SimCity kept crashing. > They reported this to the Windows developers, who disassembled SimCity, stepped through it in a debugger, found the bug, and added special code that checked if SimCity was running, and if it did, ran the memory allocator in a special mode in which you could still use memory after freeing it.
    - deleted 6y ago
      [deleted]
- AnIdiotOnTheNet 6y ago
  There isn't really anything in the language that prevents use-after-free, partially because allocation isn't even part of the language and exists entirely in userland code. However, IIRC the standard library does include an allocator that tries to detect use-after-free.
  - skohan 6y ago
    Isn't that an intentional design decision in Zig? As far as I understood, Zig isn't trying to "solve" memory management, it's trying to provide manual memory management with better tools than C to help you do it right, but it's explicitly not trying to save you from yourself in this respect.
    - pjmlp 6y ago
      Except that C and C++ already provide similar tools, one just needs to actually enable them.
      - MaxBarraclough 6y ago
        I don't follow. You recently pointed out to me that most of the serious security bugs in the Chromium codebase (C++) are rooted in memory-management. [0] It's no simple thing to fix these bugs. Not even Google can do so in their most treasured code. [0] https://news.ycombinator.com/item?id=26862330 https://news.ycombinator.com/item?id=26862330
        pjmlp 6y ago
        The point being that Zig improves very little regarding that, because it is based on the same kind of tooling.
  - matheusmoreira 6y ago
    > allocation isn't even part of the language It's not supposed to be. In most cases, memory allocation is an operating system concept. As a systems programming language, zig must not abstract this away from the programmer.
smasher164 6y ago
The question is if this should be done at the language-level or library-level. With sufficient metaprogramming capabilities, an enterprising programmer could write safe resource management abstractions for Zig. However, this wouldn't make the language "safe by default," which seems to be what Rust programmers are bringing with this criticism. Even if Zig doesn't bring safety by default to the language, however, I think you could get it in practice by making the standard library enforce safety. Then, unless someone goes out of their way to write their own libraries from scratch and eschew all of the safety mechanisms, they would likely live in this safety bubble.
- pcwalton 6y ago
  Can you write a borrow checker that enforces alias-xor-mut using metaprogramming? I'm skeptical, because of the flow sensitivity you really want to make it practical.
  - smasher164 6y ago
    Not sure, but I became optimistic of there being some solution after I saw someone implement affine typing using stateful template metaprogramming: https://godbolt.org/z/PnPPrnPjY https://godbolt.org/z/PnPPrnPjY.
    - pcwalton 6y ago
      That's neat, but also flow-insensitive (and wow, generating a definition for every single use of a variable can't be good for compile-time memory usage).
      - smasher164 6y ago
        Yeah, I'm unaware of any push to bring flow-sensitive typing, or a mechanism that affords flow-sensitive analysis, to Zig.
  - pron 6y ago
    You could with some changes to the type capabilities, but I don't think that's the right direction. The main question is do we want soundness or not? This is a general question for various correctness properties, and, at least in the formal methods space, the answer seems to be "not always." Soundness has a cost, and stopping 100% of UAF bugs for the cost of making the language more complex and even adding a few bugs of other kinds, might not be worth it if you can stop 99% of them for a fraction of the cost. I think the goal should be to not have soundness -- IMO it has more downsides than upsides in this case -- and make good runtime detection joined with fast compile/test cycle and even automatic test generation.

bsedlm 6y ago

I like to think Zig is what we would have if we knew back then (when desiging C) what we know now. (note: "we" excludes me personally but I mean it as "us who work and study comptuing at large")

pjmlp 6y ago
We already knew in 1981. "Many years later we asked our customers whether they wished us to provide an option to switch off these checks in the interests of efficiency on production runs. Unanimously, they urged us not to--they already knew how frequently subscript errors occur on production runs where failure to detect them could be disastrous. I note with fear and horror that even in 1980, language designers and users have not learned this lesson. In any respectable branch of engineering, failure to observe such elementary precautions would have long been against the law." C.A.R Hoare on his Turing award speech in 1981.
not2b 6y ago
The difficulty is that in the days when C was being designed, computers were much more irregular than they are today. There were one's complement machines, machines that didn't have power-of-two word sizes, no standardization of character sets, IEEE floating point hadn't been invented yet. The irregular machines weren't fringe stuff, they were the dominant architectures (IBM 360/370, DEC PDP-10, Pr1me, just a big collection of weird stuff). And compiler technology was much less advanced. So C was a messy compromise.
- dnautics 6y ago
  Iirc, C was also designed by committee, and a lot of industry players got some of their grubby hands on the spec... (I could be wrong) but I belive the utter mess that is short/long/char sizes arises from hardware manufacturers wanting their code to be "trivially portable" across platforms with different machine words.
  - not2b 6y ago
    No, the different sizes were done by the original creators, not by some committee. They had to: a PDP-11 is a 16-bit machine, a PDP-10 is 36-bit, etc.