rand and srand

[Ben Pfaff]

Ok, fair enough. I had a recollection of supposed-c89 comppliant
compilers warning about it, but they were probably written by a
Certain Software Giant.

Every good C89 compiler warned about the use of implicit int if
set to a high-enough warning level, because use of implicit int
has never been good programming practice. That is quite
different from implicit int being declared obsolescent by the
standard. You don't expect that a compiler will warn only about
practices that the standard has declared obsolescent, do you?

 

[Eric Sosman]

Every good C89 compiler warned about the use of implicit int if
set to a high-enough warning level, because use of implicit int
has never been good programming practice.

"Never" seems too strong. Just twenty years ago there
was no `void' keyword in the language; what would the good
programming practice of that time suggest as a declaration
of qsort(), say?

double qsort(); /* clearly wrong */
int qsort(); /* OK, but misleading */
qsort(); /* better, to my eye */

Observe that the latter two declarations meant exactly the
same thing, and that the third's is superior to the second
*because* its `int' is not explicit.

 

[Ben Pfaff]

Every good C89 compiler warned about the use of implicit int if
set to a high-enough warning level, because use of implicit int
has never been good programming practice.

"Never" seems too strong. [...]

Yes. I was thinking of this in the context of functions that
actually return a value. In that context, I believe that my
statement is correct.

 

[Mark McIntyre]

Every good C89 compiler warned about the use of implicit int if
set to a high-enough warning level, because use of implicit int
has never been good programming practice.

I don't think that's either true or relevant. IME not many compilers
warn about discarding the result of the f... family except at absurdly
high warning levels. Yet surelt that's bad programming practice too.

You don't expect that a compiler will warn only about
practices that the standard has declared obsolescent, do you?

Certainly I'd expect it warn about all sorts of things. I wouldn't
however expect it to warn about perfectly legal practices which some
people might consider distasteful or which offend their aesthetics or
principles.

I personally abhor arrays of function pointers, they're the devil's
spawn, and I insist on the braces-on-a-new-line style but I'm not going
to write a compiler that insults people who use a different layout.

 

[Richard Tobin]

I don't think that's either true or relevant. IME not many compilers
warn about discarding the result of the f... family except at absurdly
high warning levels. Yet surelt that's bad programming practice too.

There are lots of cases where it's perfectly reasonable not to test
the result of those functions. Perhaps you're going to check ferror()
later. Or if it's output to the terminal, there may well not be much
you can do about it - the likely cause of the error will also prevent
you from reporting it. So whether it's "bad programming practice"
depends on factors the compiler probably cannot determine.

-- Richard

 

[santosh]

If I had been alert I would have known. N1124 is obviously later
than N869.

So I still don't have a proper description of c90 or C95, nor C89
(that standard is a copy of something I got from Dan Pop, which has
obvious holes in it). Bah.

Why not buy a copy from ANSI?

 

[santosh]

Woops. I read it somewhat more carefully, and you are right.

You might also be interested in using the latest working document of
WG14, found at:

<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf>

 

[CBFalconer]

You might also be interested in using the latest working document
of WG14, found at:

<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf>

I've got that. I have been looking for a public copy of the C90 or
C95 standard. The only thing I have is the Dan Pop version of C89,
which has some glaring holes in it.

 

[Keith Thompson]

CBFalconer wrote: [...]

So I still don't have a proper description of c90 or C95, nor C89
(that standard is a copy of something I got from Dan Pop, which has
obvious holes in it). Bah.

Why not buy a copy from ANSI?

Last time I checked, ANSI no longer sells the C90 standard.

 

[Martin]

Why not buy a copy from ANSI?

ANSI aren't selling the *old* C Standard. I asked about this a few weeks
ago and was given this link: http://flash-gordon.me.uk/ansi.c.txt, and
this for the Rationale: http://www.lysator.liu.se/c/rat/title.html.

 

[CBFalconer]

ANSI aren't selling the *old* C Standard. I asked about this a
few weeks ago and was given this link:

http://flash-gordon.me.uk/ansi.c.txt,

and this for the Rationale:

http://www.lysator.liu.se/c/rat/title.html.

I believe that is the faulty version of C89 that Dan Pop supplied.
Some areas are just missing.

 

[Flash Gordon]

CBFalconer wrote, On 17/03/08 20:19:

I believe that is the faulty version of C89 that Dan Pop supplied.
Some areas are just missing.

