6 ms·

ZPL: (Almost) C99 Powerkit

73 points by up2isomorphism 6y ago

deleted 6y ago
[deleted]
wg0 6y ago
This is beautiful. I think I am going to toy around with it in a project I have been dreaming about.
deleted 6y ago
[deleted]
MaxBarraclough 6y ago
> Most parts of the library are written in pure C99. There are however, some additional components that require C11 to work (notably in the Threading module). As long as you are using minimal version (ZPL_NANO), and manually enable modules, the C99 support should be just fine. I think it would be better to describe it as a C11 library. I didn't know what to make of 'almost C99', which might refer to limited use of compiler-specific features, for instance.
- kevin_thibedeau 6y ago
  There are compilers that don't support C11. Knowing that downgrading to C99 is a simple procedure is worthwhile.
  - MaxBarraclough 6y ago
    Sure, but that wasn't my point. almost C99 is unclear, unless you already know the intent. It's telling me which language the framework isn't written in. 90% C99, 10% C11 would be fine.
szanni 6y ago
This looks like a nice and concise library. Single header file, many useful functions, and a usable license. The only thing I really dislike are all of the typedefs. zpl_u64 zpl_crc64(void const *data, zpl_isize len); Const correctness, good! But why is the size parameter signed? Why not use size_t and uint64_t like the C stdlib?
- messe 6y ago
  The zpl_u64 seems to be because they're trying to support older versions of the MSVC compiler[1]. As for why they're using a signed size parameter, I'm not really sure. One idiom they appear to use often is[2]: for (...; x--; y++) where x is a size-type of some kind. They may be defaulting to signed size types to avoid errors in case somebody decides to change to above to: for (...; x-- >= 0; y++) There's even a macro zpl_size_of: #define zpl_size_of(x) (zpl_isize)(sizeof(x)) But the real weirdness is in the other macros: #define cast(Type) (Type) ...just why? And #define ZPL_MULTILINE(...) #__VA_ARGS__ is supposed to be a way of having multiline literals in C. But, everything inside the "..." has to be valid C tokens. It might work as a string literal in many cases, but it's misleading at best and broken at worst. I'm not sure what the advantage of the following is vs. just setting the bits using & and | which every C programmer should already be familiar with: #define ZPL_MASK_SET(var, set, mask) \ do { \ if (set) \ (var) |= (mask); \ else \ (var) &= ~(mask); \ } while (0) There's surely no excuse for this: #define zpl_global static // Global variables While a lot of the library looks useful, stuff like the above makes it feel like it's written by somebody who knows C, but doesn't feel fully comfortable writing it. [1]: https://github.com/zpl-c/zpl/blob/master/code/header/essentials/types.h#L11-L40 https://github.com/zpl-c/zpl/blob/master/code/header/essenti... [2]: https://github.com/zpl-c/zpl/blob/27c80bd5807da5238777bfcba8588731b77683cc/code/source/hashing.c#L136 https://github.com/zpl-c/zpl/blob/27c80bd5807da5238777bfcba8...
  - up2isomorphism 6y ago
    These extra wrappers are most likely when library writer trying to cover windows platform, which has almost never been a good place for ANSI C programming.
  - keldaris 6y ago
    > There's surely no excuse for this The "excuse" is greppability since static has three completely different meanings in C and the desire to clearly denote global variables is fairly common. The same reasoning goes for the cast define as well. Whether you find value in these small abuses of the preprocessor depends on your coding habits, but I don't really see much reason to criticize them. If the author finds them helpful, what's the harm? There isn't much room for confusion and they're not forced on the users of the library.
JediPig 6y ago
is there any other similar libraries i should know about? frankly the developer is right, I hate re-implementation of lists and other crap in modern languages. I have a complete crap kernel include file i use when I write kernel modules. ( Though You will find me no longer publishing source code. Client is moving to freebsd, after a linux kernel bug that got labeled "WONT FIX" by linus & crew ) So client goes "WONT SUPPORT" on 5.x linux. Linux userland is a damn mess.
deleted 6y ago
[deleted]
mhd 6y ago
Is "Powerkit" some common term I'm missing here? At first I thought this was related to some kind of Apple "Kit", written in straight C instead of Objective-C/Swift.
- up2isomorphism 6y ago
  I think that it is called "Powerkit" in a sense that it gives C programmers some tools that make daily programming task easier.
- pjmlp 6y ago
  Actually the C++ Framework for Mac OS made by Metrowerks was called PowerPlant.
