I've found this library to be a great resource for getting implementations of a bunch of simple functions with no strings attached. PDCLib code has made it into most of my toy kernels and the KnightOS libc.
Fantastic work on KnightOS! It has been a constant source of teachers complaining to me at school, because students are hacking away building programs to do all their work for them.
You're not a good student if you never cause trouble for your teachers.
The problem is it takes a good teacher to distinguish between good trouble indicating an engaged student having fun with the material (e.g. a class mate of mine and I went through a phase of handing in homework in non-latin scripts; to our teachers great credit she tolerated Cyrillic, Etruskan and Sanskrit without the slightest complaint) and bad trouble.
That's awesome! Back when I had one of these calculators I wrote tons of TI-BASIC scripts, but never figured the Asm() out (didn't know how to look for the assembler manual or how to use that...). Pretty much the only other thing we had was some app similar to these old Nokia Java games, iirc called Mirage.
This is C, not POSIX. POSIX defers to ISO C but has extensions and more strictly defined behavior/return values.
Example (first function I randomly looked at)
remove() - PDCLib won't remove directories or currently fopened files. ISO C doesn't mention directory support and removing an open file is implementation defined. POSIX says it is equivalent to unlink() or removdir() as appropriate.
At a glance it appears to be a difference without a distinction. What's legally or ethically gained by comparison to existing MIT/BSD licensed c libraries?
Legally, there's less overhead for disseminating copyright notices, and how that should look based on how you're using the software.
Ethically, there's no freer software than public domain.
For myself, it makes it simpler to look into lifting out parts of the library to complement where avr-libc is lacking, which is in a lot of places. I don't have to worry over the fine line, a single line of attribution in the documentation of the final hardware device is more than is asked for.
As to if I used something BSD licensed instead?
If the license is somehow included with the software, well, the end user would never be able to see it, as it would be stored in EEPROM, and take about half the memory.
Strings are a pain in the butt for memory management, and having a pop-up of some sort with the BSD license, would use about a third of available memory.
Should it then be included in the documentation? Possibly, but included a no-warranty clause amongst documents for a warranty-covered device is likely to cause some strife amongst the purchasers of said device.
Including it only in online documentation doesn't seem to fit either the letter or the spirit of the license.
Practically, and legally, where to include the LICENSE is hard to tell.
Of course, this is only public domain in some countries --- as the boilerplate says, public domain just doesn't exist in some places, which is why it's CC0 licensed with a fallback license for when public domain won't work.
Which means that there's a non-zero chance that distributing the code without the CC0 license attached might cause copyright problems in those places. In the FAQ they recommend that you treat the CC0 declaration as a license, with boilerplate at the top of each file and a COPYING file in the distribution:
Including CC0 in accompanying documentation is less likely to frighten users than:
THIS SOFTWARE IS PROVIDED BY <COPYRIGHT HOLDER> ''AS IS'' AND ANY
EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL <COPYRIGHT HOLDER> BE LIABLE FOR ANY
DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
And as the CC0 doesn't stringently demand to be included with the software, I can be sure that including it within the standard literature for clients, or even amongst the spec sheets, is acceptable.
Copyright has made public domain painful, but CC0 is as close as we can get right now, (that I know of).
Lots of Mac apps I used have an "about" window with a trail of near-identical BSD and MIT licenses. It always seems absurd to me.
If someone puts out a code library with no usage restrictions, why require this turgid legal notice to be attached? Public domain dedication seems a much more elegant solution to me.
I really like the Creative Commons approach to licensing rather than the OSI system. The various layers in the CC approach are easy to understand. You mix and match until you have the terms you want to release your work with.
Whereas the OSI model relies on historical artifacts that are difficult to understand and whose meaning is viewed differently even by experts.
I'd like to see more software move to the CC model of licensing and perhaps vainly hope that eventually the OSI will create a model that uses the same kind of layered approach.
Do someone know how easy is to use this in your project without recompiling the OS and whatnot?
I really want some good threads.h implementation, but musl is Linux-only, and the others I found so far are kinda hacky and have some problems here and there. (usually messing up your #defines and #includes in unexpected ways).
The future of Windows systems programming is C++ and C support in Visual C++ is only done to the extent required by ANSI C++ compliance. And ANSI C++ doesn't require C++ compilers to be C compilers, just to compile the common subset and libraries.
For pure C projects there is the new integration of clang with VC++ backend, or any other C compiler capable of targeting Windows.
The clang integration was announced in 2015, so a full 16 years after C99 was finalised.
A C compiler ignoring most of the spec for at least decade seems hugely odd to me.
First and foremost, MSVC is a C compiler, and for a long time was the only one available.
Comparing it's spec support story with GCC, clang, tcc or turboc, and it stands out.
I mean, avr-gcc is designed mostly for use with C++, you're expected to use C++. But it still fully supports C99 and most of C11, with a goal to fix that in the next three years.
It's... Odd.
It may make sense if MS assumes all their developers have no need of the many C APIs they maintain, but it is certainly not the reasoning of many other compilers.
> First and foremost, MSVC is a C compiler, and for a long time was the only one available.
Since when? MSVC doesn't exist, never did, the product has always been called MSVC++.
The only pure C compiler from Microsoft was called *Microsoft C Compiler", and Microsoft was actually the last C compiler vendor adding C++ support for MS-DOS.
> Comparing it's spec support story with GCC, clang, tcc or turboc, and it stands out.
GCC used to stand for GNU C Compiler, before it got renamed into GNU Compiler Collection.
tcc is a C compiler.
Turbo C was a C compiler, the C++ one was called Turbo C++.
clang always supported C, C++ and Objective-C since the beginning, because C's subset of Objective-C is a 100% compatible with C, which isn't the case with C++.
> t may make sense if MS assumes all their developers have no need of the many C APIs they maintain, but it is certainly not the reasoning of many other compilers.
They have assumed this for a long time now, since 2012 actually, people seem to keep not paying attention.
Thanks, now we know why Windows has such a stellar security record.
Really, talking to C++ proponents is like talking to a wall. C programmers can at least admit failures, grumble about their tools and have diverse opinions.
Not so in C++. Religious adherence to dogma, unwaivering allegiance to conference heroes, unbridled enthusiasm for every new feature seems to be a prerequisite for programming in that language.
And God forbid that there's any self-criticism, ever.
This is not my experience at all. I've often observed C programmers that were visibly embarrassed if a single segfault -- let alone an exploit -- was found in their code.
I've observed C++ programmers who were completely indifferent to segfaults, shipped 5 more releases with the bug and continued instead discussing their latest abstractions and how awesome and secure C++ is.
Also, for yet another time: The majority of CVE-worthy programs is written in C (for good reasons), why don't you look at Windows instead?
Because while C++ offers the language features for writing good code, it doesn't prevent that many use it as "C with C++ compiler".
Which is both a path to its successful adoption as better C replaced, but also a curse to language improvements.
So we need languages that share the same spirit as C++ in programmer tooling, but don't allow copy-paste of C code.
Also because Ada compilers were too expensive and most younger generations of developers never heard of it.
Hence Rust, which while a good progress towards safety still needs to match C++'s IDEs, debugging tools and being available on OS vendors SDKs as first level language.
I am looking forward to it, but it still isn't quite there.
C too offers language features for writing good code, but is also cursed by the power it gives the programmer.
It's fantastic flow controls allowed us to move beyond ASM and its convoluted jumps that can become difficult to reason about.
C++ gave us abstraction models that made reasoning about state easier in many ways, but spoils us by allowing us to try and abstract everything, and still possesses unexpected dangers.
Rust gives us abstraction over memory addresses, protecting us from ourselves, but still giving us some power, but sometimes getting in the way of the programmer.
There is a place for all of these.
I like that my RTC uses ASM, I like that my watch uses C, I like that my word processor uses C++, and I like that my web server uses Rust.
No one must be superior to the other. They aren't successors to each other. I think we find ourselves here: [0], and I think you and I may have to agree to disagree, because none of these languages is perfect, and they all impact each other.
I rather that neither C and eventually C++, are no where to be seen on that stack.
Being almost the same age than C, and older than C++, means I know there were better ways of doing systems programming than any of them.
Right now C++ is the lesser of both evil, until Rust, Swift, .NET Native, D, other safe language of the month, eventually takes over most of its use cases.
But that argument doesn't necessarily call for a new language, it only calls for the prohibition of the unsafe elements of the existing language. Intuitively one might assume that potentially unsafe elements (like pointers, references, parts of the standard library, etc.) are so ingrained in C++ that prohibiting them would cripple the language. But actually, C++'s preprocessor is powerful enough that instead of abandoning those potentially unsafe elements, you can instead replace them with safe compatible substitutes. SaferCPlusPlus[1] is a collection of such substitutes.
And since the substitute elements are themselves pure C++, you can still use your existing IDEs, debugging tools and SDKs. And the migration of existing code can be done completely incrementally, and much of it won't need to be changed at all.
It doesn't work in the enterprise context where I am yet to see any code review taking place.
The very few I happened to see weren't real ones, rather some meetings to tick a few check boxes, usually faded away after the managers realize the amount of "wasted money" doing them.
You mean, that if there isn't some kind of (automated) enforcement, programmers will continue to "taint" code with unsafe elements? Yes, but just like one might anticipate the development of a good IDE/tool/libray/SDK ecosystem for Rust, you could imagine the development of a memory safety enforcement/verification tool for either SaferCPlusPlus or C++ in general. The C++ "Core Guidelines Lifetime Checker"[1] is intended to be such a tool for C++ in general. And such a tool for SaferCPlusPlus would be simple enough that, if it didn't want to wait for one, an enterprise could implement one itself. I mean, all it would have to do is identify any instances of potentially unsafe elements in the code. Right?
Or are you suggesting that it would be "politically" unrealistic to impose a prohibition on unsafe C++ code in the enterprise context? So it would be more realistic to adopt a new language, like Rust, that doesn't have the baggage that C++ does?
I mean any form of review be it automated or manual.
Money spent in code review processes and tooling is usually budgeted after unit testing and documentation, those tend to have quite small budgets and political willingness.
Yes to your last question, the good thing about languages that aren't copy-paste compatible with C, is that there isn't any easy way to write code the C way.
