4 ms·

Standard C is not suitable for writing kernels anymore due to all the ridiculous hostile interpretions of the standard (mainly typed based aliasing rules). I m

Standard C is not suitable for writing kernels anymore due to all the ridiculous hostile interpretions of the standard (mainly typed based aliasing rules). I mean you can't even write an allocator in standard C.

monocasa 5y ago
Both sides are true IMO. The kernel isn't capable of being written totally in standards compliant C, and it'd probably be better off if that fact wasn't used as carte blanche to write non standards compliant code where it doesn't provide a tangible benefit.
jstimpfle 5y ago
Why can't you write an allocator???
- monocasa 5y ago
  Casting pointers to different object types and then dereferencing them is undefined behavior.
  - synergy20 5y ago
    this is new to me, any source of it? Thanks!
    - synergy20 5y ago
      now got it, strict aliasing that is.
shadowofneptune 5y ago
Then in this case the portability offered by C is false. Could be an equally valid approach to place the required behavior into separate modules written with an assembler.
- pjmlp 5y ago
  It was never true, "portable" C programs are full of #ifdef spaghetti.
woodruffw 5y ago
> I mean you can't even write an allocator in standard C. I might be missing something, but I don't believe this is true? The type aliasing rules have an explicit carve-out for `char *` aliases of other types, which is intended to solve this exact issue. Similarly, C99 and C11 both allow aliasing through a union of pointers without violating the strict aliasing rule.
- astrange 5y ago
  You can't implement `malloc()` in C because the pointers it returns are defined to be pointers to different objects, and if you can see the implementation of `malloc` then you know it's returning pointers to the same object (the page it gets from mmap/sbrk). There's no functionality in C to actually do what it says except for the function itself.
  - woodruffw 5y ago
    My understanding is that this is covered by the "effective type" language in both C99 and C11[1]. malloc itself is specified to return a void pointer, but the effective type established during assignment circumvents what would otherwise be UB via aliasing[2]. Edit: Specifically, the reasoning is: 1. Allocated objects have no declared type; 2. 6.5.6: Objects with no declared type have the type of their accessing lvalue 3. 6.5.7: Access of a stored value is valid for lvalue expressions that are type compatible with the effective type. So there's no UB here. `malloc` itself doesn't need to know about the effective type produced by the lvalue, and C (at least C99 onwards) respects that type for strict aliasing purposes. [1]: https://port70.net/%7Ensz/c/c11/n1570.html#6.5p6 https://port70.net/%7Ensz/c/c11/n1570.html#6.5p6 [2]: https://port70.net/%7Ensz/c/c11/n1570.html#6.5p7 https://port70.net/%7Ensz/c/c11/n1570.html#6.5p7
    - astrange 5y ago
      The issue in C99 is: > The lifetime of an allocated object extends from the allocation until the deallocation. Each such allocation shall yield a pointer to an object disjoint from any other object. If the implementation of malloc is visible, then it can be inlined etc., and then you have to deal with the effects of this obviously not being true.

monocasa 5y ago

Both sides are true IMO. The kernel isn't capable of being written totally in standards compliant C, and it'd probably be better off if that fact wasn't used as carte blanche to write non standards compliant code where it doesn't provide a tangible benefit.

jstimpfle 5y ago

Why can't you write an allocator???

monocasa 5y ago
Casting pointers to different object types and then dereferencing them is undefined behavior.
- synergy20 5y ago
  this is new to me, any source of it? Thanks!
  - synergy20 5y ago
    now got it, strict aliasing that is.

shadowofneptune 5y ago

Then in this case the portability offered by C is false. Could be an equally valid approach to place the required behavior into separate modules written with an assembler.

pjmlp 5y ago
It was never true, "portable" C programs are full of #ifdef spaghetti.

woodruffw 5y ago

> I mean you can't even write an allocator in standard C. I might be missing something, but I don't believe this is true? The type aliasing rules have an explicit carve-out for `char *` aliases of other types, which is intended to solve this exact issue. Similarly, C99 and C11 both allow aliasing through a union of pointers without violating the strict aliasing rule.

astrange 5y ago
You can't implement `malloc()` in C because the pointers it returns are defined to be pointers to different objects, and if you can see the implementation of `malloc` then you know it's returning pointers to the same object (the page it gets from mmap/sbrk). There's no functionality in C to actually do what it says except for the function itself.
- woodruffw 5y ago
  My understanding is that this is covered by the "effective type" language in both C99 and C11[1]. malloc itself is specified to return a void pointer, but the effective type established during assignment circumvents what would otherwise be UB via aliasing[2]. Edit: Specifically, the reasoning is: 1. Allocated objects have no declared type; 2. 6.5.6: Objects with no declared type have the type of their accessing lvalue 3. 6.5.7: Access of a stored value is valid for lvalue expressions that are type compatible with the effective type. So there's no UB here. `malloc` itself doesn't need to know about the effective type produced by the lvalue, and C (at least C99 onwards) respects that type for strict aliasing purposes. [1]: https://port70.net/%7Ensz/c/c11/n1570.html#6.5p6 https://port70.net/%7Ensz/c/c11/n1570.html#6.5p6 [2]: https://port70.net/%7Ensz/c/c11/n1570.html#6.5p7 https://port70.net/%7Ensz/c/c11/n1570.html#6.5p7
  - astrange 5y ago
    The issue in C99 is: > The lifetime of an allocated object extends from the allocation until the deallocation. Each such allocation shall yield a pointer to an object disjoint from any other object. If the implementation of malloc is visible, then it can be inlined etc., and then you have to deal with the effects of this obviously not being true.