From: Cort Dougan <cort@fsmlabs.com>
To: Larry McVoy <lm@work.bitmover.com>,
Linus Torvalds <torvalds@transmeta.com>,
Stephen Rothwell <sfr@canb.auug.org.au>,
LKML <linux-kernel@vger.kernel.org>,
anton@samba.org, "David S. Miller" <davem@redhat.com>,
ak@muc.de
Subject: Re: [PATCH] Beginnings of conpat 32 code cleanups
Date: Fri, 22 Nov 2002 13:13:51 -0700 [thread overview]
Message-ID: <20021122131351.C30808@duath.fsmlabs.com> (raw)
In-Reply-To: <20021122115454.A481@work.bitmover.com>; from lm@bitmover.com on Fri, Nov 22, 2002 at 11:54:54AM -0800
"IMHO"? Larry, you're never humble about your opinions :)
} IMHO, the thing that the early Unix systems did wrong was to not have
} u8, u16, u32, etc as basic ctypes in sys/types.h. And C should have
} had a way to fake it if they weren't native.
}
} Anyone who has ported a networking stack or worked on driver knows exactly
} what I'm talking about.
}
} And while I'm whining,
}
} assert(strlen(any typedef) < 8));
Plan9 takes it a step further and tackles the char/8-byte issue. A
printable character is a 16-byte entity - a rune - while char is an 8-byte
quantity. Doing everything in UNICODE forced the issue, I think.
Even better, everything was designed to run with different byte-ordering
schemes so:
ulong
getlong(void)
{
ulong l;
l = (getchar()&0xFF)<<24;
|= (getchar()&0xFF)<<16;
l |= (getchar()&0xFF)<<8;
l |= (getchar()&0xFF)<<0;
return l;
}
always works correctly. They even ripped out the darn c-preprocessor and
just made a smarter optimization compiler.
Improvements in C without ending up with something like C# or C++. Can't
beat that with a stick.
Ah, yes... the streets are paved with gold in the land of Plan9.
} I like my stack variable declarations to line up. I despise some_long_name_t
} typedefs with a passion.
There is a special kind of mind that allows people to follow 5 levels worth
of typedef to struct including stuct with typedefs in them. It involves
having a very unhealthy outlook on the world.
next prev parent reply other threads:[~2002-11-22 20:09 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-11-22 5:23 [PATCH] Beginnings of conpat 32 code cleanups Stephen Rothwell
2002-11-22 19:47 ` Linus Torvalds
2002-11-22 19:54 ` Larry McVoy
2002-11-22 20:13 ` Cort Dougan [this message]
2002-11-22 20:38 ` H. Peter Anvin
2002-11-23 0:28 ` Stephen Rothwell
2002-11-25 19:48 ` Linus Torvalds
2002-11-23 5:16 ` Anton Blanchard
2002-11-25 20:00 ` Linus Torvalds
2002-11-26 13:53 ` Pavel Machek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20021122131351.C30808@duath.fsmlabs.com \
--to=cort@fsmlabs.com \
--cc=ak@muc.de \
--cc=anton@samba.org \
--cc=davem@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lm@work.bitmover.com \
--cc=sfr@canb.auug.org.au \
--cc=torvalds@transmeta.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.