Deukhoofd 6y ago
So unrelated to the Zebra Programming Language?
jart 6y ago
It looks like ZPL has its own memcpy() implementation which is a work in progress. https://github.com/zpl-c/zpl/blob/dfcb9538967f381363eaef10f9f9c5875cd3b888/code/source/essentials/memory.c#L73 https://github.com/zpl-c/zpl/blob/dfcb9538967f381363eaef10f9... That leads me to believe feedback is desired so assuming the author posted this as a Show HN kind of thread, here's some of what I've learned implementing that function. It goes pretty quick on the machines I've used so far to have an indirect branch with overlapping moves. Here's what that looks like in "pure c" for gcc and clang. https://github.com/jart/cosmopolitan/blob/master/libc/str/memmove-pure.c https://github.com/jart/cosmopolitan/blob/master/libc/str/me... memcpy is hard to implement in pure c99 because aliasing pointers to non-char types can trigger ubsan errors. With rep movsb it's a good idea to check cpuid for erms support. In that case it'll be fastest for bigger moves but is still slower for small moves. See the chart at https://justine.lol/cosmopolitan/index.html https://justine.lol/cosmopolitan/index.html which compares various methods. Also take into consideration that if you call zpl_memcpy() the compiler doesn't know that's memcpy() so it can't perform some of its inlining magic at the call site. So if you want things like null propagation it might be better to do that as a macro. Regarding array.c I implemented a bunch of similar routines myself and eventually chose to not worry about capacity and just call realloc every time. I'm not sure if the standard specifies this, but I'm pretty sure every realloc implementation in practice, under the hood, should track the capacity and grow it at two power sizes. So even if you're just constantly appending by one char the cost should amortize itself out to be cheap in the long run.
- zX41ZdbW 6y ago
  Testing performance of memcpy should be more exhaustive than just running on single CPU: https://github.com/ClickHouse/ClickHouse/issues/18583#issuecomment-793248521 https://github.com/ClickHouse/ClickHouse/issues/18583#issuec...
  - jart 6y ago
    I don't feel like you evaluated my work fairly because you used a modified version of Cosmopolitan memcpy() that had the CPUID checks removed, and then you judged it negatively for not having the CPUID checks.
TazeTSchnitzel 6y ago
I feel like every sufficiently large C project ends up reimplementing the same things: binary-safe (or at least explicit-length) strings, dynamically-sized arrays, hashmaps, a set of typedefs for integers and booleans (if the project predates wide C99 support), a macro to count the number of elements in an array, bit manipulation functions, locale-independent string functions… It's a sad story about the state of the C standard library. When I see nice C libraries, it does make me want to write new C code. But then I am reminded of the many non-library problems with C, like the `uint64_t m = 1 << n;` footgun, the ubiquity of pointer parameters yet lack of syntax to show data flow direction, the inability to specify the width of an enum value… Despite everything, I do like C, especially compared to C++, but there's so many little things that could be improved and yet have been stagnant for decades. And that's without taking about the massive safety issues.
- RJIb8RBYxzAMX9u 6y ago
  To play devil's advocate: it's because one size does not fit all. C gives you the flexibility to tailor your implementation for your specific needs. Whereas in a higher level language, you'd have to fight the language / standard library if your requirements don't match the "few" true ways to do things. That said, too many projects believe they have special needs, when they're better served just using e.g. apr in the first place.
  - TazeTSchnitzel 6y ago
    This argument does not make sense to me at all. C has a standard library, so why can't it be a good one? There's also many things about the language that could be improved without sacrificing any of its low-level qualities.
    - RJIb8RBYxzAMX9u 6y ago
      There are many reasons IMHO: - C is designed by committee, so proposals to expand the standard library move slowly. - Specifications suitable for general computing may not be so for embedded micro-controllers. TBF this is slowly changing as well, given that a ARM CortexM can have double-digit kilobytes of memory now, and is almost as fast as a PII. - Philosophical: some C users maintain that C's supposed to be a "portable assembler" and higher level abstractions are beyond the scope[0]. This may sound tongue-in-cheek but: you should use C++ instead. Yes it has a lot of flaws of its own, but IMHO it really lives up to the spirit of being a "better C". It has (almost?) everything you said wanted in it standard library. And just because you're using C++ doesn't mean you have to go all-in with template meta-programming, objects, etc. I've written very C-ish code in C++, and only used parts of the C++ standard library I absolutely needed. Last time I did that I was able to "un-C++" my code later to satisfy upstream requirement (no capes!^W C++) relatively easily, after iterating with C++ first. [0] I know there are counterarguments that C's never been that and it's more a "convenient lie." Nonetheless the that's the spirit of the argument.

