Implementation of functions in math.h on clc-wiki

[Gregory Pietsch]

I'm writing a portable implementation of the C standard library for
http://www.clc-wiki.net and I was wondering if someone could check the
functions in math.h for sanity/portability/whatever. I'm almost halfway
through writing the over 200 functions needed to implement C99's
version of math.h, and I would like to have some feedback and/or expert
advice on my implementations.

Sincerely, Gregory Pietsch

[Ronald Bruck]

In article <44***************@yahoo.com>, CBFalconer
<cb********@yahoo.com> wrote:

niiru wrote:

P.J. Plauger wrote:

On the subject of holding yourself to higher standards, the
evolution of

http://www.dinkumware.com/conform_c.html

... snip ...

Customers might start wondering about the quality of these tests.

Please do not snip attributions for material you quote. Your
message would imply that PJP wrote the portion marked ">>>" above.
He did not, you did. This is either carelessness or sneakiness.

I think we're able to count > signs.

--Ron Bruck

Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------
http://www.usenet.com

[Al Balmer]

On Wed, 15 Mar 2006 23:26:25 -0800, Ronald Bruck <br***@math.usc.edu>
wrote:

In article <44***************@yahoo.com>, CBFalconer
<cb********@yahoo.com> wrote:

niiru wrote:

> P.J. Plauger wrote:
>
>>> On the subject of holding yourself to higher standards, the
>>> evolution of
>>>
>>> http://www.dinkumware.com/conform_c.html
>>>

... snip ...

>
> Customers might start wondering about the quality of these tests.

Please do not snip attributions for material you quote. Your
message would imply that PJP wrote the portion marked ">>>" above.
He did not, you did. This is either carelessness or sneakiness.

I think we're able to count > signs.

How does that restore the missing attribution?

--
Al Balmer
Sun City, AZ

[Ronald Bruck]

In article <po********************************@4ax.com>, Al Balmer
<al******@att.net> wrote:

On Wed, 15 Mar 2006 23:26:25 -0800, Ronald Bruck <br***@math.usc.edu>
wrote:

In article <44***************@yahoo.com>, CBFalconer
<cb********@yahoo.com> wrote:

niiru wrote:
> P.J. Plauger wrote:
>
>>> On the subject of holding yourself to higher standards, the
>>> evolution of
>>>
>>> http://www.dinkumware.com/conform_c.html
>>>
... snip ...
>
> Customers might start wondering about the quality of these tests.

Please do not snip attributions for material you quote. Your
message would imply that PJP wrote the portion marked ">>>" above.
He did not, you did. This is either carelessness or sneakiness.

I think we're able to count > signs.

How does that restore the missing attribution?

It doesn't. When you're concentrating on, in this case, Plauger's
remark, you only need to restore sufficient context to understand his
remark. Who cares who made the intermediate comment?

This isn't academia, where everything is referenced, re-referenced, and
footnoted. Thank God.

--Ron Bruck

Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------
http://www.usenet.com

[CBFalconer]

Ronald Bruck wrote:

<al******@att.net> wrote:

Ronald Bruck <br***@math.usc.edu> wrote:

<cb********@yahoo.com> wrote:
niiru wrote:
> P.J. Plauger wrote:
>
>>> On the subject of holding yourself to higher standards, the
>>> evolution of
>>>
>>> http://www.dinkumware.com/conform_c.html
>>>
... snip ...
>
> Customers might start wondering about the quality of these tests.

Please do not snip attributions for material you quote. Your
message would imply that PJP wrote the portion marked ">>>" above.
He did not, you did. This is either carelessness or sneakiness.

I think we're able to count > signs.

How does that restore the missing attribution?

It doesn't. When you're concentrating on, in this case, Plauger's
remark, you only need to restore sufficient context to understand
his remark. Who cares who made the intermediate comment?

If you look, there is nothing in that message that PJP wrote, yet
there is a missing attribute for what niiru wrote. That was the
point. You can't restore missing context lacking the referenced
article.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

