3 ms·

I’m working on a compiler right now that generates C. Should I use this for the generated code? (Or should I use glib, musl, or uclib?) A comparison chart woul

I’m working on a compiler right now that generates C. Should I use this for the generated code? (Or should I use glib, musl, or uclib?) A comparison chart would be helpful! Similar to: http://www.etalabs.net/compare_libcs.html http://www.etalabs.net/compare_libcs.html

flukus 8y ago
> Should I use this? (Or should I use glib, musl, or uclib?) I agree that a comparison would be good, but musl and glibc are low level fundamental API's for things like printf and opening files. Glib and this are higher level libraries to build applications with. If you're building a compiler you probably want one of these, for the generated code it would depend a lot on the specifics. Edit - I'll also add that a lot of people's experience with C seems to com from college or beginner material where they're learning in a very bare bones environment. Combine C and libraries like this and it's not just good for app development but can be great for scripting where python or bash would typically be used.
- waruqi 8y ago
  Yes.
AndyKelley 8y ago
To solve the problem in a robust way, the C library has to be part of the target. For example on Debian Linux, glibc is the native libc. On Alpine Linux, musl is the native libc. In LLVM terminology, this is the "C ABI environment" part of the "target triple". If your compiler supports cross compiling, you might look into the strategies that Zig does[1]. If it only supports native builds, you probably want to detect the native libc. Again here it might be useful to look at what Zig does[2]. [1]: https://ziglang.org/download/0.4.0/release-notes.html#Zig-ships-with-libc https://ziglang.org/download/0.4.0/release-notes.html#Zig-sh... [2]: https://ziglang.org/download/0.4.0/release-notes.html#Libc-Detection https://ziglang.org/download/0.4.0/release-notes.html#Libc-D...
- waruqi 8y ago
  That is the standard library, TBOX is just a third-party library, providing some easy-to-use cross-platform modules.
  - sansnomme 8y ago
    Any plans to do a Libc too? A lot of embedded systems like ESP32 could really use a good Libc without having to pull in Linux.
    - waruqi 8y ago
      I haven't got this plan yet., but the tbox has a lightweight and compact libc implementation built in. The interface name looks like this: tb_snprintf, tb_strlcpy, ... You can see https://github.com/tboox/tbox/tree/master/src/tbox/libc https://github.com/tboox/tbox/tree/master/src/tbox/libc
earenndil 8y ago
You've been heavily downvoted because you made a category error. GlibC, musl, and uclibc are implementations of the c standard library[1]. Glib[2], this, and NSPR[3] (among others), on the other hand, abstract away platform-specific things. So whereas strcpy is a standard function that you can count on being there, the process for opening a window is different on windows, mac (quartz), mac (cocoa), unix (x11), unix (wayland), and others; the cross-platform libraries handle this and provide you with a single api for (for example) opening a window. Now, as a language developer, you actually don't have to worry about any of these. The c standard library will be provided by the os and you don't have to think about it. Some programming languages that want to replace c don't rely on the c standard library, but you shouldn't have to worry about that. As for abstracting out different platform apis, I would say that doesn't really belong in your language itself. 1: https://en.wikipedia.org/wiki/C_standard_library https://en.wikipedia.org/wiki/C_standard_library 2: https://developer.gnome.org/glib/ https://developer.gnome.org/glib/ 3: https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSPR https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NS...

flukus 8y ago

> Should I use this? (Or should I use glib, musl, or uclib?) I agree that a comparison would be good, but musl and glibc are low level fundamental API's for things like printf and opening files. Glib and this are higher level libraries to build applications with. If you're building a compiler you probably want one of these, for the generated code it would depend a lot on the specifics. Edit - I'll also add that a lot of people's experience with C seems to com from college or beginner material where they're learning in a very bare bones environment. Combine C and libraries like this and it's not just good for app development but can be great for scripting where python or bash would typically be used.

waruqi 8y ago
Yes.

AndyKelley 8y ago

To solve the problem in a robust way, the C library has to be part of the target. For example on Debian Linux, glibc is the native libc. On Alpine Linux, musl is the native libc. In LLVM terminology, this is the "C ABI environment" part of the "target triple". If your compiler supports cross compiling, you might look into the strategies that Zig does[1]. If it only supports native builds, you probably want to detect the native libc. Again here it might be useful to look at what Zig does[2]. [1]: https://ziglang.org/download/0.4.0/release-notes.html#Zig-ships-with-libc https://ziglang.org/download/0.4.0/release-notes.html#Zig-sh... [2]: https://ziglang.org/download/0.4.0/release-notes.html#Libc-Detection https://ziglang.org/download/0.4.0/release-notes.html#Libc-D...

waruqi 8y ago
That is the standard library, TBOX is just a third-party library, providing some easy-to-use cross-platform modules.
- sansnomme 8y ago
  Any plans to do a Libc too? A lot of embedded systems like ESP32 could really use a good Libc without having to pull in Linux.
  - waruqi 8y ago
    I haven't got this plan yet., but the tbox has a lightweight and compact libc implementation built in. The interface name looks like this: tb_snprintf, tb_strlcpy, ... You can see https://github.com/tboox/tbox/tree/master/src/tbox/libc https://github.com/tboox/tbox/tree/master/src/tbox/libc

earenndil 8y ago

You've been heavily downvoted because you made a category error. GlibC, musl, and uclibc are implementations of the c standard library[1]. Glib[2], this, and NSPR[3] (among others), on the other hand, abstract away platform-specific things. So whereas strcpy is a standard function that you can count on being there, the process for opening a window is different on windows, mac (quartz), mac (cocoa), unix (x11), unix (wayland), and others; the cross-platform libraries handle this and provide you with a single api for (for example) opening a window. Now, as a language developer, you actually don't have to worry about any of these. The c standard library will be provided by the os and you don't have to think about it. Some programming languages that want to replace c don't rely on the c standard library, but you shouldn't have to worry about that. As for abstracting out different platform apis, I would say that doesn't really belong in your language itself. 1: https://en.wikipedia.org/wiki/C_standard_library https://en.wikipedia.org/wiki/C_standard_library 2: https://developer.gnome.org/glib/ https://developer.gnome.org/glib/ 3: https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSPR https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NS...