
The Public Domain C Library - shakna
http://pdclib.e43.eu/
======
Sir_Cmpwn
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.

~~~
shakna
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.

I couldn't be happier.

~~~
Sir_Cmpwn
That's awesome! You wouldn't believe how much trouble I caused for my teachers
in high school, especially the math teachers :)

~~~
vidarh
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.

~~~
shakna
My high school science teacher took it as I was bored, and gave me open-ended
research questions to occupy me.

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.

~~~
vidarh
Yes, I was similarly lucky for the most part that when I was "causing trouble"
it tended to result in further challenges rather than complaints.

------
ksherlock
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.

------
ausjke
what's the "selling point" here? don't we have quite a few c libraries(glibc,
libc-bsd, musl, uclibc,...) already?

~~~
speeder
I liked the fact it has threads.h :)

Most other c libraries don't have it, the few ones that do (musl for example)
are linux-only usually...

~~~
blackguardx
It has a header file called threads.h, but the implementation is just stubbed
out unless you have pthreads.h available.

Unless I'm missing something...

~~~
shakna
I think pthread is implemented in /opt/pthreads [0], and I think you're right,
looks like a bunch of wrapper APIs.

[0]
[https://bitbucket.org/pdclib/pdclib/src/95be959efe2e/opt/pth...](https://bitbucket.org/pdclib/pdclib/src/95be959efe2e/opt/pthreads/?at=default)

------
ryanmccullagh
This site seems to be broken. Clicking on Source link doesn't work.

~~~
userbinator
Works for me; it takes me to
[https://bitbucket.org/pdclib/pdclib](https://bitbucket.org/pdclib/pdclib)

~~~
amadeusw
Does it work for you further along? I wanted to peek at source or man of
strlen and saw a 404:
[http://pdclib.e43.eu/man/#/man/3/strlen.html](http://pdclib.e43.eu/man/#/man/3/strlen.html)

~~~
shakna
Some of the documentation is incomplete, and is based off the man files
provided in the source's man3 folder.

strlen is missing, but strdup isn't.

[http://pdclib.e43.eu/man/#/man/3/strdup.html](http://pdclib.e43.eu/man/#/man/3/strdup.html)

Edit: And the source for strlen: [0]

[0]
[https://bitbucket.org/pdclib/pdclib/src/95be959efe2ed2f36104...](https://bitbucket.org/pdclib/pdclib/src/95be959efe2ed2f36104ab5cffe9c222972d3e43/functions/string/strlen.c?at=default&fileviewer=file-
view-default)

------
speeder
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).

~~~
shakna
This still doesn't have great support for Windows, if that's what you're
hoping.

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.

~~~
pjmlp
The approach is not odd at all.

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.

~~~
shakna
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.

~~~
pjmlp
> 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.

[https://herbsutter.com/2012/05/03/reader-qa-what-about-vc-
an...](https://herbsutter.com/2012/05/03/reader-qa-what-about-vc-and-c99/)

~~~
throwaway19182
C++ culture at its worst -- listen to the weekly recommendations of Herb,
Scott et al. and you'll be fine. Trust us.

~~~
pjmlp
C++ culture at its best, fixing C memory corruption and UB errors inflicted
into the industry, while providing an upgrade path for saner coding.

~~~
throwaway30101
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.

~~~
pjmlp
C developers don't even care about security, as shown by making the C99
security annex, which was pretty small actually, optional in C11.

Or they just like to wave the amount of CVE exploits that get added daily to
the database, as not being a language issue.

~~~
throwaway10190
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?

~~~
pjmlp
> 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...](http://arstechnica.com/security/2016/09/linux-kernel-security-
needs-fixing/)

------
tonetheman
This stuff is beautiful.

------
kchauhan
Looks like more code here for abs.c

[https://bitbucket.org/pdclib/pdclib/src/95be959efe2ed2f36104...](https://bitbucket.org/pdclib/pdclib/src/95be959efe2ed2f36104ab5cffe9c222972d3e43/functions/stdlib/abs.c?at=default&fileviewer=file-
view-default)

than musl:

[https://git.musl-libc.org/cgit/musl/tree/src/stdlib/abs.c](https://git.musl-
libc.org/cgit/musl/tree/src/stdlib/abs.c)

~~~
anilgulecha
Because it includes testcases.

~~~
therein
You're absolutely 100% correct but to play the devil's advocate, what if he is
talking about it being

glibc:

> return ( j >= 0 ) ? j : -j;

Musl:

> return a>0 ? a : -a;

~~~
reidrac
It really doesn't matter, the compiler will generate the same code (gcc -S at
least does generate the same assembler output for both pieces of code; see:
[https://gist.github.com/reidrac/afb89b29228a243954bd51281c39...](https://gist.github.com/reidrac/afb89b29228a243954bd51281c39ee88)).

I guess looking at the definition:
[https://en.wikipedia.org/wiki/Absolute_value#Real_numbers](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.

~~~
PDoyle
They'd differ for floating-point NaNs.

~~~
vidarh
But the input types here are int's.

