In article <41f6c9cb.1328362468@News.individual.net>
Dave Hansen <iddw@hotmail.com> wrote:
>FWIW, the Univac never had a C compiler when I was working with it.
>FORTRAN 77, Pascal, PL/I, COBOL, SNOBOL, Lisp, GPSS, Prolog, and many
>others I'm forgetting now, but no C.
There *was* at least one 1100-series C compiler. I never used it,
but I know people who did. The compiler had 9-bit "char" (ASCII
quaterword, as you would expect), 18-bit "short", and 36-bit "long".
I think, but am not sure, that "int" was also 36 bits. All were
of course ones' complement.
(This predated the 1989 C Standard, and I imagine various things
the compiler did would not have been conforming. Note, however,
that ones' complement is explicitly allowed.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40�39.22'N, 111�50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
Reply by 42Bastian Schick●January 27, 20052005-01-27
>
>Suppose I, as your implementor, put this in <stdio.h> (contrary to
>the standard's requirement that I do not do this):
>
> #define i 42
> #define tmp "ha ha"
>
>Now you, the user, write your program, including a function:
>
> #include <stdio.h>
> ...
> void f(...) {
> int i;
> char *tmp;
> ...
>
>When you go to compile this, the compiler "sees" the top of your
>function f() written as:
>
> int 42;
> char *"ha ha";
>
>and gives you a bunch of strange syntax error messages.
>
>I, the implementor, keep out of you way by making sure I do this:
>
> /* flags for __sflag field */
> #define __SRD 1
> #define __SWR 2
> [etc]
>
>You, the user, keep out of my way by not using names like "__SRD".
>For the most part, all the names starting with "_" are mine, and
>all the rest are yours. If I define "i" or "tmp", it is my fault
>for breaking your code. If you define _ZOG, it is your fault for
>breaking my code.
Now, that's clear. Thanks.
--
42Bastian
Do not email to bastian42@yahoo.com, it's a spam-only account :-)
Use <same-name>@monlynx.de instead !
Reply by 42Bastian Schick●January 27, 20052005-01-27
>>
>> Didn't know that C defines the term byte.
>
>I hope you don't write C programs.
I do, but prefer assembler :-)
--
42Bastian
Do not email to bastian42@yahoo.com, it's a spam-only account :-)
Use <same-name>@monlynx.de instead !
Reply by CBFalconer●January 26, 20052005-01-26
Chris Torek wrote:
> 42Bastian Schick <bastian42@yahoo.com> wrote:
>
>> Means, only the compiler or what comes with it should define
>> types with leading underscores ?
>
> Means "the implementor" -- the guy writing your compiler and
> surrounding code.
>
> >(Actually, IIRC I've seen in in some Linux source and found it
> >appealing.)
>
> Suppose I, as your implementor, put this in <stdio.h> (contrary
> to the standard's requirement that I do not do this):
>
> #define i 42
> #define tmp "ha ha"
>
> Now you, the user, write your program, including a function:
>
> #include <stdio.h>
> ...
> void f(...) {
> int i;
> char *tmp;
> ...
>
> When you go to compile this, the compiler "sees" the top of your
> function f() written as:
>
> int 42;
> char *"ha ha";
>
> and gives you a bunch of strange syntax error messages.
>
> I, the implementor, keep out of you way by making sure I do this:
>
> /* flags for __sflag field */
> #define __SRD 1
> #define __SWR 2
> [etc]
>
> You, the user, keep out of my way by not using names like "__SRD".
> For the most part, all the names starting with "_" are mine, and
> all the rest are yours. If I define "i" or "tmp", it is my fault
> for breaking your code. If you define _ZOG, it is your fault for
> breaking my code.
>
> Now, what if you are neither the implementor, nor the end user?
> What if you are the guy writing a library for doing graphics, or
> playing chess, or whatever? What names do *you* get? (The
> Standard answereth not.)
Which is all nice and clear for those not yet aware. As far as the
last paragraph is concerned, common practice is to add a
(hopefully) unique prefix to all names in that library. Some use
prefix, underscore, and then the normal name, as in "hsh_find". I
leave out the underscore. With luck it all works.
--
"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
Reply by Chris Torek●January 26, 20052005-01-26
In article <41f77890.11797123@news.individual.de>
42Bastian Schick <bastian42@yahoo.com> wrote:
>Means, only the compiler or what comes with it should define types
>with leading underscores ?
Means "the implementor" -- the guy writing your compiler and
surrounding code.
>(Actually, IIRC I've seen in in some Linux source and found it
>appealing.)
Suppose I, as your implementor, put this in <stdio.h> (contrary to
the standard's requirement that I do not do this):
#define i 42
#define tmp "ha ha"
Now you, the user, write your program, including a function:
#include <stdio.h>
...
void f(...) {
int i;
char *tmp;
...
When you go to compile this, the compiler "sees" the top of your
function f() written as:
int 42;
char *"ha ha";
and gives you a bunch of strange syntax error messages.
I, the implementor, keep out of you way by making sure I do this:
/* flags for __sflag field */
#define __SRD 1
#define __SWR 2
[etc]
You, the user, keep out of my way by not using names like "__SRD".
For the most part, all the names starting with "_" are mine, and
all the rest are yours. If I define "i" or "tmp", it is my fault
for breaking your code. If you define _ZOG, it is your fault for
breaking my code.
Now, what if you are neither the implementor, nor the end user?
What if you are the guy writing a library for doing graphics, or
playing chess, or whatever? What names do *you* get? (The Standard
answereth not.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40�39.22'N, 111�50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
Reply by pete●January 26, 20052005-01-26
Grant Edwards wrote:
>
> On 2005-01-26, 42Bastian Schick <bastian42@yahoo.com> wrote:
>
> >>> I think common sense is that a byte is nowadays 8 bit.
> >>
> >>Common sense is often wrong. As yours seems to be in this
> >>case. I've worked on architectures where a byte (a-la "C") was
> >>32 bits.
> >
> > Maybe, or even sure, but if you read MBytes, KBytes etc. do you
> > honestly thing in 32-bit bytes ?
>
> No but that's moot. The OP was asking about C programming.
>
> >>> That's it, they speak of words avoiding the term byte.
> >>
> >>The OP is asking about C. In C, 'byte' has a very specific
> >>definition.
> >
> > Didn't know that C defines the term byte.
>
> I hope you don't write C programs.
C defines a number of words like "object" and "string", which
have slightly different meanings in other programming contexts.
--
pete
Reply by Rufus V. Smith●January 26, 20052005-01-26
"Peter" <moocowmoo@newprovidence.demon.co.uk> wrote in message
news:ct68eu$7h0$1$830fa7a5@news.demon.co.uk...
>
> "Neo" <timeless_illusion@yahoo.com> wrote in message
> news:35mbgiF4pcd1dU1@individual.net...
> > Hi All,
> >
> > Is that true that size of a byte not necessarily 8-bit?
>
> veering off topic a bit....
>
> Anybody else old enough to have worked on a machine with a 24 bit word and
a
> 6 bit char? The first machine I learned assembler on was like that. With
> only 6 bits something had to give, and so it couldn't use lower case
> letters.
>
> Fortunately, they were all scrapped before they got around to implementing
C
> on them.
>
> Peter
>
I worked on a machine that was 36 bits and a character was 9 bits.
I think it was GE? Might have been DEC.
I don't remember if a byte was 9 or 18 bits.
But I do remember there was a lot of packing of variables names into
6-bit characters...
Rufus
Reply by Grant Edwards●January 26, 20052005-01-26
On 2005-01-26, 42Bastian Schick <bastian42@yahoo.com> wrote:
>>> I think common sense is that a byte is nowadays 8 bit.
>>
>>Common sense is often wrong. As yours seems to be in this
>>case. I've worked on architectures where a byte (a-la "C") was
>>32 bits.
>
> Maybe, or even sure, but if you read MBytes, KBytes etc. do you
> honestly thing in 32-bit bytes ?
No but that's moot. The OP was asking about C programming.
>>> That's it, they speak of words avoiding the term byte.
>>
>>The OP is asking about C. In C, 'byte' has a very specific
>>definition.
>
> Didn't know that C defines the term byte.
I hope you don't write C programs.
--
Grant Edwards grante Yow! Could I have a drug
at overdose?
visi.com
Reply by Richard●January 26, 20052005-01-26
"Peter" <moocowmoo@newprovidence.demon.co.uk> wrote in
news:ct68eu$7h0$1$830fa7a5@news.demon.co.uk:
>
> "Neo" <timeless_illusion@yahoo.com> wrote in message
> news:35mbgiF4pcd1dU1@individual.net...
>> Hi All,
>>
>> Is that true that size of a byte not necessarily 8-bit?
>
> veering off topic a bit....
>
> Anybody else old enough to have worked on a machine with a 24 bit word
> and a 6 bit char? The first machine I learned assembler on was like
> that. With only 6 bits something had to give, and so it couldn't use
> lower case letters.
>
> Fortunately, they were all scrapped before they got around to
> implementing C on them.
>
I remember working on one with a 60 bit word, then there were a couple I
worked with just a few years back, one with a 140 bit word, the other
with a 268 (or thereabouts) bit word, in both cases that was also the
smallest addressable unit, other than single bits.
--
Richard
Reply by Hans-Bernhard Broeker●January 26, 20052005-01-26
Jim McGinnis <remove_this.mcginnis@and_this.ieee.org> wrote:
> TI made some very interesting graphics processors about 15 years ago,
> the 34010 and 34020. All their memory was bit-addressable and they had
> an excellent C compiler, but with the quirk that the sizeof an 8-bit
> char was 8, not 1.
While it may have been excellent, it was not a "C compiler" by any
meaningful definition of that term.
If we were to accept such abuse of terms, we might as well call a
Pascal compiler a "C compiler with somewhat buggy spelling".
> This was the source of many bugs.
I'd say this feature itself _was_ a bug. The "many bugs" are just
different manifestations of this one central bug.
--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.