/dev/urandom vs. /dev/random

[Ron Peterson]

In the following piece of code, which simply generates a sequence of
(random) octal codes, I'm surprised by the apparent non-randomness of
/dev/random. It's not noticeable unless RAND_LENGTH is largish. I was
under the assumption that /dev/random was "more random" than
/dev/urandom, and that it would block if it ran out of entropy until it
got more. Why am I seeing so many zeroes in my output?

#include <stdio.h>
#include <fcntl.h>
#define RAND_LEN 1024

void
read_random( const char* dev ) {
int i, fd;
char dat[RAND_LEN];

fd = open( dev, O_RDONLY );

dat[RAND_LEN] = '\0';

if( fd != -1 ) {
read( fd, dat, RAND_LEN );
for( i = 0; i < RAND_LEN; i++ ) {
dat[i] = (dat[i] >> 4 & 0x07) + 48;
}
printf( "%s: %s\n\n", dev, dat );
} else {
exit( 1 );
}

close( fd );
}

int
main( void ) {
read_random( "/dev/random" );
read_random( "/dev/urandom" );
return( 0 );
}

506$ ./test

/dev/random: 200050617063526 437602510346655 072474031767426 306605046222320 604001730615000 243427435070303 503367456120754 173510400040000 000050000000000 007737204577300 001773560405044 500220434040000 340417736104640 464040000000000 000000000000000 000000000000000 000000000000000 000000000000000 000000640423461 000000000000000 000000000000000 000000000000024 040000000041007 000000063461000 000000000000000 000000000000000 000000000000000 000000000000000 000000005604000 000000000340437 730400377305043 000000047730000 000000000000000 000000000300010 000000000000000 000000000000000 000000000000000 000000000000000 000000000450045 004000000002000 700413043304070 400001704340417 040504277307040 504003016045773 240400006704000 000000000000000 007004200064040 000340400006404 677300045004000 000005773200070 041304330407040 000170434046404 400047730704400 007700000777324 040000570400000 000000000000000 000000003404710 007047773220417 046704000000000 000777300000000 000000000770077 354040504160463 040704577337730 204700020004004 477357731104641 464143773650464 145773340400005 404177322046404 5704

/dev/urandom: 103137002760751 330471453227547 317447153305403 055445577241174 112554437473707 174466515247147 230165510321673 032612147044376 361336471103425 426601777564215 275375065067605 320467556775450 023436261315455 011306014006753 403112324146646 175070523075164 557244007157744 425536470274352 332415164131435 115125573101442 745565447177770 545201523517642 416662075710077 001223562356301 231171774154712 461726216545424 416106151774201 651063200446176 135471662402411 424412532245563 115451424762236 647021720005536 526122475115504 245147261210474 110355324013261 471071077552457 243201117615642 610621436346764 640170271720054 525337367306022 203674555216357 653675736157531 236151625103600 640302611364212 474263063442224 321677233017736 071340646247534 536645354770361 405340770217451 441530701353725 673225577676034 024065113165756 376675063056177 024303522225056 407015430715065 670415500366164 627720133246523 045641760343566 266442731667313 365016666076430 236732103100735 453566475641705 242516630662601 345037070127506 753760326567356 031232252607702 215722340421132 304741363321332 6054

--
Ron Peterson
Network & Systems Manager
Mount Holyoke College

[Christopher Benson-Manica]

Ron Peterson <rp******@mthol yoke.edu> spoke thus:

Pencils down. The LKML list pinned it down for me. It was in fact a C programming error. I wasn't checking the return
value of 'read', to see how much data was actually read.

Not to boast, but note my response elsethread :)

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cybers pace.org | don't, I need to know. Flames welcome.

[Michael Wojcik]

In article <41********@nap .mtholyoke.edu> , Ron Peterson <rp******@mthol yoke.edu> writes:

It was in fact a C programming error. I wasn't checking the return
value of 'read', to see how much data was actually read.

This is a POSIX programming error, not a C programming error. You
could make precisely the same mistake with any language capable of
making system calls on a POSIX system. read is not a C function;
it's a POSIX function.

And that is precisely why this question was OT for comp.lang.c, and
topical for comp.unix.progr ammer.

--
Michael Wojcik mi************@ microfocus.com

Painful lark, labouring to rise!
The solemn mallet says:
In the grave's slot
he lies. We rot. -- Basil Bunting

[Michael Wojcik]

In article <cr**********@c hessie.cirr.com >, Christopher Benson-Manica <at***@nospam.c yberspace.org> writes:

