rand and srand

[Bill Cunningham]

I am stumped on this one. I tried two methods and something just doesn't
seem right. I'll try my new syle.

#include <stdio.h>
#include <stdlib.h>

main() {
srand(2000); /*seed unsigned */
printf("%u",rand());
}

Now I get a number much larger than 2000. Also when I also try RAND_MAX with
srand from time to time.

With main I was always told int was the default type and didn't need to be
declared. Main() has always worked. I hope this code is much more readable.

Bill

[santosh]

Bill Cunningham wrote:

<about main>

The C99 standard wants and int.

Or a type compatible with int.

[...] So is there really a need to use srand ( ) ?

Yes. If you want your next pseudo-random sequence to be different and
not repeat.

[Jack Klein]

On Sun, 09 Mar 2008 14:57:38 -0600, Falcon Kirtaran
<fa********@iridiumlinux.orgwrote in comp.lang.c:

Bill Cunningham wrote:

I am stumped on this one. I tried two methods and something just doesn't
seem right. I'll try my new syle.

#include <stdio.h>
#include <stdlib.h>

main() {
srand(2000); /*seed unsigned */
printf("%u",rand());
}

Now I get a number much larger than 2000. Also when I also try RAND_MAX with
srand from time to time.

With main I was always told int was the default type and didn't need to be
declared. Main() has always worked. I hope this code is much more readable.

Bill

[snip]

As for your main(), I wasn't actually aware that such code was legal C.

Wherever did you get that idea? That code was perfectly legal in C up
until the 1999 update to the C language standard.

My guess is that it is actually void main(), because you never return

Now you're getting silly. Prior to C99, everyplace where it was legal
to define or declare something without an explicit type, it was
implicitly typed as int. Never as void.

main()

....prior to C99, was exactly identical to:

int main()

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

a value from it, so the exit status of your program is most likely
undefined. It is a good idea, particularly in UNIX, to declare it int,
and return 0 at the end (unless the program failed).

This is correct under any version of the C standard. If a program
"falls off the end" of main() without returning a value, the exit
status returned to the environment is undefined.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

[Keith Thompson]

Jack Klein <ja*******@spamcop.netwrites:

On Sun, 09 Mar 2008 14:57:38 -0600, Falcon Kirtaran
<fa********@iridiumlinux.orgwrote in comp.lang.c:

[...]

>a value from it, so the exit status of your program is most likely
undefined. It is a good idea, particularly in UNIX, to declare it int,
and return 0 at the end (unless the program failed).

This is correct under any version of the C standard. If a program
"falls off the end" of main() without returning a value, the exit
status returned to the environment is undefined.

No, C99 added a special-case rule that falling off the end of main()
does an implicit "return 0;"; see C99 5.1.2.2.3.

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Richard Heathfield]

santosh said:

Bill Cunningham wrote:

<about main>

> The C99 standard wants and int.

Or a type compatible with int.

>[...] So is there really a need to use srand ( ) ?

Yes. If you want your next pseudo-random sequence to be different and
not repeat.

The way the OP was using srand(), the next pseudo-random sequence will not
be any different. I would explain further, but there's no point - it's all
in the FAQ, in the "Library Functions" section - see http://c-faq.com

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Ben Pfaff]

Falcon Kirtaran <fa********@iridiumlinux.orgwrites:

...if you srand(1) in a program, the same sequence of random
numbers will be returned each time it is run on the same
implementation and platform.

If you don't call srand() at all, then the implementation behaves
as if srand(1) was called.
--
char a[]="\n .CJacehknorstu";int putchar(int);int main(void){unsigned long b[]
={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da6aa6a,0xa6 7f6aaa,0xaa9aa9f6,0x11f6},*p
=b,i=24;for(;p+=!*p;*p/=4)switch(0[p]&3)case 0:{return 0;for(p--;i--;i--)case+
2:{i++;if(i)break;else default:continue;if(0)case 1:putchar(a[i&15]);break;}}}

[Jack Klein]

On Sun, 09 Mar 2008 15:47:39 -0700, Keith Thompson <ks***@mib.org>
wrote in comp.lang.c:

Jack Klein <ja*******@spamcop.netwrites:

On Sun, 09 Mar 2008 14:57:38 -0600, Falcon Kirtaran
<fa********@iridiumlinux.orgwrote in comp.lang.c:

[...]

a value from it, so the exit status of your program is most likely
undefined. It is a good idea, particularly in UNIX, to declare it int,
and return 0 at the end (unless the program failed).

