On Mon, Jul 24, 2000, Ury Segal wrote about ""C" is standartizied - In your dreams!":
> I got the feeling hat some people here think that C has
> a standard that is commonly followed, (more that C++ in
> any case.) This is SO FAR from the truth. C has profound
> standartzation problem, some of them built-in in the language.
I don't agree. ANSI C is a good standard, although some things are deliberately
left up to implementation, and even that is defined in the standard.
These differences are easy to overcome with autoconf, or a similar system.
> Let me give you some examples.
>
> 1) The "standard" IO library
>
> 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
>..
ASCI C (ANSI C3.159-1989) *does* specify, to the best of my knowledge,
what this function returns: the number of items assigned.
The fact that some older systems have a different implementation is just
because their C compilation system is not yet ANSI compliant.
>
> b. If you ar not familiar with sscanf, how about fopen(), eh ? Old
> timer, mentioned in K&R. Even THIS has no standard. On most
> Windows/DOS compilers, if you does not use the letter "b" in the
> 2nd argument to open, it will add CRLF, or maybe CR, or maybe
> LD after evert 255, or 254 or 246 character without CR,or CRLF,
> or maybe LF, among them. It all depends on your compiler. This is
> the default behaviour which can be changed in diffrent way in
> different
> compilers. And you don't want to know about the read operation,
> belive
> me.
That's not fair: this idiotic "b" was added to the standard because of
how Microsoft's C compiler worked, and on POSIX conforming system it is
ignored (as mandated by the POSIX standard).
This is indeed a stupid part of the C standard - they should have let microsoft
choke on its own carriage-returns (all it would mean is that gets will
return an additional carriage-return. who cares? Why did they need to define
fictitious "text files"?)
> 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 !
>
> *) Worse: Do you know the size of a pointer ? A long ? what
> ever compiler, or on some system, how you booted the machine,
> effect that.
"how you booted the machine"?? The size of the variables is obviously
defined in compile time (where sizes of static variables, etc., must be
determined) so it cannot change in run-time.
Anyway, this feature of C is one of its important points. I have programmed
on machines where pointers were longer than integers, machines where pointers
were shorter than integers, and you have to be aware of that.
It's not C's fault: it's the fault of processors that have fixed sized pointers
(obviously - although the 8086 complicated even this point), and a fixed size
for their efficient integer (of course you can have 1024-bit integers, but
you'll need special slow code to handle them - the machine has special sizes
that can be handled efficiently).
> *) Is the "long long" datatype signed or unsigned by default ?
> Can you read my the "standard" on this ?
I didn't realise "long long" was even in the standard, but maybe I'm wrong -
I don't have any books here right now.
> *) Have you ever heard of the "far" keyword, sometimes used as the "FAR"
> macro? On 16 bit 8086 systems, it is used widely. Do you know how
> hard is this to go over 100's of 1000's of lines of "standard" C
> code
> and make it 32-bit with this used-to-be widely-used keyword
Yeah, really hard... just do
#define far /*nothing*/
If you're talking about the other direction, then this is *completely* the
implementation's fault: there is no reason why the 8086 compilers (which
I used too, by the way) and assemblers couldn't make the far calls when
they determine that a call needs to be "far". It can also be fixed in the
linking stage... You could also use the "Huge" memory model, in which
case you didn't need this far keyword at all (if I remember correctly).
BTW, I also had a C compiler on my 8-bit Commodore-64 (!!). It worked
very nicely.
>
> *) "register" . Does anyone know what it does? It varies on different
> versions
> of the same compiler, for god's sake.
Register is only a recommendation to the compiler, and is a leftover from
the times when the optimizer wasn't smart enough to do that on its own.
Consider it as a finetuning to the optimizer, and feel free to ignore it.
> 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. and the "#pargma" directive,
You usually don't, and it's not in the standard, so don't use it.
> All those things are just thing I came across during the 10 years
> or so I am writing in C as a payed professional. If you
> really want to see it all, go to the metaacutoconfig source.
I've programmed in C for 15 years, and have seen it all too :)
But considering what has happened in the computer world since, the changes
in C are not all that terrible, and I am still running several C programs I
wrote 10 years ago. Most of the weird checks in autoconf and the likes have
to do not with the C compiler per-se, but rather with libraries and UNIX
systems which have *really* changed a lot (just try compiling a curses program
from 10 years ago, and see if it works).
--
Nadav Har'El | Monday, Jul 24 2000, 21 Tammuz 5760
[EMAIL PROTECTED] |-----------------------------------------
Phone: +972-53-245868, ICQ 13349191 |Cats know what we feel. They don't care,
http://nadav.harel.org.il |but they know.
=================================================================
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]