if( fd != EOF ) { /* right? */
Wrong, I'm afraid, and yet another example of why we shouldn't try
to answer off-topic questions here.

fd is the return value from the POSIX open function. open returns
a file descriptor, which is a non-negative integer, or -1 on failure.
Since EOF may not be -1, that's not the appropriate value to compare
it to.
int bytes=read( fd, dat, RAND_LEN );
if( bytes == -1 ) {
/* error */
}
if( bytes ) { /* bytes == 0 implies end of file */
for( i=0; i < bytes; i++ ) {
/* ... */
}
}

This does fix part of the error in the OP's code (it appears that
he expects the read_random function to populate the entire buffer,
so it really needs to loop around calls to read until it's done so),
but note that the test "if( bytes )" is extraneous, since the for
loop does nothing if bytes == 0.

--
Michael Wojcik mi************@ microfocus.com

Not the author (with K.Ravichandran and T.Rick Fletcher) of "Mode specific
chemistry of HS + N{_2}O(n,1,0) using stimulated Raman excitation".

[Christopher Benson-Manica]

Michael Wojcik <mw*****@newsgu y.com> spoke thus:

Wrong, I'm afraid, and yet another example of why we shouldn't try
to answer off-topic questions here.

Well, it wasn't totally off-topic, since we agree that OP failed to
use the standard read() function correctly.

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cybers pace.org | don't, I need to know. Flames welcome.

[Martin Ambuhl]

Christopher Benson-Manica wrote:

Michael Wojcik <mw*****@newsgu y.com> spoke thus:

Wrong, I'm afraid, and yet another example of why we shouldn't try
to answer off-topic questions here.

Well, it wasn't totally off-topic, since we agree that OP failed to
use the standard read() function correctly.

There is no standard function in C called "read". If you are referring
to the POSIX function called "read", then you know that it is topical in
newsgroups addressing POSIX issues and off-topic in newsgroups
addressing C issues. Your "reason" for the question's not being
"totally off-topic" is completely bogus.

[Keith Thompson]

Christopher Benson-Manica <at***@nospam.c yberspace.org> writes:

Michael Wojcik <mw*****@newsgu y.com> spoke thus:

Wrong, I'm afraid, and yet another example of why we shouldn't try
to answer off-topic questions here.

Well, it wasn't totally off-topic, since we agree that OP failed to
use the standard read() function correctly.

What standard read() function would that be? read() is POSIX, not
ISO C. fread() is ISO C.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[infobahn]

Christopher Benson-Manica wrote:

Michael Wojcik <mw*****@newsgu y.com> spoke thus:

Wrong, I'm afraid, and yet another example of why we shouldn't try
to answer off-topic questions here.

Well, it wasn't totally off-topic, since we agree that OP failed to
use the standard read() function correctly.

No, that's not why it wasn't off-topic (for reasons which have been
explained already). It wasn't off-topic because it was a question
about C. The fact that the OP used read() turned out to be relevant,
at which point it would have been perfectly reasonable to redirect
him to another newsgroup if it weren't for the fact that his
question had by that stage been answered already.

We cannot expect everyone asking questions here to know everything
about C, and particularly what is and what is not C. That does not
mean that all questions are topical here if they contain the letter
C! A detailed explanation of the read() function and its part in
the OP's downfall would have been off-topic here, but the question
itself was fine. Consider this question:

Q: As my example code shows, I'm struggling with fork(). Could
someone tell me what I'm doing wrong?

which is a perfectly sensible question to ask in this newsgroup.
Of course, the only topical /answer/ would be to refer the OP to a
*nix group, but that's beside the point.

[Michael Wojcik]

In article <41************ ***@btinternet. com>, infobahn <in******@btint ernet.com> writes:

Christopher Benson-Manica wrote:

Michael Wojcik <mw*****@newsgu y.com> spoke thus:

Wrong, I'm afraid, and yet another example of why we shouldn't try
to answer off-topic questions here.
Well, it wasn't totally off-topic, since we agree that OP failed to
use the standard read() function correctly.

No, that's not why it wasn't off-topic (for reasons which have been
explained already). It wasn't off-topic because it was a question
about C. The fact that the OP used read() turned out to be relevant,
at which point it would have been perfectly reasonable to redirect
him to another newsgroup if it weren't for the fact that his
question had by that stage been answered already.

Agreed, but note that by "answer off-topic questions" above I meant
specifically "try to provide a direct answer, rather than a
redirection to an appropriate group" (usage which is frequently
employed in topicality discussions here).

Of course when confronted with questions that the questioner believes
are about C, but actually turn on an implementation dependency, we
should "answer" them in the sense of providing a redirection. What
we should avoid doing is trying to answer the substance of the
question, for the reasons commonly cited: we may be mistaken about
the implementation, and our responses will not be vetted by the
community dedicated to that implementation.
A detailed explanation of the read() function and its part in
the OP's downfall would have been off-topic here, but the question
itself was fine.

That was indeed my point (except that I referred to Christopher's
comment regarding the return value of the open() function, not the
read() function).

--
Michael Wojcik mi************@ microfocus.com

Auden often writes like Disney. Like Disney, he knows the shape of beasts --
(& incidently he, too, might have a company of artists producing his lines) --
unlike Lawrence, he does not know what shapes or motivates these beasts.
-- Dylan Thomas

[Christopher Benson-Manica]

Keith Thompson <ks***@mib.or g> spoke thus:

What standard read() function would that be?

The one that I thought existed after looking it up in K&R; I should
have understood the difference between "library function" (standard)
and "system call" (not standard). Sorry.

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cybers pace.org | don't, I need to know. Flames welcome.

[Keith Thompson]

Christopher Benson-Manica <at***@nospam.c yberspace.org> writes:

Keith Thompson <ks***@mib.or g> spoke thus:

What standard read() function would that be?

The one that I thought existed after looking it up in K&R; I should
have understood the difference between "library function" (standard)
and "system call" (not standard). Sorry.

The distinction between library functions and system calls isn't the
same as the distinction between standard and non-standard functions.
System calls are an implementation detail; a function in the C
standard library could easily be implemented as a system call. (The
time() function typically is, for example.) Similarly, there are
plenty of functions defined by POSIX but not by ISO C that are
typically implemented as library functions rather than as system
calls.

<OT>
A system call generally works by invoking code within the OS kernel
rather than in a user-mode library. On a Unix-like system, system
calls are documented by man pages in section 2, library functions in
section 3.
</OT>

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.