Gregory,
I haven't looked closely at the technical content of the code you've added yet, but I intend to when I've finished some other things. I have a couple of non-technical suggestions in the meantime. Firstly, the separate but related .c files for ctype could be placed on a single page, rather than a separate category - they're small enough that this is suitable and it makes navigation easier. Secondly, you could use the summary line template, and if you find any deficiencies in it, say so - it hasn't been used yet apart from the line I've just added to the bottom of Xctype.c. For one thing this line saves on having to include the original author's name in the actual code comments (you can include it anyway of course), but mostly it provides a structure for later reviews to hang off. You can copy-n-paste it from Help:Editing#Creating_a_Summary_Line_for_a_Code_Block.
--Netocrat 05:11, 3 February 2006 (GMT)
Believe it or not, the ctype implementation is the output of a program I wrote to reverse-engineer an implementation of ctype and generate the appropriate tables. For the is() functions, all I do is check the appropriate bitflag in the ctype table; for the to() functions, it's a table lookup (isascii() and toascii() nonwithstanding). I'm not treating any of this code as sacred, BTW, so if anyone has any suggestions for improvement, go ahead and make them! -- Gregory Pietsch 20:18, 3 February 2006 (GMT)
Oh, I will edit them if no one beats me to it. I've noticed some unneeded casts and one or two other things. I'll probably also nick your descriptions to start seeding the Library reference.
--Flash Gordon 00:27, 4 February 2006 (GMT)
I've just come across code in a pete post (<43E47D3E.5C8F@mindspring.com>) that provides a good alternative to predefining whether a system is two's complement. I briefly noticed that your code relies on _C2 as statically defined in yvals.h; pete's code could be adapted for this macro. I won't make any changes at this point as I haven't looked closely enough at your code or thought carefully about his code, but here's what pete posted:
#include <stdio.h> int main(void) { switch (-1 & 3) { case 1: puts("signed magnitude"); break; case 2: puts("ones's complement"); break; default: puts("two's complement"); break; } return 0; }
--Netocrat 00:05, 5 February 2006 (GMT)
Wow! Once I thought about it, I threw it into <limits.h>. I still need a yvals.h for CHAR_BIT and MB_LEN_MAX, though, because I don't know how I could make those port to the Deathstation 9000. I'm just one guy with a lot of ideas about this, so I appreciate any help I can get! -- Gregory Pietsch 02:44, 5 February 2006 (GMT)
I think that there is some risk due to the possibility of padding bits, but not everything can be done in pure unadulterated standard C. So I think the best thing to do things in as standard a manner as possible and just comment the bits that are not pure standard as you have done in <limits.h> and I added in the memmove implementation.
--Flash Gordon 11:33, 5 February 2006 (GMT)
In that case, I wonder how setjmp.c and longjmp.c will work. -- Gregory Pietsch 19:57, 5 February 2006 (GMT)
setjmp and longjmp won't be portable.
Why did you revert my change to the definition of the NULL macro in stdlib.h? Defining it as
#define NULL ((void*)0)
is portable to all conforming compilers, as would defining it simply as 0.
I thought I saw a ghost. Anyway, NULL is now defined as 0 in <stdlib.h> and <string.h>. I guess that _NULL is now removed from yvals.h. -- Gregory Pietsch 23:43, 7 February 2006 (GMT)
Copyright
Have you copied any of P.J. Plauger's material, either expressly or perhaps inadvertently, as he claims? If so, let's get rid of it asap - that sort of stuff shouldn't even be viewable in the history; Flash can probably assist by wiping it from the database.--Netocrat 22:23, 11 March 2006 (GMT)
