1. 16
  1. 6

    To make it more complicated, the author is assuming a byte is 8 bits. I do some work on a TI C2000 where a “byte” (or really the addressable unit) is 16 bits.

    1. 4

      Do not conflate addressable unit with byte.

    2. 3

      7 bit bytes for the win.

      1. 2

        Last year’s DEFCON CTF used an architecture with 9 bit bytes.

      2. 2

        This really seems like a series of own goals based on the incorrect assumption that all optimization depends on taking away the ability of a lower level language to address memory directly. Of course, languages like Lua or Haskell have an abstract state in which we can simplify memory access by making sure references to memory do not overlap and are strictly associated with a type. But C and C++ are not designed to provide that level of insulation from the processor memory model, so the compiler developer needs to think differently.

        1. 2

          Optimizations do depend on “pointers are not integers” or inability to guess/manufacture pointers. Otherwise you can’t even prove external pointers do not alias with local variables.

          1. 1

            Some optimizations depend on aliasing rules. But a great deal of optimization does not. So it is incorrect to claim that straightforward C type pointer semantics is incompatible with optimization in general. You could show that that aliasing based optimizations are super important to C code, but I have never seen anyone provide any data for that.

            In general: “These types of optimizations are available in high level languages, but harder or impossible in C unless we make it impossible to use so let’s make C impossible to use” is not super persuasive.

            1. 2

              Eh no? This is not about any specific aliasing rule. If pointers are integers, int a = 1; f(); /* use a */ can’t be optimized to /* use 1 */ because f can guess the address of a and modify it. This is disastrous.

              1. 0

                Oh come on. The compiler is not required to protect programmers against such errors - and it doesn’t need to rely on aliasing rules for that. In fact; global declarations int a=1, *b = &a; plus f() { …. x = a; *b = 2; y = a;] is conforming C code - the compiler is NOT permitted to replace both a’ s with 1s. You want permission to violate basic language semantics. C does not have borrow-checker semantics, and Rust does not have it for unsafe code. That’ s a constraint on the compiler you should not try to fix by breaking the languages. The C programmer is supposed to know to use “const” or restricted.