size of a byte and int?

[42Bastian Schick]

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

 

[Michael Mair]

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

The compiler, the standard library, maybe the OS.

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

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

 

[Grant Edwards]

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.

Didn't know that C defines the term byte.

I hope you don't write C programs.

 

[pete]

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


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.

 

[Chris Torek]

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

 

[CBFalconer]

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.

 

[Zilla]

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

 

[42Bastian Schick]

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

???? Know what ?

 

[42Bastian Schick]

I hope you don't write C programs.

I do, but prefer assembler

 

[42Bastian Schick]

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.

 

[toby]

In practice, though, such streams would almost always be files of 8-bit
characters - even if the type happens to be wider. Of course, in
theory, you're right, that could be a portability concern.

I was referring above to being unable to directly address 8 bit data
(packed strings, or blocks read from such an 8 bit packed file), and
requiring shift (or swap) and mask operations to do so.

 

[CBFalconer]

In practice, though, such streams would almost always be files of
8-bit characters - even if the type happens to be wider. Of course,
in theory, you're right, that could be a portability concern.

I was referring above to being unable to directly address 8 bit
data (packed strings, or blocks read from such an 8 bit packed
file), and requiring shift (or swap) and mask operations to do so.

Please desist from publishing these orphaned quoteless articles.
There is no 'above' to which to refer. The google view of a
newsgroup is sadly distorted from reality, as is their foul posting
interface. See my sig below for a partial cure. Better yet, get a
real newsreader. (Netscape, Thunderbird, Xnews all come to mind.
Xnews is only for Windoze)

 

[toby]

...
Please desist from publishing these orphaned quoteless articles.

This is inadvertent - in addition to all their other sins, Google
Groups is now incompatible with my habits. Thanks for the headsup, I'll
try to remember to take the long route through their interface in
future, which allows correct quoting.
In this case the context of the posting was fairly obvious.

--Toby

 

[Chris Torek]

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