OSDev.org

Solar wrote: Contributions of course wellcome. Come on! There's no sense in every single one of us battling with his/her very own C library. Let's solve this once and for all (and everybody). Don't fear the corps "stealing" a C lib - how much is there to a ISO standard that could possibly be "stolen"?!?

is the libc not quite the most OS dependant (or really, kernel dependant) piece of code? Of course the algorithms can be shared, but how do you suppose numerous people (from numerous kernels) can work on one libc project if the lower level of the libc is kernel dependant? You could have multiple code bases and branches, but that kind of defeats the purpose...

If you have a reasonable method, I'm more than willing to help

Candy wrote: [is the libc not quite the most OS dependant (or really, kernel dependant) piece of code?

Since the SourceForge dudes already approved the project, I made the answer in the "pdclib" SourceForge forum (being a good net-citizen not wanting to clutter this forum with project-specific talk).

Does anyone know of an existing Public Domain implementation of the math.h functions?

I already know Paul Edwards' PDPCLIB; however, its incomplete in regards to math. All other stuff I've found so far is BSD, GPL, or some other non-PD license.

Just making sure I didn't miss anything before starting to roll our own.

Solar wrote: Does anyone know of an existing Public Domain implementation of the math.h functions?

Hmmm, glad you asked. Since I'm working exclusively on the x86 architecture, I'm implementing my functions in assembler. I've been working on the math functions and doing quite a bit of work with the MMX instruction set.

Funny that, assembler in a C library... anyhows, it will be fairly easy for me to rewrite this in C and contribute them to the C library.

Sourceforge problems fixed? I need to learn how to use CVS properly...

You will probably find it even more funny that it's not even possible to implement a C99 library without using C++, undocumented compiler features, or some completely different language - the reason is tgmath.h, which provides "generic" math functions. That's too bad since C doesn't support generic (overloaded) functions.

The CVS repository is available for reading again. All you have to do is:
That is, for this project:
Please send commits as archive to my mail address. I'll do the review and check-in.

And don't throw away that assembler code - once we have the "generic" thing up and running, I'd like to add various hardware "personalities", which would include optimized versions especially (but not only) for maths.

well, i'm going to be writing a c standard library for my os (only for compiling the kernel though). my project is gpl, though, so it's not exactly what you guys want.
basically, i need to rewrite glibc to be non-os-dependent, or rather to rephrase, so that it will work without an underlying os. i'm doing it from scratch, but i only need to do the functions used by my current code since it is only used by the kernel.
essentially, my kernel is a small microkernel-like module, which only does two things:
1) initialize/load modules
2) serve the functions used by Guile
this is because the os, called axis-z, uses the guile scheme interpreter library as an api and a shell, adding flexibility by simplifying the coding/code modification process as well as creating a simple way to add to the api.
but that's enough project-specific info. in any case, as much as i'd love to help/get help, i gpl all my code.
~unknown

Solar wrote: Does anyone know of an existing Public Domain implementation of the math.h functions?

Sun's math library is available http://www.netlib.org/fdlibm/.

* Permission to use, copy, modify, and distribute this
* software is freely granted, provided that this notice
* is preserved.

Sorry but that's not PD... It's close, but no cigar.


@ unknown user:

Well, you could still contribute your code under Public Domain, in addition to GPL'ing it in your own project. Your code is first and foremost your code. Basically, you are releasing a copy of your work under the GPL - you can still give away or sell another copy under a different license.

As soon as someone else contributes to your GPL code base, of course, you have to either get his OK for a parallel PD release, or start a dedicated GPL fork of your code. (The other person committed under terms of the GPL, so you aren't allowed to take *that* to PD.)

Just to point out the options. Since you are aiming at kernel functions only, I guess that doesn't include fancy maths anyway.

The licencing issue is giving me a headache. It's easier for me to make all my own code GPL. Now that I've studied it carefully, I am rather growing on it. I like it. And besides, the wealth of existing GPL'd code influences me a bit... a LOT... may as well make the job as pleasant as possible by using other people's tested and debugged code wherever we can. I just want to get my OS going, and spend as little time as possible on support routines and libraries. I need this badly and want to get it out the way.

That's OK... but then again, if we were after taking the easy road, we'd all be using Windows, Linux, or MacOS, wouldn't we?

Ah well.

other people's tested and debugged code

This is a very big assumption. Code from 3rd parties should always be treated as non-trustworthy, no matter how much you actually do trust the person who wrote it.

Curufir wrote: Code from 3rd parties should always be treated as non-trustworthy, no matter how much you actually do trust the person who wrote it.

I wouldn't say so ... you can use GLIBC almost without worrying too much about bugs, etc. because it has a good documentation (and has been tested etc. of course
That's one of the main issue - imho - when using 3rd party code. Well documented code will leave no doubt on what can work and what couldn't. strcpy crashes the thread when given a NULL source or destination and do not check the destination is large enough ... that's no bug! that's the way it works ...

Pype.Clicker wrote: I wouldn't say so ... you can use GLIBC almost without worrying too much about bugs, etc.
...snip...

Last major security advisory on glibc I recall was a possible local root compromise involving code derived from the Sun RPC implementation. Of course this was way back in April, so I'm sure they've audited every last piece of GLIBC and made it bug-free by now ;D. I stand by my comment, all third party code should be viewed as untrustworthy.

Perhaps you have never had the uplifting experience of spending a week looking for a bug in perfectly good code only to discover it was actually a bug in a library you were using? Much fun, I advise everyone to try it at least once...and only once .

kernel.com.au wrote: The licencing issue is giving me a headache. It's easier for me to make all my own code GPL. Now that I've studied it carefully, I am rather growing on it.

One word yet, if I may:

Be aware that, if you make all your OS code GPL, that means that any applications for your OS must be GPL'ed, too.

Even if you make your CLib LGPL, that still yields the same result.

That's the reason why glibc and stdlibc++ come with special additions to their license making allowances for software to be linked with them without "getting the GPL" so to speak.

Also note that you are not allowed to change the (L)GPL, because the text of the license itself is not free.

While "going GPL" sure gives you a wealth of source bases to tap into, it is

a) not "easier" than anything, license wise (though people just tend to ignore the fine print); and

b) endangers you to "get the UNIX". Most GPL'ed stuff simply assumes a Unix / POSIX environment.

As long as you are aware of these points, by all means go ahead. I am not opposing the GPL per se, I am just opposing the "everything is fine" attitude most people have towards it.