4 ms·

Sometimes I think a "better C" is just C, but with a rational standard library. Then I remember that we're not allowed to have nice things.

matheusmoreira 3y ago
I agree completely. I started writing freestanding C exclusively and it's a much better language compared to hosted C. There's zero cruft for you to deal with. It's just C and whatever you make of it. Nothing holding you back. Some years ago I started a liblinux project so I could have lightweight Linux system calls but then I discovered the kernel's nolibc headers which are vastly superior. Now I'm working on a Lisp written completely in freestanding C with zero libc bullshit. Turns out you can get surprisingly far with a statically allocated array of bytes.
- thechao 3y ago
  The only facilities I really need, 80% if the time, are FILE* — but I much prefer ‘fopencookie’ as the API: I can have a uniform “FILE*” API, and provide a default string-wrapper–to-user-allocator API. (This is when I’m writing library code.)
  - matheusmoreira 3y ago
    I vastly prefer using the open, close, read and write system calls. They are actually extremely easy to work with, easier than stdio functions. No buffering unless you explicitly add it: when you write data out, you know it's been written. Sizes are always known so you can actually implement proper memory and string structures in C literally from the ground up. They just return a negated errno constant to signal errors which means there's no brain damage like thread local global errno variables anywhere in your code. It's such a good feeling. Buffering is the only real reason to build on top of those system calls. I wrote a very simple read buffer for my language's parser. It just sort of appeared organically during development. Haven't bothered to buffer writes.

4 ms·

Sometimes I think a "better C" is just C, but with a rational standard library. Then I remember that we're not allowed to have nice things.

by thechao 3y ago

matheusmoreira 3y ago
I agree completely. I started writing freestanding C exclusively and it's a much better language compared to hosted C. There's zero cruft for you to deal with. It's just C and whatever you make of it. Nothing holding you back. Some years ago I started a liblinux project so I could have lightweight Linux system calls but then I discovered the kernel's nolibc headers which are vastly superior. Now I'm working on a Lisp written completely in freestanding C with zero libc bullshit. Turns out you can get surprisingly far with a statically allocated array of bytes.
- thechao 3y ago
  The only facilities I really need, 80% if the time, are FILE* — but I much prefer ‘fopencookie’ as the API: I can have a uniform “FILE*” API, and provide a default string-wrapper–to-user-allocator API. (This is when I’m writing library code.)
  - matheusmoreira 3y ago
    I vastly prefer using the open, close, read and write system calls. They are actually extremely easy to work with, easier than stdio functions. No buffering unless you explicitly add it: when you write data out, you know it's been written. Sizes are always known so you can actually implement proper memory and string structures in C literally from the ground up. They just return a negated errno constant to signal errors which means there's no brain damage like thread local global errno variables anywhere in your code. It's such a good feeling. Buffering is the only real reason to build on top of those system calls. I wrote a very simple read buffer for my language's parser. It just sort of appeared organically during development. Haven't bothered to buffer writes.