[Al Balmer]

On Thu, 16 Mar 2006 11:34:29 -0800, Ronald Bruck <br***@math.usc.edu>
wrote:

In article <po********************************@4ax.com>, Al Balmer
<al******@att.net> wrote:

On Wed, 15 Mar 2006 23:26:25 -0800, Ronald Bruck <br***@math.usc.edu>
wrote:

>In article <44***************@yahoo.com>, CBFalconer
><cb********@yahoo.com> wrote:
>
>> niiru wrote:
>> > P.J. Plauger wrote:
>> >
>> >>> On the subject of holding yourself to higher standards, the
>> >>> evolution of
>> >>>
>> >>> http://www.dinkumware.com/conform_c.html
>> >>>
>> ... snip ...
>> >
>> > Customers might start wondering about the quality of these tests.
>>
>> Please do not snip attributions for material you quote. Your
>> message would imply that PJP wrote the portion marked ">>>" above.
>> He did not, you did. This is either carelessness or sneakiness.
>
>I think we're able to count > signs.
> How does that restore the missing attribution?

It doesn't. When you're concentrating on, in this case, Plauger's
remark, you only need to restore sufficient context to understand his
remark. Who cares who made the intermediate comment?

Obviously, Chuck and I do. So should you, considering that the above
was *not* Plauger's remark. That was the point of the objection.
This isn't academia, where everything is referenced, re-referenced, and
footnoted. Thank God.

--
Al Balmer
Sun City, AZ

[Netocrat]

On Sun, 12 Mar 2006 08:07:28 +0000, Richard Heathfield wrote:

Netocrat said:

I've deleted all code-containing pages from the "Portable C library
source code implementation" category and its sub-categories on
clc-wiki.net.

