Since 4chan's /prog/ has become little more than meme spamming, I decided I'd try here.
Me and a group of anons are working on a POSIX-compliant OS, which will be developed anonymously and be public domain. Currently we've started on replacing GNU's Coreutils with Anoncoreutils, and have around 1/3 of the utilities finished. This is both an experiment in anonymous software development and an attempt to eliminate the bloat that GNU's programs tend to have.
Anyone is welcome to join in with this, as long as they don't leave a name and don't mind writing code for the public domain.
More info at http://rechan.eu.org/ac/ and http://rechan.eu.org/ax/
>>78
Those are two different people, and I'm guessing neither of them wrote mkdir.
I don't see anything wrong with the fold
though.
>>76
long long is also gcc, IBMcc, HP's cc, and several others. They put it in c99 because of this existing practice.
As an aside, we're thinking of adding a "long long long" to AnonCC which, if the machine supports it, will be at least 128 bits. (Yes, we're making plans for beyond Anoncoreutils already, sinec development is pretty quick right now.)
>>79
it demonstrates that "trusting the programmer" is stupid, not everyone knows what they're doing, and if someone makes a mistake other people aren't smart enough to figure out what it is
anyway i'm looking forward to the june update so i can compile it on my OLPC and see how much shit breaks
maybe i'll dig my mac quadra with A/UX out of the garage too
>>81
Someone else fixed mkdir, not me (nor do I know who did). Whoever did didn't log the change, and I don't feel like bringing up the diff.
>and if someone makes a mistake other people aren't smart enough to figure out what it is
mkdir.c works now, so someone was smart enough to find the bug. I don't care who did it, the important thing was it got fixed.
Are you the guy who posted a pic of /g/ on an OLPC on /g/?
>>74
mkdir had inline
too.
mkfifo assumes mode_t
is signed.dectooct
returns -1 if you give it a number that has the digits 8 or 9 in it. you store the int
result of dectooct
in the mode_t
variable mode
and then check to see if it's equal to -1 to determine whether the mode supplied by the user is valid:
if(mode == -1) {
fprintf(stderr, "%s: invalid mode\n", argv[0]);
return 1;
}
mode
cannot ever be -1 if mode_t
is unsigned (which it is on my system), so it continues on and tries to set the mode to 0177777.
also, mkfifo really needs to be indented.
As an aside, we're thinking of adding a "long long long" to AnonCC which, if the machine supports it, will be at least 128 bits.
>First of all, there is nothing that says long long can't be 128 bits
You missed the part about "at least". Also
long >= 32 bits
long long >= 64 bits
long long long >= 128 bits (the next logical step?)
I know the hardware doesn't have to support 128-bit types for it to be in the language, but this is more of an extension than anything else. AnonCC plans are very vague right now, we might not even add triple-long if it serves no useful purpose.
>>83,84
Yeah, the whole dectooct()
is retarded and we're going to rewrite it. It doesn't even support the POSIX symbolic modes (+w, -r, g=o, etc.) Your hate only makes us more determined to fix it.
> long long long >= 128 bits (the next logical step?)
Just a suggestion... If you have 128-bit integers at all, call them int128_t
and uint128_t
(and intleast128_t
, uintleast128_t
, intfast128_t
, uintfast128_t
, intmax_t
, and uintmax_t
).
If you want to also have a 128-bit long long long
that's fine, but if you don't have the standard names it's fucking useless.
Also, if you're planning on writing a new C compiler that doesn't support C99, don't bother.
>>88
typedef long long long int int128_t
typedef unsigned long long long int uint128_t
etc.
>>90
if we add 3-long, we decide how long it's going to be and 128 seems like a good length. yes long long could be 128 on a wider machine but then 3-long will be even bigger still, like 256. and if long is 256, we'll make long long 512 and long long long 1024. but this is purely theoretical, no ordinary machines we know of are this wide and certainly none of us own one.
i have no idea how much she wrote, but she spends more time discussing the project with us than writing code. she also has IRL to contend with, like the rest of us. a/x is just a side project, not full-time work.
what bug are you talking about? if you're complaning about the versions on REchan right now not having been fixed, shut the fuck up and learn to read because i explained like three fucking times already ***THE UPDATES WILL BE RELEASED IN JUNE***
and the more you say a/x is going to fail, the more incentive you give us to work harder on it.
if we add 3-long, we decide how long it's going to be and 128 seems like a good length. yes long long could be 128 on a wider machine but then 3-long will be even bigger still, like 256. and if long is 256, we'll make long long 512 and long long long 1024. but this is purely theoretical, no ordinary machines we know of are this wide and certainly none of us own one.
what bug are you talking about?
shut the fuck up and learn to read because i explained like three fucking times already ***THE UPDATES WILL BE RELEASED IN JUNE***
and the more you say a/x is going to fail, the more incentive you give us to work harder on it.
Thanks for the input, but you missed this:
>but this is purely theoretical
We're considering a triple long, not desperately thinking of adding one. Enough talk about longs, it's getting rather long.
>Funny, as I said before it would take me less than a day to "update" (ie completely rewrite) all the code you've already written.
And I wrote an ANSI C compiler in ANSI C when I was 12. PROVE IT! Besides, we have other things to do than work on a/x 24/7.
> If it takes you so much to update code which normally would take 1 day for any normal programmer
And again you fail at reading comprehension. We have our own private-but-open (read the posts again, you might just figure out how to access it) repository and FTP server. The code there is the most recent and all the bugs are fixed there. BUT WE ARE NOT UPLOADING IT TO RECHAN UNTIL JUNE.
>Be cause you are retarded, you have a woman in your team which is beyond retardism
lol, resorting to misogyny now?
And I wrote an ANSI C compiler in ANSI C when I was 12. PROVE IT! Besides, we have other things to do than work on a/x 24/7.
This thread sucks. Please stop posting here.
Wow, a project destined for failure before it was even thought of. Enjoy wasting your time, faggots.
http://rechan.eu.org/s/ is broken.
you can't even write a simple php script and you're writing an operating system?
>>98
Didn't notice that. There's nothing wrong with r4:
>[Thu May 22 05:05:40 2008] [error] [client x.x.x.x] PHP Warning: file_put_contents(index.htm) [function.file-put-contents]: failed to open stream: Permission denied in /chroot/home/rechaneu/rechan.eu.org/html/s/r4.php on line 285, referer: http://rechan.eu.org/s/
Stop jumping to conclusions. It was working before we moved hosts. And now it's been fixed.
>>99
No it wasn't, the whole site was broken before you moved.
http://wakaba.c3.cx/soc/kareha.pl/1108009355/n180-
Hmm... I was looking through the BSD source tree and wondering why BSD doesn't have their own compiler? They seem to use gcc too.
>>102
Apparently 4.4BSD, the final release of the original which the current distributions of BSD are descended from, switched from a truly ancient compiler (1970s vintage) called "pcc" to gcc. I'm not certain why; pcc might have been AT&T owned at the time, or just suffering from neglect.
A maintainer appeared last year and started working on pcc again, and there's talk that the more ideological BSDs (i.e. not FreeBSD) might switch back to using it.
commissioned by /prog/:
http://rechan.eu.org/misc/anoncoreutils-20080601-1.tar.bz2
>>102,105
i lol'd at !6mHaRuhies, !MhMRSATORI!!L0f5nl0+ and above having the same ID
>>107
We're posting through the local repo server. It's so you can identify what posts are from the Anonix core group (which manages file releases among other things) to prevent someone else from faking a release filled with GNU copypasta.
>>108
What, being a tripfag isn't adequate proof of your identity?
Also, you should mention somewhere your shit isn't BSD 4.3 compatible and requiring _XOPEN_SOURCE=600 or similar to compile without spewing undefined identifiers, at least on my system.
Also, ISO C90 still doesn't support 'long long'.
>>109
a/c isn't Windows compatible either now is it?
Try compiling on a fully POSIX compliant system.
Compile the few progs that use 'long long' in C99 mode if you must.
> Try compiling on a fully POSIX compliant system.
I'm running Ubuntu on an OLPC. Care to suggest what I can install on an OLPC that's fully POSIX compliant, since that apparently isn't?
>>111
MINIX ought to work, but I'm using LFS with the include files edited to naturally define the POSIX stuff (instead of having it locked inside #ifdef's).
(Not too familiar with OLPC, but I think it's a standard PC architecture which should be fine.)
rechan is down halp
>>113
works now, probably just server maintenence
int haxanus (void) {
printf("file not found, DESU\n");
exit(EXIT_FAILURE);
}
Eliminating the bloat that GNU utilities have? Command line programs?
You people are tripping.
lol permasaged
RAGE FAGGOTS, RAGE!
Also, Boxxy.
Also THE GAME!
HAX MY ANUS!
>122
i see you, but that doesn't count in a permasaged thread anyway
posting in a legendary kusosure