> Insisting on using implementation based APIs just because the rest of the world is using it is the equivalent of shooting oneself in the foot
If you're that anal about things, why are you still using an off the shelf micro processor?
Design your own silicon - c'mon man, you're just not trying hard enough.
You have an interesting journey, but only to you.
Nobody else is going to follow you.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
I'm not smart enough for that, besides the point of C is to compile down to asm that can be wildy different to target processor, the problem with the C standards is that too many lessons were learned too late, I plan to resolve that with a new library that builds upon those lessons, paw will be designed around the minimal headers concept that standard C headers attempted to follow, my sprintfv will be partially future proofed by relying on a list of accepted format suffixes, I can't think of anything to future proof prefixes but a dynamic list of accept suffixes and their callbacks would indeed help with future proofing, being a custom sprinfv I can even add in a parameter for a target BUFFER object instead of target string, this would make it far easier to get a hold of the memory needed by the functions without sacrificing custom memory allocators (which are needed for safe multi-threaded allocations). By designing a new library there is only one implementation to worry about the details of, instead of the many implementations by many compilers, I'm not saying C itself is a problem but the many implementations of it's "standard" APIs. 1 implementation = 1 standard, many implementations = many standards, that's what I'm getting at with the shooting onself in the footOriginally Posted by Salem
Last edited by awsdert; 08-13-2021 at 04:06 AM. Reason: typo
Is this a bug?
Specifically, you are checking prv, but passing arg in the second call.Code:err = ArgHasIssue( prv, NULL ); if ( err ) return ArgHadIssue( err, arg );
927: Standards - explain xkcd
"...a computer is a stupid machine with the ability to do incredibly smart things, while computer programmers are smart people with the ability to do incredibly stupid things. They are,in short, a perfect match.." Bill Bryson
No that wasn't a bug, that was only there because the option doesn't get processed until it's value is brought into sight, prv just held the option, anyways I've already changed to a better method that would allow for options like what gcc uses, -o dst src0 etc
Took a glance, I see your point but that doesn't change my point, because the implementation of current standards are left to vendors there's too much to program around, I hate that which is why I prefer to develop a new standard that can run along side the vendor implementation or just outright render it obsolete, if there's only one implementation that has a clear prefix to avoid collisions then one can still refer to the original documentation and prefix everything so as to avoid programming around multiple implementations and instead only worry about one, weather that implementation makes use of the vendor implementation or maps to it or just ignores it, it is irrelevant to the reliant code, the point is to take out the problem of inconsistent APIs by providing a prefixed version that is guaranteed to do what it should do according to the docs of the original APIs, in other words, not a new standard API but rather a standard implementation of an existing standard API with only minor differences if any, and these differences will only exist for thread safety