The ansi.c.txt file is indeed the one from Dan Pop, which is one reason
why I would prefer that people posted a link to
http://clc-wiki.net/wiki/c_standard so that Dan gets the credit for
originally providing it. Also if anyone had a link to a better version
please feel free to update the Wiki accordingly.

The link to the rational, however, is another matter. It would have been
helpful if you had made this clear in your response.

 

[David Thompson]

...and is illegal under C99 and later versions, as all declarators
must explicitly declare a type.

Nit: declaration, or more specifically here function-definition, and
even more specifically declaration-specifiers, but not declarator.

- formerly david.thompson1 || achar(64) || worldnet.att.net

 

[David Thompson]

C89, as well as earlier pre-standard versions of the language, had an
"implicit int" rule, <snip>
(As I understand it, saving keystrokes was more important when C and
its ancestor languages were first designed; the teletypes of the time
required a lot more pressure to enter characters than a modern
keyboard does. That rationale has been irrelevant for many decades.)

If you mean actual (mechanical) Teletypes, yes the keyboard was pretty
'hard' (especially if not oiled!). But the then common and affordable
Teletype models (33 and to a lesser extent 35) didn't have lowercare
and { | } ~ which made using them for C inconvenient indeed. (Yes, the
Unix tty driver had workarounds to allow use of uppercase-only
terminals. Really ugly workarounds. Workarounds which could be the
dictionary illustration for 'bletcherous'. Well, at least if the
Hacker's Dictionary were illustrated. <G>)

If you mean other types of terminals, then commonly if inaccurately
referred to generically as 'teletypes' or 'ttys' (and especially video
character terminals, commonly called 'glass ttys'), they almost all
used electronic keyboards generally similar to most of today's. The
only other then-common terminal with a mechanical keyboard I recall
was the IBM 2741, based on their Selectric typewriter, which was
beautifully engineered and even though mechanical was quite easy to
use if properly maintained. (Except when locked by the system it was
connected to, but that wasn't the terminal's fault.)

A more possible rationale was the cost of disk and limits on memory,
but I think the real reason (and undisputably _a_ reason) is that C
derived from B which didn't ALLOW specifying any type, and it was very
useful in transitioning programs, and programmers, to allow old code
and styles to continue working. Perhaps this 'phase-in' should have
been ended earlier than '99, though.

<snip rest>
- formerly david.thompson1 || achar(64) || worldnet.att.net

 

[Keith Thompson]

CBFalconer wrote: [...]
So I still don't have a proper description of c90 or C95, nor C89
(that standard is a copy of something I got from Dan Pop, which has
obvious holes in it). Bah.
Why not buy a copy from ANSI?

Last time I checked, ANSI no longer sells the C90 standard.

http://webstore.ansi.org/RecordDetail.aspx?sku=AS+3955-1991

Thanks, I was mistaken. (But $112 is more than I'd be willing to pay,
especially if the PDF is as bad as the copy I have.)

 

[Keith Thompson]

Keith Thompson wrote:
CBFalconer wrote:
[...]
So I still don't have a proper description of c90 or C95, nor C89
(that standard is a copy of something I got from Dan Pop, which has
obvious holes in it). Bah.
Why not buy a copy from ANSI?
Last time I checked, ANSI no longer sells the C90 standard.
http://webstore.ansi.org/RecordDetail.aspx?sku=AS+3955-1991

Thanks, I was mistaken. (But $112 is more than I'd be willing to pay,
especially if the PDF is as bad as the copy I have.)

Hmm. ANSI says "This Standard is identical with and has been
reproduced from ISO/IEC 9899:1990."

ISO/IEC 9899:1990 is available for $30. Try:

<http://webstore.ansi.org/FindStandards.aspx?SearchString=ISO/IEC+9899&SearchOption=1&PageNum=0>

Where I also found links to download TC1, TC2, and TC3 at no charge.

Look again. They offer ISO/IEC 9899:1999 for $30. AS 3955-1991,
apparently a copy of the C90 standard, is $112.

 

[Harald van Dijk]

I must be missing something. If it's identical to the ISO/IEC document,
then why not purchase the lower-priced document and save $82?

1990 != 1999. ISO/IEC 9899:1999 is C99, and that is available for $30. ISO/
IEC 9899:1990 is C90.

 

[Keith Thompson]

I must be missing something. If it's identical to the ISO/IEC
document, then why not purchase the lower-priced document and save
$82?

The $30 document is the C99 standard.
The $112 document is the C90 standard.

[...]