As an update for anyone following this: none of the pages have been
restored yet, but I believe it would be possible for quite a few of them
to be restored without raising objections. Everyone concerned seems to
accept the good-faith future intentions of other parties.
Good move. Perhaps it would be a good idea to start again, and ban
anyone from participating if they have access to a copy of TSCL. (In a
curious omission, I never actually got around to buying a copy myself,
so I'd be game for that.)
I'd prefer that too, but I don't think that it's necessary - it blocks a
lot of people from contributing. So long as people disclose all
references that they've used, and any possible unconscious reproduction
along with steps they've taken to avoid it, I think that ethical and legal
principles are upheld.

I've drafted some policies partly in response to this thread:
<http://clc-wiki.net/wiki/Clc:Policies#Licencing_and_Copyright>. Comments
welcome.
This morning, I took the opportunity to drop in on the C wiki, and I
have to say it does look like it's becoming a useful site, current
debacle notwithstanding. I am delighted, and encouraged. I may start
dropping by a little more often.

Thanks for the support. I hope you keep on stopping by.

--
http://members.dodo.com.au/~netocrat

[Netocrat]

[some snippage restored]
On Tue, 14 Mar 2006 01:31:53 +0200, Juuso Hukkanen wrote:

On 12 Mar 2006 05:44:28 GMT, Jordan Abel <ra*******@gmail.com> wrote:

On 2006-03-11, Gregory Pietsch <GK**@flash.net> wrote:

I'm writing a portable implementation of the C standard library for

I would like to help with this, I have ideas on implementing stdio, and

Great, fresh ideas are welcome.
I also think that these files should be moved into a "pseudo-namespace"
[see http://clc-wiki.net/wiki/Clc_libc/stdio]

I've described a different approach here:
<http://clc-wiki.net/wiki/Talk:Clc_libc>. This includes a few reference
pages.
Perhaps MinGW's C library package could be used as material, after all
it is distributed as a public domain.
The policies and conventions that I've just added to the wiki for
discussion discourage this approach without outright prohibiting it,
preferring that contributed code be completely original.

[...] btw, I use the opportunity to thank you all who have been patiently &
unselfisly posting codes to public domain. The CLC-wiki - project will
certainly be a very important resource for many - Keep up with good
work!

That's also my hope for it. Cheers for the support.

--
http://members.dodo.com.au/~netocrat

[Netocrat]

On Sun, 12 Mar 2006 09:45:04 +0000, Jordan Abel wrote:

On 2006-03-12, we******@gmail.com <we******@gmail.com> wrote:

Jordan Abel wrote:

On 2006-03-11, CBFalconer <cb********@yahoo.com> wrote:
> Gregory Pietsch wrote:
>> I'm writing a portable implementation of the C standard library for
>> http://www.clc-wiki.net and I was wondering if someone could check
>> the functions in math.h for sanity/portability/whatever. I'm almost
>> halfway through writing the over 200 functions needed to implement
>> C99's version of math.h, and I would like to have some feedback
>> and/or expert advice on my implementations.
>
> Caution. Many of the standard library routines are intrinsically
> not implementable with portable code. I suggest an enumeration of
> these would be worthwhile, together with the sort of assumptions
> needed for an implementation. We can start with malloc, realloc,
> and free, which require assumptions about alignment and pointer
> convertability.

A _lot_ can be done with only a very tiny section of non-portable
code, though. malloc/realloc/free need only two things - a way to get
a [moderately large] block of memory from the OS, and a way to figure
out pointer alignments. (Once a pointer _is_ aligned 'for any data
type', it can be converted to a pointer to any data type)
On many (and certainly most modern) platforms, a heap implementation
that is not thread safe (via true critical sections) is kind of
useless.
The question is what the wiki's focus should be. I think that it should
be on purely portable C code as c.l.c has made that its focus. So the
wiki C implementations needn't cope with threading at all, but that
limitation should be documented if it turns out to be the case.
Locking can be abstracted with macros, to some extent.

If it doesn't add unnecessary complexity, sure, we can use that approach.

much of stdio can be implemented on a bare-bones subset of the UNIX
api: open, close, read, write; limit open flags to only O_{RDONLY RDWR
WRONLY CREAT TRUNC APPEND}; the other three functions are already
dead-simple.

Hmm ... how about things like clock, time, remove, getenv? And if you
are including headers, what's the plan for implementing offsetof,
va_start, va_arg, etc portably?

No idea.

The approach that I suggest is to quarantine non-portable code into
identifiers prefixed with _np, and to list all those identifiers on a
single page. If an _np identifier encompasses an entire library function,
so be it, but the aim would be to minimise their scope. From there,
whether it's useful to implement a non-portable solution for that
identifier on the wiki depends on how much insight into C that
implementation would provide.

--
http://members.dodo.com.au/~netocrat

[Jordan Abel]

On 2006-03-20, Netocrat <ne******@dodo.com.au> wrote:

On Sun, 12 Mar 2006 08:07:28 +0000, Richard Heathfield wrote:

Netocrat said:

I've deleted all code-containing pages from the "Portable C library
source code implementation" category and its sub-categories on
clc-wiki.net.

As an update for anyone following this: none of the pages have been
restored yet, but I believe it would be possible for quite a few of them
to be restored without raising objections. Everyone concerned seems to
accept the good-faith future intentions of other parties.

Good move. Perhaps it would be a good idea to start again, and ban
anyone from participating if they have access to a copy of TSCL. (In a
curious omission, I never actually got around to buying a copy myself,
so I'd be game for that.)

I'd prefer that too, but I don't think that it's necessary - it blocks a
lot of people from contributing. So long as people disclose all
references that they've used, and any possible unconscious reproduction
along with steps they've taken to avoid it, I think that ethical and legal
principles are upheld.

Some issues - I don't like the GFDL [there are certain problems like its
poorly worded DRM restrictions that have been the subject of some
controversy recently] and I think you should seriously consider this
instead of just using the GFDL because wikipedia does it [Sorry if this
isn't the reason, but it's what the combination of GFDL and mediawiki
brings to mind

Second, there's no particular reason that code segments in an article
can't have their own license. [say, the GPL - which the GFDL is
incompatible with.]
I've drafted some policies partly in response to this thread:
<http://clc-wiki.net/wiki/Clc:Policies#Licencing_and_Copyright>. Comments
welcome.

This morning, I took the opportunity to drop in on the C wiki, and I
have to say it does look like it's becoming a useful site, current
debacle notwithstanding. I am delighted, and encouraged. I may start
dropping by a little more often.

Thanks for the support. I hope you keep on stopping by.

[Jordan Abel]

On 2006-03-20, Netocrat <ne******@dodo.com.au> wrote:

[some snippage restored]
On Tue, 14 Mar 2006 01:31:53 +0200, Juuso Hukkanen wrote:

On 12 Mar 2006 05:44:28 GMT, Jordan Abel <ra*******@gmail.com> wrote:

On 2006-03-11, Gregory Pietsch <GK**@flash.net> wrote:
I'm writing a portable implementation of the C standard library for

I would like to help with this, I have ideas on implementing stdio, and
Great, fresh ideas are welcome.
I also think that these files should be moved into a "pseudo-namespace"
[see http://clc-wiki.net/wiki/Clc_libc/stdio]
I've described a different approach here:
<http://clc-wiki.net/wiki/Talk:Clc_libc>. This includes a few reference
pages.

Perhaps MinGW's C library package could be used as material, after all
it is distributed as a public domain.

The policies and conventions that I've just added to the wiki for
discussion discourage this approach without outright prohibiting it,
preferring that contributed code be completely original.

There's still the issue of code that someone has read in the past
"contaminating" their code with similarities.

There's also libclc to consider, which it might make sense to post in
its entirety or even to some extent 're-home' it or its documentation on
the wiki (are any of the authors still around here? Bjorn Augestad, Dan
Pop, Eric G. Miller, Hallvard B. Furuseth, Jan Engelhardt, Randy Howard,
Bertrand Mollinier Toublet, Howard Chu, Walter Faxon, are all credited,
and I have no idea who the maintainer is) - it's under a BSD-ish
license, but... does the GFDL allow warranty disclaimers? It's not
particularly suited to code, so it might not mention the issue [and if
it has a "no more restrictions" clause that could be a problem]
btw, I use the opportunity to thank you all who have been patiently &
unselfisly posting codes to public domain. The CLC-wiki - project will
certainly be a very important resource for many - Keep up with good
work!

That's also my hope for it. Cheers for the support.

[Jordan Abel]

On 2006-03-20, Netocrat <ne******@dodo.com.au> wrote:

[some snippage restored]
On Tue, 14 Mar 2006 01:31:53 +0200, Juuso Hukkanen wrote:

On 12 Mar 2006 05:44:28 GMT, Jordan Abel <ra*******@gmail.com> wrote:

On 2006-03-11, Gregory Pietsch <GK**@flash.net> wrote:
I'm writing a portable implementation of the C standard library for

I would like to help with this, I have ideas on implementing stdio, and
Great, fresh ideas are welcome.
I also think that these files should be moved into a "pseudo-namespace"
[see http://clc-wiki.net/wiki/Clc_libc/stdio]

I've described a different approach here:
<http://clc-wiki.net/wiki/Talk:Clc_libc>. This includes a few reference
pages.

I think namespaces are still a worthwhile approach, especially if we
ever decide to post code that isn't part of a libc implementation [I
mentioned libclc in my other reply]

A hierarchial namespace is discouraged on wikipedia for a reason, but i
tihnk that reason maybe doesn't fit well here.

How about we [i guess by 'we' i mean 'you'] set it up like the
following?

Standard_Library/string.h [place to put explanations of constants and macros,
and the header file code itself]
Standard_Library/string.h/strcpy

[the current strcpy article moved to Standard_Library/string.h/strcpy
and so on]