The Public Domain C Library
pdclib.e43.eu
pdclib.e43.eu
I couldn't be happier.
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.
e.g. Why is the sky blue during the day, and red at sunset?
Though that's much easier to answer today, it taught me some great skills, and how to not be afraid of failure or rejection.
I ended up having some great conversations with the professors at my local universities.
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.
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.
It sparked my interest.
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.
But I don't have to hire a lawyer with this.
I can just use it.
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.
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:
https://wiki.creativecommons.org/wiki/CC0_FAQ
Should this be done for binaries as well as source? Beats me.
Also note that the OSI haven't certified it, citing concerns with the patent clause:
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).
Copyright notice requirement means you can't just copy-paste a single function.
Most other c libraries don't have it, the few ones that do (musl for example) are linux-only usually...
Unless I'm missing something...
[0] https://bitbucket.org/pdclib/pdclib/src/95be959efe2e/opt/pth...
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.
strlen is missing, but strdup isn't.
http://pdclib.e43.eu/man/#/man/3/strdup.html
Edit: And the source for strlen: [0]
[0] https://bitbucket.org/pdclib/pdclib/src/95be959efe2ed2f36104...
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).
Mostly to do with MSVC's odd approach to C99, that having it is nice, but not a goal, so not all supplied functions strictly conform to the standard.
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.
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.
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.
https://herbsutter.com/2012/05/03/reader-qa-what-about-vc-an...
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.
Or they just like to wave the amount of CVE exploits that get added daily to the database, as not being a language issue.
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 GNU/Linux is even worse nowadays, in spite of joking how Windows used to be, somehow they forgot to follow suit in terms of security.
"Unsafe at any clock speed: Linux kernel security needs a rethink"
http://arstechnica.com/security/2016/09/linux-kernel-securit...
Both C and C++ face the problem that memory management is hard. In different places because they use different approaches to the same problems.
Sometimes C is appropriate, sometimes C++, and sometimes Rust.
There is no reason these languages can't coexist peacefully, and no reason we can't all learn from each other.
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.
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.
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.
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.
[1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus
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.
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?
[1] https://blogs.msdn.microsoft.com/vcblog/2016/03/31/c-core-gu...
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.
https://bitbucket.org/pdclib/pdclib/src/95be959efe2ed2f36104...
than musl:
glibc:
> return ( j >= 0 ) ? j : -j;
Musl:
> return a>0 ? a : -a;
I guess looking at the definition: https://en.wikipedia.org/wiki/Absolute_value#Real_numbers I would say `( j >= 0 ) ? j : -j` is more accurate, although in practical terms is the same result.