6 ms·

I wish we could do away with (parts of) libc entirely. Many of its design principles and limitations date back to its inception and don't make sense today, even

I wish we could do away with (parts of) libc entirely. Many of its design principles and limitations date back to its inception and don't make sense today, even on "embedded" systems. - function names limited to 6 characters (because of compiler/linker memory limits at the time?) - non-reentrency of many functions (strtok(), errno...) - dangerous string manipulation functions (see the various iterations of strcpy()) - and so much more... Of course, I'm missing the point. Libc continues on because it's standard and backwards-compatible, and lets you leverage 50 years of software ecosystem. Nevertheless, I'd love to see what a modern clean-slate implementation might look like. I'm sure there'd be much disagreement about what warrants replacement and what doesn't ;)

mangix 7y ago
musl?
- saagarjha 7y ago
  musl still has many of the same issues, as it needs to remain compatible with POSIX.
_rtld_global_ro 7y ago
errno is thread-safe as it resides in TLS. Part of libc such as pthread is very hard, and so does the dynamic linker. The latter is supposed to handle TLS data as required by TLS/elf spec, which more or less requires a full thread/pthread implementation. As a result, it is rather difficult to break down libc, without writing the whole thing in the first place. golang might be an exception (no linkage against libc), but AFAIK it doesn't use TLS. It's a pretty hard task to tackle libc (not just string functions, obviously), maybe for the same reason there're only a few libc implementations (support full dynamic linking).
- weberc2 7y ago
  What is TLS? > Part of libc such as pthread is very hard, and so does the dynamic linker. What does this mean? I'm having trouble parsing this as English much less making sense of the argument :) > It's a pretty hard task to tackle libc (not just string functions, obviously), maybe for the same reason there're only a few libc implementations (support full dynamic linking). Why does libc ship with string functions in the first place? What is special about strings that they are included in libc while other data structures (to my knowledge) are not? Presumably you don't need strings to implement malloc or other parts of libc?
  - saagarjha 7y ago
    Strings ship with libc because pretty much every language ships with string manipulation routines. You need them to basically do anything that isn’t pure computation.
    - _kst_ 7y ago
      libc includes string functions because C requires string manipulation functions. Other languages may or may not make use of C's string functions.
      - saagarjha 7y ago
        Yes, because they ship with their own string type.
    - weberc2 7y ago
      Granted, but pretty much every language also ships with routines for other data structures, and I would think that you need things like lists/slices more often than you need string routines.
  - AceJohnny2 7y ago
    > What is TLS? Thread-Local Storage: https://en.wikipedia.org/wiki/Thread-local_storage https://en.wikipedia.org/wiki/Thread-local_storage
- aidenn0 7y ago
  Neither pthreads nor a dynamic linker are required for libc. pthreads is part of the POSIX standard, not the C standard, and many libc implementations over the years have not supported dynamic linking. To give you an idea, here's a chip used by at least one of the products developed by the author: https://www.st.com/en/microcontrollers-microprocessors/stm32l151rb.html https://www.st.com/en/microcontrollers-microprocessors/stm32... 16KB of ram. You're not going to see any linking on this because you're probably running everything in a single address space anyways.
kevin_thibedeau 7y ago
strtok_r() should be available on any halfway decent embedded platform.
wahern 7y ago
> I'm sure there'd be much disagreement about what warrants replacement and what doesn't ; How many backwards incompatible variations of C++ std::string have there been, simply in terms of the standard (not extensions). Two? Three? glibc has been turning their nose up at strlcpy(3) for literally 20 years, and yet still doesn't provide a comparable one-liner alternative that guarantees to always leave a NUL-terminated string behind (i.e. doesn't leave a loaded gun lying around). A good string interface is impossible to pin down because a "string" is the anti-thesis of a proper data structure. C dipped its toes in the better string library waters with Annex K, which saw almost no uptake; even the original sponsor, Microsoft, never shipped a complete implementation. C would be wise to avoid chasing the mirage of a better string library. In general if you're thinking in terms of "strings", C is the wrong language. C being an inconvenient language for programming with that mindset is a good thing. (I would love to see strlcpy added, but the fact it's so divisive is maybe a strong hint that there's no way to placate a substantial minority of people, not even the most pragmatic of users. Anything involving the str* API is a lose-lose at this point.) What C really needs are some primitives for bounded arrays and slices. There are some very good, very simple proposals out there, but no compiler vendor has actually shipped them and the C committee has been burned several times before by standardizing de novo interfaces.
- saagarjha 7y ago
  > glibc has been turning their nose up at strlcpy(3) for literally 20 years, and yet still doesn't provide a comparable one-liner alternative that guarantees to always leave a NUL-terminated string behind (i.e. doesn't leave a loaded gun lying around). snprintf(destination, sizeof(destination), "%s", source); ?
  - wahern 7y ago
    snprintf(3) can fail with ENOMEM. In fact, at one point (not sure about now), glibc could fail with ENOMEM even for %s.[1] The size argument is an int, not size_t, so there are arithmetic overflow problems. The return value is also an int, creating underflow and overflow hazards, though the degree to which this is a problem, and the extent to which it's a feature, vary. Everybody has a different opinion about how truncation should be signaled, if at all. [1] Because glibc snprintf uses (or at least used) its stdio FILE interfaces for implementing snprintf, and it conditionally uses malloc for initializing a temporary FILE object.

