I am saying, again and again., and again and again:
I don;t mean that C doesn't HAVE a standard. The standard
is not followed.
That's all.
It is Like C++. C, like C++, has several standard, but no
one folows them. C is like C++ in that matter.
----- Original Message -----
From: Nadav Har'El <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, July 24, 2000 4:38 PM
Subject: Re: "C" is standartizied - In your dreams!
> 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]
>
=================================================================
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]
