201–210 of 222 posts
Earlier quoted context omitted.
That's fine. Just don't call it "ultra portable" while treating it as a non-goal.
I'm seeing that people have a big issue with the language, but "ultra" doesn't even necessarily mean "total"
Earlier quoted context omitted.
I’m not getting dragged into a strawman argument about meaningless hypothetical percentages of a vague and arbitrary illustration. And particularly not when the point being made was pretty clear: > “Portable”, in the context of how it was used, generally refers to software using platform agnostic idioms.
Portable has two meanings: a construct is portable if we can rely on it to work everywhere. A portable codebase is one that supports moving to a new platform, with some nonzero effort which is not large compared to rewriting the code. It is able to be ported. E.g, "Johnson's Portable C Compiler (PCC)". If only the Foo kernel must be rewritten in order to port Foo, but that kernel is 75% of Foo, then I would say Foo i…
“in the context of how it was used,”
This isn’t some meta conversation about how to write portable software. This is a conversation specific to what the author had written about their project.
i doubt many people will go through the whole code themselves or do this stuff to determine if claims are true and/or its worth to port something to this or start learning it.
people spend a lot of time getting familiar with libraries in order to be able to use them properly.. If you help them a long that path more it will be more inviting to try your code.
(that being said i think people talking about fixing C likely dont realise that people just quietly roll their own libs like this..not to fix C but because that is what C programming is.)
> C is valuable because it’s simple This is funny to me because just today some friends gave me a link to a C quiz: https://stefansf.de/c-quiz/ From which I gathered that it is a much more cursed language than I remembered. Maybe we all just got used to C and just happen to use a minimal subset. The problems with C are not mainly with the standard library, but any effort to improve things should be lauded.
The quiz is not entirely accurate though. For example, pointers to the same address must compare equal. Other stuff is ancient and some of it was already removed in C23. Again other things are entirely irrelevant in practice and kept only for backwards compatibility or for specific technical reasons. In practice, C is very simple, at least compared to the alternatives.
try it with `gcc -O1` and you will get a different result than with `gcc -O0`
Earlier quoted context omitted.
The quiz is not entirely accurate though. For example, pointers to the same address must compare equal. Other stuff is ancient and some of it was already removed in C23. Again other things are entirely irrelevant in practice and kept only for backwards compatibility or for specific technical reasons. In practice, C is very simple, at least compared to the alternatives.
There is an explanation for every one of them, the pointer equality one has code, too. try it with `gcc -O1` and you will get a different result than with `gcc -O0`
Earlier quoted context omitted.
> This shows that "extremely portable" is actually marketing for "It supports a number of platforms. In my opinion, this number is big". The number might just be zero - did anyone check if this compiles? I am trying to track down where the function `sp_mem_allocator_alloc_type` is defined (used in 3x places) but it doesn't appear in the GH search results. I'm not going to clone and build this (too dangerous).
> I am trying to track down where the function `sp_mem_allocator_alloc_type` is defined A quick glance at the source on github and here you go: https://github.com/tspader/sp/blob/e64697aa649907ce3357a7dd0... `sp_mem_allocator_alloc_type ` is going through a couple of macro resolutions which ends up at `sp_mem_allocator_alloc` > I'm not going to clone and build this (too dangerous). Your computer won't explode just fr…
Earlier quoted context omitted.
I have no philosophical complaints with supporting odd architectures in general. I agree that most obscure targets are probably not that much code, since the library is factored with this in mind (e.g. basic WASM support took an afternoon). It's stated as a non-goal simply because it's not the most valuable thing I can do with my time. My fundamental stance is that writing new Windows or Linux or macOS or WASM progra…
That's fine. Just don't call it "ultra portable" while treating it as a non-goal.
Earlier quoted context omitted.
To be portable it's probably best to use the pthreads API for everything, make no additional assumptions, and rely on the user to provide the implementation. Consider what happens when someone is working with OpenMP, CUDA, or similar and attempts to make use of a dependency that in turn makes use of your library. The easier it is to understand the assumptions made by your library the better.
I agree with that. I'm just stating that it's contradictory with the project's own principles. > Program directly against syscalls It's the very first one of the listed principles. In the paragraph after this title it even says it "must" be the case in italic to insist on it, and there's a footnote to define what they mean, which is very clear in that pthreads should be out according to this principle.
I must suspect the author has insufficient understanding of the dynamic linker, TLS memory management, and the vDSO.
Earlier quoted context omitted.
Portability across compilers is orthogonal to portability across target architectures.
This is true, but it would probably be good to be specific what is meant by "portable". There is also the dimension of operating system. It sounds like it has a goal of being "extremely portable" across compilers, (although I'm curious how many compulers it is actually tested against) but only somewhat portable across architectures and operatings systems, just hitting the most popular ones.