mangix 7y ago

musl?

saagarjha 7y ago
musl still has many of the same issues, as it needs to remain compatible with POSIX.

_rtld_global_ro 7y ago

errno is thread-safe as it resides in TLS. Part of libc such as pthread is very hard, and so does the dynamic linker. The latter is supposed to handle TLS data as required by TLS/elf spec, which more or less requires a full thread/pthread implementation. As a result, it is rather difficult to break down libc, without writing the whole thing in the first place. golang might be an exception (no linkage against libc), but AFAIK it doesn't use TLS. It's a pretty hard task to tackle libc (not just string functions, obviously), maybe for the same reason there're only a few libc implementations (support full dynamic linking).

weberc2 7y ago
What is TLS? > Part of libc such as pthread is very hard, and so does the dynamic linker. What does this mean? I'm having trouble parsing this as English much less making sense of the argument :) > It's a pretty hard task to tackle libc (not just string functions, obviously), maybe for the same reason there're only a few libc implementations (support full dynamic linking). Why does libc ship with string functions in the first place? What is special about strings that they are included in libc while other data structures (to my knowledge) are not? Presumably you don't need strings to implement malloc or other parts of libc?
- saagarjha 7y ago
  Strings ship with libc because pretty much every language ships with string manipulation routines. You need them to basically do anything that isn’t pure computation.
  - _kst_ 7y ago
    libc includes string functions because C requires string manipulation functions. Other languages may or may not make use of C's string functions.
    - saagarjha 7y ago
      Yes, because they ship with their own string type.
  - weberc2 7y ago
    Granted, but pretty much every language also ships with routines for other data structures, and I would think that you need things like lists/slices more often than you need string routines.
- AceJohnny2 7y ago
  > What is TLS? Thread-Local Storage: https://en.wikipedia.org/wiki/Thread-local_storage https://en.wikipedia.org/wiki/Thread-local_storage
aidenn0 7y ago
Neither pthreads nor a dynamic linker are required for libc. pthreads is part of the POSIX standard, not the C standard, and many libc implementations over the years have not supported dynamic linking. To give you an idea, here's a chip used by at least one of the products developed by the author: https://www.st.com/en/microcontrollers-microprocessors/stm32l151rb.html https://www.st.com/en/microcontrollers-microprocessors/stm32... 16KB of ram. You're not going to see any linking on this because you're probably running everything in a single address space anyways.

kevin_thibedeau 7y ago

strtok_r() should be available on any halfway decent embedded platform.

wahern 7y ago

> I'm sure there'd be much disagreement about what warrants replacement and what doesn't ; How many backwards incompatible variations of C++ std::string have there been, simply in terms of the standard (not extensions). Two? Three? glibc has been turning their nose up at strlcpy(3) for literally 20 years, and yet still doesn't provide a comparable one-liner alternative that guarantees to always leave a NUL-terminated string behind (i.e. doesn't leave a loaded gun lying around). A good string interface is impossible to pin down because a "string" is the anti-thesis of a proper data structure. C dipped its toes in the better string library waters with Annex K, which saw almost no uptake; even the original sponsor, Microsoft, never shipped a complete implementation. C would be wise to avoid chasing the mirage of a better string library. In general if you're thinking in terms of "strings", C is the wrong language. C being an inconvenient language for programming with that mindset is a good thing. (I would love to see strlcpy added, but the fact it's so divisive is maybe a strong hint that there's no way to placate a substantial minority of people, not even the most pragmatic of users. Anything involving the str* API is a lose-lose at this point.) What C really needs are some primitives for bounded arrays and slices. There are some very good, very simple proposals out there, but no compiler vendor has actually shipped them and the C committee has been burned several times before by standardizing de novo interfaces.

saagarjha 7y ago
> glibc has been turning their nose up at strlcpy(3) for literally 20 years, and yet still doesn't provide a comparable one-liner alternative that guarantees to always leave a NUL-terminated string behind (i.e. doesn't leave a loaded gun lying around). snprintf(destination, sizeof(destination), "%s", source); ?
- wahern 7y ago
  snprintf(3) can fail with ENOMEM. In fact, at one point (not sure about now), glibc could fail with ENOMEM even for %s.[1] The size argument is an int, not size_t, so there are arithmetic overflow problems. The return value is also an int, creating underflow and overflow hazards, though the degree to which this is a problem, and the extent to which it's a feature, vary. Everybody has a different opinion about how truncation should be signaled, if at all. [1] Because glibc snprintf uses (or at least used) its stdio FILE interfaces for implementing snprintf, and it conditionally uses malloc for initializing a temporary FILE object.