"Ury Segal" <[EMAIL PROTECTED]> writes:
> I got the feeling hat some people here think that C has
> a standard that is commonly followed, (more that C++ in
> any case.)
I have a feeling that you are mixing up the existence of a standard
that people writing code are "supposed" to follow, and the fact that
some people actually don't follow the standard (or standards in
general), thus making their code less portable than it could be. I
also have the feeling that you could think of - or research - the
reasons why certain things are not in the standard. The folks who
wrote the standard (ISO/ANSI, I mean) put in a lot of effort and
thought, and they were not stupid or negligent.
> This is SO FAR from the truth. C has profound
> standartzation problem, some of them built-in in the language.
I suspect that you regard some things that a language cannot define
(things that are outside of the language proper) as "built-in
problems".
> a. Do you know the standard, simple, sscanf() function? Do you
> know what does it return? It varies bwteen BSD, SYSV, and
> other C environments: In the first, it retrun the first
> parameter,and
What first parameter? The format? No, it has to return an int...
> in the other, in returns the number of token actually
> converted.
That's what the standard says it should return. Or EOF if end of file
is reached before any conflict or assignment.
> It all depends on your compiler.
Oh yes, it does,. A compiler implements an approximation to the
standard. Conformance varies between nearly perfect to plainly broken.
And yes, you can change the approximation by using different compiler
flags. GCC is a good example of that.
> 2) The "standard" C variables types
>
> *) Do you know what is the size of an int ? It is built-in into
> the language definition that you cannot know the size of an
> int variable. It cannot BE standartized. GREAT !
Indeed. The size of an int can vary between platforms. It's outside of
C. Same with pointer size. You could have also asked whether long is
wider than int. C doesn't know.
> *) Is the "long long" datatype signed or unsigned by default ?
Never heard of "long long". Long is signed.
> *) Have you ever heard of the "far" keyword, sometimes used as the "FAR"
> macro?
No. I heard of "near" and "far" pointers - implementation-dependent.
> *) "register" . Does anyone know what it does? It varies on different
> versions of the same compiler, for god's sake.
"Register" informs the compiler that an object is likely to be used
heavily and should be allocated in a way that minimizes access time.
It does not tell the compiler what to do specifically. It's a hint,
not a directive. The compiler may do different things under different
circumstances, including doing nothing at all. And that's in the
Standard, AFAIK (disclaimer: I don't own a copy). For instance, if you
use "register" too much, it's likely to be useless or even
counterproductive. A well-optimizing compiler is likely to ignore
"register" altogether - it optimizes storage anyway.
> 4) The "standard" C Preproccesor
>
> Don't get me started on this. Almost no two compiler has similar
> preprocessor. Multiple parameters to a macro with the same name?
> sometimes you have it, sometimes not.
I don't think it is allowed in the sense of overloading.
> and the "#pargma" directive,
Which is intended to provide implementation-dependent information
to the compiler.
> And, I don't know why you guis like Standard so much.
Because when I write compliant code I will have much less trouble
porting it to a new platform. My code has to work on a number of
platforms, and I should be very careful not to use non-compliant
constructs. Yes, portable is defined as "working on all platforms of
interest". There is a wrinkle to that though: I don't know what
platforms will be of interest 2 years down the road. So I try to be
extra cautious. Adhering to the Standard means that I am likely to
be in that domain of the functionality that will be common for the
current and the future platforms.
Maybe you came to the conclusion that it is not important. If you
neglected that in the code you've written during the last 10 years, I
hope I won't have to maintain any of it. Mind you, I can easily
believe that your code is brilliant, elegant, clever, and efficient,
but maybe - just maybe - you rely too much on your intimate knowledge
of the intricacies and personal quirks of some compilers you used...
And yes, on a few occasions I found myself in situation where a
compiler was broken, or where I really needed to use a non-standard
feature. Sometimes there are ways to condition the compilation (now
you can use #pragma, among other things), sometimes it is possible to
re-write the code so that you don't rely on the most horrible features
of the compiler, etc. And there are some non-standard things that are
so common that the definition of "portable" mentioned above makes them
robust enough.
We all know that Linus does not think that Linux must be 100%
POSIX-compliant. It did occur to him that it would be nice to have it
almost 100% POSIX-compliant, didn't it?
--
Oleg Goldshmidt <[EMAIL PROTECTED]>
"... We work by wit, and not by witchcraft;
And wit depends on dilatory time." [Shakespeare]
=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
