size of a byte and int?

Eh, what do you mean by implementation ?

And what is an application in this regard ?

Is a TCP/IP stack an application in this sense ?

I am confused !

When I read megabytes et cetera, I do so in a hard drive spec, not in a C programming context. When programming, I don't use megabytes, I use precise numbers, and precise sizes. (Unhinted crossposts are evil.)

Richard

A C implementation is whatever it takes to translate and execute a C program. If you have a compiler or a cross compiler, then that would be part of your implementation.

Means, only the compiler or what comes with it should define types with leading underscores ?

(Actually, IIRC I've seen in in some Linux source and found it appealing.)

If the "the basic character set of the execution environment" is Unicode, it would make sense to define CHAR_BIT as 21, even if the processor would be capable of addressing 8 bit octets.

In fact making 21 bit processors would not be a bad idea after all, since a single word could hold char, short and int values, while two words (42 bits) could hold long a float values and three words (63 bit) double values.

Paul

I have not used 24 bit machines, but 36 bit machines with 6 or 9 bit characters.

What is the problem ? Who said that you could not use lowercase characters. It was up to the printing device if it produced all upper-case or all lower-case characters.

In very early computers even 5 bit teletype codes has been used (with letter and digit shift codes). IIRC, some telex machines even printed the local keyboard entry in all upper-case and all text received from the line as all lower-case.

Only a very small number of current programming languages and one family of operating systems make any distinction of upper and lower case characters anyway.

However, a programming language with a much larger character set (such as Unicode) would be interesting, in which you could use e.g. greek characters as variable names when dealing with scientific entities or use a rich set of mathematical operators. The only language with such features I can think of was APL, but there may have been others.

Paul

The compiler, the standard library, maybe the OS.

This is not a matter of chic; if you use leading underscores, you are invading the implementation's namespace which can lead to nasty consequences. Imagine it was the other way round: The implementation would use i, j, k, count, num and others, so you cannot declare variables or functions of the respective names and be sure that everything works as intended as the implementation gives you macros which work on these global variables...

Just have a look at the standard headers; you will probably find many underscores. If you inadvertently #undef'ed or #defined something which is needed there, then you might run into subtle trouble.

Cheers Michael

... snip ...

APL always was all greek to me :-)

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".

I'd say this feature itself _was_ a bug. The "many bugs" are just different manifestations of this one central bug.

"Peter" wrote in news:ct68eu$7h0$1$ snipped-for-privacy@news.demon.co.uk:

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.

No but that's moot. The OP was asking about C programming.

I hope you don't write C programs.

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

Rufus

C defines a number of words like "object" and "string", which have slightly different meanings in other programming contexts.

Means "the implementor" -- the guy writing your compiler and surrounding code.

Suppose I, as your implementor, put this in (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 ... 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.

yeah, I think I get to know them, too. Thank you.

???? Know what ?

I do, but prefer assembler :-)