I mostly agree with Moshe Zadka and Nadav Har'el on the matter,
but would still like to add something.
Quoth Nadav Har'El on Mon, Jul 24, 2000:
> On Mon, Jul 24, 2000, Ury Segal wrote about ""C" is standartizied - In your dreams!":
> > 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.
I don't know what Ury means by "BSD systems" in his original
message.
FreeBSD man page (which is identical to the ones found in BSD/OS
and OpenBSD (got no NetBSD machine here)) says:
# RETURN VALUES
# These functions return the number of input items assigned, which can be
# fewer than provided for, or even zero, in the event of a matching fail-
# ure. Zero indicates that, while there was input available, no conver-
# sions were assigned; typically this is due to an invalid input character,
# such as an alphabetic character for a `%d' conversion. The value EOF is
# returned if an input failure occurs before any conversion such as an end-
# of-file occurs. If an error or end-of-file occurs after conversion has
# begun, the number of conversions which were successfully completed is re-
# turned.
If you want 4.2BSD (ancient), SunOS man page says:
# RETURN VALUES
# If any items are converted, scanf(), fscanf() and sscanf()
# return the number of items converted successfully. This
# number may smaller than the number of items requested. If
# no items are converted, these functions return 0. scanf(),
# fscanf() and sscanf() return EOF on end of input.
Now, I couldn't find a BSD system on which sscanf() returns any
kind of pointer. Maybe I didn't look enough.
> > 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.
I have not seen any EOL markers except CR/LF on Microsoft
systems, but maybe they changed since I looked last time.
> > 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.
Ah, Ury, text files are different on different systems. Deal
with it. The C standard provides you with a portable way to
write end-of-line markers to text files. Now isn't that great?
Isn't this exactly the way a standard for a portable programming
language should be written?
> 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).
Only because in UNIX EOL is signified by LF alone.
> 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"?)
Objection. There are systems where EOL is not LF, which include
MS-DOS & friends (CR/LF) and Macintosh (CR). And a portable
language should deal with them. So, in my opinion, this is a
feature of the standard, not a bug.
> > 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 !
Duh. I'm sorry, but computer architectures differ from each
other. If you define int as, say, 32 bit, what will you do about
36 bit machines (now mostly extinct)?
> > *) 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.
On several architectures pointers to different things were of
different sizes. I don't know if any of those architectures
exist today.
> "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.
That was probably a part of flame bait.
> > *) 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.
Methinks C99 defines that, but I'm not sure (having not read the
standard).
> > *) Have you ever heard of the "far" keyword, sometimes used as the "FAR"
> > macro? On 16 bit 8086 systems, it is used widely.
And the C standards don't define it.
> > 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
By using "far" the programmer explicitly states that the code is
not going to be portable.
> Yeah, really hard... just do
> #define far /*nothing*/
Or:
CFLAGS += -Dfar=
> > *) "register" . Does anyone know what it does?
I think it's defined as "implementation dependent", but I'm not
sure about it.
> 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.
That is correct. Unlike "volatile", which does have a
well-defined meaning.
> > and the "#pargma" directive,
Defined as "implementation dependent". Proved useful, or at
least harmless in every implementation I know of, except GCC
1.<something>. And if you need to use #pragma, you should write:
#ifdef __THIS_COMPILER__
#pragma whatever
#endif
> > 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.
What is metaacutoconfig? Lack of BackSpace/Delete key?
> I've programmed in C for 15 years, and have seen it all too :)
To see it all, you don't actually have to program C as a "payed"
professional (or, quoting another Uri's mail, FUCKING "expert").
You only need to see _one_ C compiler that runs on Windows, some
old pre-ansi C compiler (such as cc on SunOS), some modern enough
compiler (like GCC) on a UNIX system, and, preferrably, several
different UNIX systems.
> 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).
UNIX libraries did not change a lot. Try to compile a Windows
(2.x?) program from 10 years ago...
Vadik.
--
The reader this message encounters not failing to understand is
cursed.
=================================================================
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]