deleted 6y ago

[deleted]

wg0 6y ago

This is beautiful. I think I am going to toy around with it in a project I have been dreaming about.

deleted 6y ago

[deleted]

MaxBarraclough 6y ago

> Most parts of the library are written in pure C99. There are however, some additional components that require C11 to work (notably in the Threading module). As long as you are using minimal version (ZPL_NANO), and manually enable modules, the C99 support should be just fine. I think it would be better to describe it as a C11 library. I didn't know what to make of 'almost C99', which might refer to limited use of compiler-specific features, for instance.

kevin_thibedeau 6y ago
There are compilers that don't support C11. Knowing that downgrading to C99 is a simple procedure is worthwhile.
- MaxBarraclough 6y ago
  Sure, but that wasn't my point. almost C99 is unclear, unless you already know the intent. It's telling me which language the framework isn't written in. 90% C99, 10% C11 would be fine.

szanni 6y ago

This looks like a nice and concise library. Single header file, many useful functions, and a usable license. The only thing I really dislike are all of the typedefs. zpl_u64 zpl_crc64(void const *data, zpl_isize len); Const correctness, good! But why is the size parameter signed? Why not use size_t and uint64_t like the C stdlib?

messe 6y ago
The zpl_u64 seems to be because they're trying to support older versions of the MSVC compiler[1]. As for why they're using a signed size parameter, I'm not really sure. One idiom they appear to use often is[2]: for (...; x--; y++) where x is a size-type of some kind. They may be defaulting to signed size types to avoid errors in case somebody decides to change to above to: for (...; x-- >= 0; y++) There's even a macro zpl_size_of: #define zpl_size_of(x) (zpl_isize)(sizeof(x)) But the real weirdness is in the other macros: #define cast(Type) (Type) ...just why? And #define ZPL_MULTILINE(...) #__VA_ARGS__ is supposed to be a way of having multiline literals in C. But, everything inside the "..." has to be valid C tokens. It might work as a string literal in many cases, but it's misleading at best and broken at worst. I'm not sure what the advantage of the following is vs. just setting the bits using & and | which every C programmer should already be familiar with: #define ZPL_MASK_SET(var, set, mask) \ do { \ if (set) \ (var) |= (mask); \ else \ (var) &= ~(mask); \ } while (0) There's surely no excuse for this: #define zpl_global static // Global variables While a lot of the library looks useful, stuff like the above makes it feel like it's written by somebody who knows C, but doesn't feel fully comfortable writing it. [1]: https://github.com/zpl-c/zpl/blob/master/code/header/essentials/types.h#L11-L40 https://github.com/zpl-c/zpl/blob/master/code/header/essenti... [2]: https://github.com/zpl-c/zpl/blob/27c80bd5807da5238777bfcba8588731b77683cc/code/source/hashing.c#L136 https://github.com/zpl-c/zpl/blob/27c80bd5807da5238777bfcba8...
- up2isomorphism 6y ago
  These extra wrappers are most likely when library writer trying to cover windows platform, which has almost never been a good place for ANSI C programming.
- keldaris 6y ago
  > There's surely no excuse for this The "excuse" is greppability since static has three completely different meanings in C and the desire to clearly denote global variables is fairly common. The same reasoning goes for the cast define as well. Whether you find value in these small abuses of the preprocessor depends on your coding habits, but I don't really see much reason to criticize them. If the author finds them helpful, what's the harm? There isn't much room for confusion and they're not forced on the users of the library.

JediPig 6y ago

is there any other similar libraries i should know about? frankly the developer is right, I hate re-implementation of lists and other crap in modern languages. I have a complete crap kernel include file i use when I write kernel modules. ( Though You will find me no longer publishing source code. Client is moving to freebsd, after a linux kernel bug that got labeled "WONT FIX" by linus & crew ) So client goes "WONT SUPPORT" on 5.x linux. Linux userland is a damn mess.

deleted 6y ago

[deleted]

mhd 6y ago

Is "Powerkit" some common term I'm missing here? At first I thought this was related to some kind of Apple "Kit", written in straight C instead of Objective-C/Swift.

up2isomorphism 6y ago
I think that it is called "Powerkit" in a sense that it gives C programmers some tools that make daily programming task easier.
pjmlp 6y ago
Actually the C++ Framework for Mac OS made by Metrowerks was called PowerPlant.

Deukhoofd 6y ago

So unrelated to the Zebra Programming Language?

jart 6y ago

