[HN Gopher] An usable and maximally efficient C standard library
       ___________________________________________________________________
        
       An usable and maximally efficient C standard library
        
       Author : ssklash
       Score  : 30 points
       Date   : 2023-12-04 21:47 UTC (1 hours ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | allanrbo wrote:
       | Fine looking general helper functions, but I find it a bit
       | confusing to call this a "standard library". That has a
       | particular meaning in C/C++ already.
        
         | andy99 wrote:
         | It's closer to what would be called builtins in python. Still
         | looks useful.
        
       | linkdd wrote:
       | It's not a "standard" library though...
       | 
       | It's a nice "toolbox", but definitely not "standard" (word which
       | has a very specific definition).
        
       | _benj wrote:
       | Oh, I like this!!
       | 
       | I might need to look deeper but how is memory management done?
       | 
       | It seems like there's some allocation happening on the
       | background? For example, the split() or string_to_json(), some
       | memory is happening somewhere.
       | 
       | I ask for more than curiosity, I wonder if this could be used in
       | embedded development.
       | 
       | Either way, seems like a fantastic toolkit for working in C!
       | 
       | I'm the most excited about the string functions, because idk why
       | but I find myself doing a bunch of string manipulation quite
       | often, and not having to jump out of C or manually implement
       | algos sounds awesome!
        
       | gren236 wrote:
       | That's the most "C" readme that I've seen. Looks really
       | interesting though.
        
       | csdvrx wrote:
       | to me, that'd be jart cosmopolitan libc so if I mean to fopen() I
       | can fopen
       | 
       | https://justine.lol/cosmopolitan/documentation.html#fopen
        
       | tedunangst wrote:
       | sorted_ulong_long_ptrs, where have you been all my life?
        
       | acuozzo wrote:
       | Pretty good work so far. Some nitpicks...
       | 
       | The library uses malloc rather liberally, but rarely (if, ever)
       | checks the result. Allocation functions failing to allocate is a
       | recoverable state1.
       | 
       | In addition to this, the library does not provide a builtin
       | mechanism to override malloc from the stdlib. Freestanding
       | targets exist! Also, on hosted targets, who isn't using
       | aligned_alloc in at least some places nowadays?
       | 
       | Having to do the following song & dance sucks.
       | #define malloc xmalloc       #include <yourthing.h>       #undef
       | malloc
       | 
       | [1] _I 'd wager most C programmers today write programs in C to
       | exercise as much control (maximal determinism?) as possible
       | without having to write in *-Assembly. Yes, I'm aware that its
       | abstract model of computation and semantic complexity make it
       | anything but "low-level", but C can get rather close on some
       | architectures with some compilers._
        
       | secondcoming wrote:
       | It would be nice if functions that take a `const char*` parameter
       | also took a `length` parameter where appropriate.
       | 
       | There's a whole lot of `strlen`'ing going on!
       | 
       | Cool though
        
       | saagarjha wrote:
       | This is cute, and probably useful for hobby projects. If I may,
       | it would be nice to have slightly more generic versions of some
       | of the interfaces, and perhaps consider dropping "maximally"
       | efficient from your tagline. Not only is it cleaner, you are less
       | likely to get yelled at by people who focus on code like this:
       | /* Function to concatenate multiple strings into a new string */
       | static inline char *concatenate(const char *str1, const char
       | *str2)       {           size_t len1 = strlen(str1);
       | size_t len2 = strlen(str2);                  char *result = (char
       | *)malloc(len1 + len2 + 1);           strcpy(result, str1);
       | strcat(result, str2);                  return result;       }
        
       | RcouF1uZ4gsC wrote:
       | Some observations:
       | 
       | 1. Who owns the memory? How is the memory freed?
       | 
       | 2. C doesn't have a lambda syntax, so using functional idioms
       | like map, etc is a bit more boilerplate.
       | 
       | 3. Lack of generics is painful (print_ushort_array,
       | print_double_array, print_ulong_array, print_long_long_array)
        
       | typon wrote:
       | Any maximally efficient C library should ideally do zero
       | allocations and if it needs to, ask the user how they manage
       | their memory.
        
       | asveikau wrote:
       | There are red flags in some of the function signatures that the
       | author doesn't understand C.
       | 
       | For example functions that I guess are meant to be generic arrays
       | that take int*. You could write volumes on how to approach
       | generic arrays in C but this is certainly not one of them.
       | 
       | Also the use of "c standard library" is weird here. Any C
       | programmer reading this phrase assumes a reasonably standard
       | conformant libc. This is a bunch of interfaces the author made
       | up.
       | 
       | Sorry for being negative but this doesn't pass a "production
       | quality c code" at-a-distance sniff test.
        
       ___________________________________________________________________
       (page generated 2023-12-04 23:00 UTC)