3 ms·

For context, since I hadn't seen this before: https://github.com/mpv-player/mpv/commit/1e70e82baa9193f6f027338b0fab0f5078971fbe https://github.com/mpv-player/mp

by vitus 3y ago

For context, since I hadn't seen this before: https://github.com/mpv-player/mpv/commit/1e70e82baa9193f6f027338b0fab0f5078971fbe https://github.com/mpv-player/mpv/commit/1e70e82baa9193f6f02... (advisory: _lots_ of profanity)

matheusmoreira 3y ago
I didn't want to link it because if I did I'd feel the need to read the entire commit again. Which I just did. It really is a religious text. It even granted me absolution. When I read it I realized I wasn't alone in thinking the C standard library is total garbage. Sometimes I'd post my opinions on the matter and people would argue with me but there's no arguing with that commit. I become increasingly convinced we should all just start over from scratch every time I read it.
- thechao 3y ago
  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.

by vitus 3y ago

matheusmoreira 3y ago

I didn't want to link it because if I did I'd feel the need to read the entire commit again. Which I just did. It really is a religious text. It even granted me absolution. When I read it I realized I wasn't alone in thinking the C standard library is total garbage. Sometimes I'd post my opinions on the matter and people would argue with me but there's no arguing with that commit. I become increasingly convinced we should all just start over from scratch every time I read it.

thechao 3y ago
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.