It looks like ZPL has its own memcpy() implementation which is a work in progress. https://github.com/zpl-c/zpl/blob/dfcb9538967f381363eaef10f9f9c5875cd3b888/code/source/essentials/memory.c#L73 https://github.com/zpl-c/zpl/blob/dfcb9538967f381363eaef10f9... That leads me to believe feedback is desired so assuming the author posted this as a Show HN kind of thread, here's some of what I've learned implementing that function. It goes pretty quick on the machines I've used so far to have an indirect branch with overlapping moves. Here's what that looks like in "pure c" for gcc and clang. https://github.com/jart/cosmopolitan/blob/master/libc/str/memmove-pure.c https://github.com/jart/cosmopolitan/blob/master/libc/str/me... memcpy is hard to implement in pure c99 because aliasing pointers to non-char types can trigger ubsan errors. With rep movsb it's a good idea to check cpuid for erms support. In that case it'll be fastest for bigger moves but is still slower for small moves. See the chart at https://justine.lol/cosmopolitan/index.html https://justine.lol/cosmopolitan/index.html which compares various methods. Also take into consideration that if you call zpl_memcpy() the compiler doesn't know that's memcpy() so it can't perform some of its inlining magic at the call site. So if you want things like null propagation it might be better to do that as a macro. Regarding array.c I implemented a bunch of similar routines myself and eventually chose to not worry about capacity and just call realloc every time. I'm not sure if the standard specifies this, but I'm pretty sure every realloc implementation in practice, under the hood, should track the capacity and grow it at two power sizes. So even if you're just constantly appending by one char the cost should amortize itself out to be cheap in the long run.

zX41ZdbW 6y ago
Testing performance of memcpy should be more exhaustive than just running on single CPU: https://github.com/ClickHouse/ClickHouse/issues/18583#issuecomment-793248521 https://github.com/ClickHouse/ClickHouse/issues/18583#issuec...
- jart 6y ago
  I don't feel like you evaluated my work fairly because you used a modified version of Cosmopolitan memcpy() that had the CPUID checks removed, and then you judged it negatively for not having the CPUID checks.

TazeTSchnitzel 6y ago

I feel like every sufficiently large C project ends up reimplementing the same things: binary-safe (or at least explicit-length) strings, dynamically-sized arrays, hashmaps, a set of typedefs for integers and booleans (if the project predates wide C99 support), a macro to count the number of elements in an array, bit manipulation functions, locale-independent string functions… It's a sad story about the state of the C standard library. When I see nice C libraries, it does make me want to write new C code. But then I am reminded of the many non-library problems with C, like the `uint64_t m = 1 << n;` footgun, the ubiquity of pointer parameters yet lack of syntax to show data flow direction, the inability to specify the width of an enum value… Despite everything, I do like C, especially compared to C++, but there's so many little things that could be improved and yet have been stagnant for decades. And that's without taking about the massive safety issues.

RJIb8RBYxzAMX9u 6y ago
To play devil's advocate: it's because one size does not fit all. C gives you the flexibility to tailor your implementation for your specific needs. Whereas in a higher level language, you'd have to fight the language / standard library if your requirements don't match the "few" true ways to do things. That said, too many projects believe they have special needs, when they're better served just using e.g. apr in the first place.
- TazeTSchnitzel 6y ago
  This argument does not make sense to me at all. C has a standard library, so why can't it be a good one? There's also many things about the language that could be improved without sacrificing any of its low-level qualities.
  - RJIb8RBYxzAMX9u 6y ago
    There are many reasons IMHO: - C is designed by committee, so proposals to expand the standard library move slowly. - Specifications suitable for general computing may not be so for embedded micro-controllers. TBF this is slowly changing as well, given that a ARM CortexM can have double-digit kilobytes of memory now, and is almost as fast as a PII. - Philosophical: some C users maintain that C's supposed to be a "portable assembler" and higher level abstractions are beyond the scope[0]. This may sound tongue-in-cheek but: you should use C++ instead. Yes it has a lot of flaws of its own, but IMHO it really lives up to the spirit of being a "better C". It has (almost?) everything you said wanted in it standard library. And just because you're using C++ doesn't mean you have to go all-in with template meta-programming, objects, etc. I've written very C-ish code in C++, and only used parts of the C++ standard library I absolutely needed. Last time I did that I was able to "un-C++" my code later to satisfy upstream requirement (no capes!^W C++) relatively easily, after iterating with C++ first. [0] I know there are counterarguments that C's never been that and it's more a "convenient lie." Nonetheless the that's the spirit of the argument.