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",ran d());
}

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]

Re: rand and srand

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]

Re: rand and srand

On Sun, 09 Mar 2008 14:57:38 -0600, Falcon Kirtaran
<falconnews@iri diumlinux.orgwr ote 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",ran d());
}

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.l earn.c-c++

http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

[Keith Thompson]

Re: rand and srand

Jack Klein <jackklein@spam cop.netwrites:

On Sun, 09 Mar 2008 14:57:38 -0600, Falcon Kirtaran
<falconnews@iri diumlinux.orgwr ote 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_Keit h) <kst-u@mib.org>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Richard Heathfield]

Re: rand and srand

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]

Re: rand and srand

Falcon Kirtaran <falconnews@iri diumlinux.orgwr ites:

...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);in t main(void){unsi gned long b[]
={0x67dffdff,0x 9aa9aa6a,0xa77f fda9,0x7da6aa6a ,0xa67f6aaa,0xa a9aa9f6,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)bre ak;else default:continu e;if(0)case 1:putchar(a[i&15]);break;}}}

[Jack Klein]

Re: rand and srand

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

Jack Klein <jackklein@spam cop.netwrites:

On Sun, 09 Mar 2008 14:57:38 -0600, Falcon Kirtaran
<falconnews@iri diumlinux.orgwr ote 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.l earn.c-c++

http://www.club.cc.cmu.edu/~ajo/docs/FAQ-acllc.html

[pete]

Re: Implicit int (was: rand and srand)

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]

Re: Implicit int (was: rand and srand)

santosh <santosh.k83@gm ail.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]

Re: Implicit int

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]

Re: Implicit int

Mark McIntyre <markmcintyre@s pamcop.netwrite s:

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);in t main(void){unsi gned long b[]
={0x67dffdff,0x 9aa9aa6a,0xa77f fda9,0x7da6aa6a ,0xa67f6aaa,0xa a9aa9f6,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)bre ak;else default:continu e;if(0)case 1:putchar(a[i&15]);break;}}}

[Eric Sosman]

Re: Implicit int

Ben Pfaff wrote:

Mark McIntyre <markmcintyre@s pamcop.netwrite s:
>

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

--
Eric.Sosman@sun .com

[Ben Pfaff]

Re: Implicit int

Eric Sosman <Eric.Sosman@su n.comwrites:

Ben Pfaff wrote:

>Mark McIntyre <markmcintyre@s pamcop.netwrite s:
>>

>>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);in t main(void){unsi gned long b[]
={0x67dffdff,0x 9aa9aa6a,0xa77f fda9,0x7da6aa6a ,0xa67f6aaa,0xa a9aa9f6,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)bre ak;else default:continu e;if(0)case 1:putchar(a[i&15]);break;}}}

[Mark McIntyre]

Re: Implicit int

Ben Pfaff wrote:

Mark McIntyre <markmcintyre@s pamcop.netwrite s:
>

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

Re: Implicit int

In article <aSZBj.4245$wc2 .2043@en-nntp-01.am2.easynews .com>,
Mark McIntyre <markmcintyre@s pamcop.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