This is correct under any version of the C standard. If a program
"falls off the end" of main() without returning a value, the exit
status returned to the environment is undefined.

No, C99 added a special-case rule that falling off the end of main()
does an implicit "return 0;"; see C99 5.1.2.2.3.

True, I overstated. Thanks for the correction.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://c-faq.com/
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

[pete]

santosh wrote:

>
CBFalconer wrote:

http://www.open-std.org/JTC1/SC22/wg...docs/n1124.pdf

What? Isn't this a "C99 draft"?

n1124 has to do with the next standard.
n1124 is not a draft of any published standard.

--
pete

[Micah Cowan]

santosh <sa*********@gmail.comwrites:

In any case my point standards.

This is now my favorite freudian slip. :)

--
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/

[Mark McIntyre]

Keith Thompson wrote:

The "draft for C95" Chuck mentioned was in fact a post-C99 draft.

I was aware of that. I made my comment independently.

C95 (which appeared only as an amendment to C90) did not deprecate
implicit int.

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.

--
Mark McIntyre

CLC FAQ <http://c-faq.com/>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

[Ben Pfaff]

Mark McIntyre <ma**********@spamcop.netwrites:

Keith Thompson wrote:

>C95 (which appeared only as an amendment to C90) did not deprecate
implicit int.

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?
--
char a[]="\n .CJacehknorstu";int putchar(int);int main(void){unsigned long b[]
={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da6aa6a,0xa6 7f6aaa,0xaa9aa9f6,0x11f6},*p
=b,i=24;for(;p+=!*p;*p/=4)switch(0[p]&3)case 0:{return 0;for(p--;i--;i--)case+
2:{i++;if(i)break;else default:continue;if(0)case 1:putchar(a[i&15]);break;}}}

[Eric Sosman]

Ben Pfaff wrote:

Mark McIntyre <ma**********@spamcop.netwrites:

>Keith Thompson wrote:

>>C95 (which appeared only as an amendment to C90) did not deprecate
implicit int.

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.

"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.

--
Er*********@sun.com

[Ben Pfaff]

Eric Sosman <Er*********@sun.comwrites:

Ben Pfaff wrote:

>Mark McIntyre <ma**********@spamcop.netwrites:

>>Keith Thompson wrote:
C95 (which appeared only as an amendment to C90) did not deprecate
implicit int.
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.

"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.
--
char a[]="\n .CJacehknorstu";int putchar(int);int main(void){unsigned long b[]
={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da6aa6a,0xa6 7f6aaa,0xaa9aa9f6,0x11f6},*p
=b,i=24;for(;p+=!*p;*p/=4)switch(0[p]&3)case 0:{return 0;for(p--;i--;i--)case+
2:{i++;if(i)break;else default:continue;if(0)case 1:putchar(a[i&15]);break;}}}

[Mark McIntyre]

Ben Pfaff wrote:

Mark McIntyre <ma**********@spamcop.netwrites:

>Keith Thompson wrote:

>>C95 (which appeared only as an amendment to C90) did not deprecate
implicit int.

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.

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.

--
Mark McIntyre

CLC FAQ <http://c-faq.com/>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

[Richard Tobin]

In article <aS*****************@en-nntp-01.am2.easynews.com>,
Mark McIntyre <ma**********@spamcop.netwrote:

>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


--
:wq

[Keith Thompson]

santosh <sa*********@gmail.comwrites:

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.

--
Keith Thompson (The_Other_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[David Thompson]

On Sun, 09 Mar 2008 17:20:22 -0500, Jack Klein <ja*******@spamcop.net>
wrote:
<snip: implicit int>

...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

[pete]

Keith Thompson wrote:

santosh <sa*********@gmail.comwrites:

>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/RecordDetai...u=AS+3955-1991

--
pete

[Keith Thompson]

pete <pf*****@mindspring.comwrites:

Keith Thompson wrote:

>santosh <sa*********@gmail.comwrites:

>>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/RecordDetai...u=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 (The_Other_Keith) <ks***@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Harald van =?UTF-8?b?RMSzaw==?=]

On Thu, 08 May 2008 15:11:50 -0500, Morris Dovey wrote:

Keith Thompson wrote:

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

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.

[Eric Sosman]

Keith Thompson wrote:

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

Does the price difference reflect the worth of C99's changes?

(With apologies to H.S. ;-)

--
Er*********@sun.com