Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
With that out of the way, I'm set to merge some contributions into the repository.
I still have Candy's math.h on hard drive, and I am pretty sure I have all other contribs (including Curufir's work) still in the mailbox on my hard drive. But since I've yet to import this into Linux and know my luck with computers lately... if you really want to make sure, just send me the ZIP's again. :-[
Every good solution is obvious once you've found it.
Officially I would tell you that any decent book about the C programming language should come with some specs on the C standard library.
Inofficially, Google has some links about "ISO/IEC 9899:1999"...
As for implementing the standard, I strongly recomment P.J. Plauger's "The C Standard Library". The book comes at a price, but Plauger details many of the tricky innards of the C lib.
@ Candy:
You said you'd release the malloc module of AtlantisOS into PD... I surfed to atlantisos.com today, but when I followed the menu to the AtlantisOS sources all I got was a PHP error... you might want to fix that.
Every good solution is obvious once you've found it.
You said you'd release the malloc module of AtlantisOS into PD... I surfed to atlantisos.com today, but when I followed the menu to the AtlantisOS sources all I got was a PHP error... you might want to fix that.
Very good point . Will work late tonight to get at least the file section working (switching part of the design). The files are also at www.sf.net/projects/atlantisos - you can take either 0.0.1, 0.0.2 or 0.0.2.1 but I strongly advise the latest as the rest is less complete. AFAIK, didn't change any between 0.0.2 and 0.0.2.1.
You might want to know that the parameter to malloc() and realloc() is size_t (which is part of the standard), not uint_t (which isn't). Also, you might want to have a look at stdint.h - it probably obsoletes your types.h.
Every good solution is obvious once you've found it.
It says I contributed a malloc. Did I? I can't even remember writing a fully blown malloc! I'mn fairly sure this is a mistake. If I did then is it up so I can see it. I'm going brain dead!
Pete
PS If you do have one from me feel free to use it.
Does http://www.pro-pos.org/cgi-bin/viewcvs. ... iew=markup look familiar, or did I forget something? (Not sure, I think I checked in the math.h you provided, but I was without my favourite and familiar tools at that time, so I might have goofed up.)
Every good solution is obvious once you've found it.
Solar wrote:
Does http://www.pro-pos.org/cgi-bin/viewcvs. ... iew=markup look familiar, or did I forget something? (Not sure, I think I checked in the math.h you provided, but I was without my favourite and familiar tools at that time, so I might have goofed up.)
It looks familiar. It's the old one, that's 16k smaller and doesn't contain the macros. So, your credits are wrong again
I haven't reviewed it in detail yet, but one note up front: no, long double is not always 80 bit - afair, 80 bit floating points are a speciality of the Intel architecture. Sorry but whenever numerical limits come into play, the standard gets difficult - there might even be machines around that do not notate floating points to a radix of 2... ::)
Every good solution is obvious once you've found it.
Solar wrote:
I haven't reviewed it in detail yet, but one note up front: no, long double is not always 80 bit - afair, 80 bit floating points are a speciality of the Intel architecture. Sorry but whenever numerical limits come into play, the standard gets difficult - there might even be machines around that do not notate floating points to a radix of 2... ::)
Ok, so then it should go in the x86 personality (or something). At least, the defines. I had somewhere spotted a sparc that did 128-bit, but I didn't know about those things.
Anyway, what /are/ you doing up at this hour? I know you're in the same timezone .