/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: 20005061706352643760251034665507247403176742630660 50462223206040017306150002434274350703035033674561 20754173510400040000000050000000000007737204577300 00177356040504450022043404000034041773610464046404 00000000000000000000000000000000000000000000000000 00000000000000000000000000640423461000000000000000 00000000000000000000000000002404000000004100700000 00634610000000000000000000000000000000000000000000 00000000000000000000000000005604000000000000340437 73040037730504300000004773000000000000000000000000 00003000100000000000000000000000000000000000000000 00000000000000000000000000000450045004000000002000 70041304330407040000170434041704050427730704050400 30160457732404000067040000000000000000000070042000 64040000340400006404677300045004000000005773200070 04130433040704000017043404640440004773070440000770 00007773240400005704000000000000000000000000000034 04710007047773220417046704000000000000777300000000 00000000077007735404050416046304070457733773020470 00200040044773577311046414641437736504641457733404 000054041773220464045704

/dev/urandom: 10313700276075133047145322754731744715330540305544 55772411741125544374737071744665152471472301655103 21673032612147044376361336471103425426601777564215 27537506506760532046755677545002343626131545501130 60140067534031123241466461750705230751645572440071 57744425536470274352332415164131435115125573101442 74556544717777054520152351764241666207571007700122 35623563012311717741547124617262165454244161061517 74201651063200446176135471662402411424412532245563 11545142476223664702172000553652612247511550424514 72612104741103553240132614710710775524572432011176 15642610621436346764640170271720054525337367306022 20367455521635765367573615753123615162510360064030 26113642124742630634422243216772330177360713406462 47534536645354770361405340770217451441530701353725 67322557767603402406511316575637667506305617702430 35222250564070154307150656704155003661646277201332 46523045641760343566266442731667313365016666076430 23673210310073545356647564170524251663066260134503 70701275067537603265673560312322526077022157223404 211323047413633213326054

--
Ron Peterson
Network & Systems Manager
Mount Holyoke College

[Joona I Palaste]

Ron Peterson <rp******@mtholyoke.edu> scribbled the following:

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?
Your question is about the Unix devices /dev/random and /dev/urandom,
not about C. Please continue discussion about this on
comp.unix.programmer.
#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: 20005061706352643760251034665507247403176742630660 50462223206040017306150002434274350703035033674561 20754173510400040000000050000000000007737204577300 00177356040504450022043404000034041773610464046404 00000000000000000000000000000000000000000000000000 00000000000000000000000000640423461000000000000000 00000000000000000000000000002404000000004100700000 00634610000000000000000000000000000000000000000000 00000000000000000000000000005604000000000000340437 7304003773050430000000477300000000000000000000 00000000300010000000000000000000000000000000000000 00000000000000000000000000000000045004500400000000 20007004130433040704000017043404170405042773070405 04003016045773240400006704000000000000000000007004 20006404000034040000640467730004500400000000577320 00700413043304070400001704340464044000477307044000 07700000777324040000570400000000000000000000000000 00340471000704777322041704670400000000000077730000 00000000000007700773540405041604630407045773377302 04700020004004477357731104641464143773650464145773 34040000540
41773220464045704
/dev/urandom: 10313700276075133047145322754731744715330540305544 55772411741125544374737071744665152471472301655103 21673032612147044376361336471103425426601777564215 27537506506760532046755677545002343626131545501130 60140067534031123241466461750705230751645572440071 57744425536470274352332415164131435115125573101442 74556544717777054520152351764241666207571007700122 35623563012311717741547124617262165454244161061517 74201651063200446176135471662402411424412532245563 115451424762236647021720005536526122475115504

24514726121047411035532401326147107107755245724320 11176156426106214363467646401702717200545253373673 06022203674555216357653675736157531236151625103600 64030261136421247426306344222432167723301773607134 06462475345366453547703614053407702174514415307013 53725673225577676034024065113165756376675063056177 02430352222505640701543071506567041550036616462772 01332465230456417603435662664427316673133650166660 76430236732103100735453566475641705242516630662601 34503707012750675376032656735603123225260770221572 23404211323
047413633213326054

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-------------------------------------------------------- rules! --------/
"I will never display my bum in public again."
- Homer Simpson

[infobahn]

Ron Peterson wrote:

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';
This assignment violates dat's bounds, invoking undefined behaviour.
So all bets are off.

Make it char dat[RAND_LEN + 1];

if( fd != -1 ) {
read( fd, dat, RAND_LEN );
for( i = 0; i < RAND_LEN; i++ ) {
dat[i] = (dat[i] >> 4 & 0x07) + 48;
Again, undefined behaviour. This time it's because you're reading
an indeterminate value, dat[i].
}
printf( "%s: %s\n\n", dev, dat );
} else {
exit( 1 );
}

close( fd );
}

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

Leaving those bugs unfixed, does swapping these two calls
reverse the behaviour? That is, if you do this instead:

read_random( "/dev/urandom" );
read_random( "/dev/random" );

are the excess 0s now associated with /dev/urandom instead?

If so, you can be reasonably sure that the problem lies with
the problems I've mentioned.

[Ron Peterson]

I was copying bits and pieces from other code, and made a couple of
errors. I should have typed:

char dat[RAND_LEN + 1]; (so I'm not going beyond end of array)

and

dat[i] = (dat[i] & 0x07) + '0'; (I don't need to bit shift, I just want
three bits).

Anyway, when I do these things, I still get long strings of zeroes from
/dev/random. ?

Not exactly a C question, I know. I could direct this to the kernel
list, as the kernel provides random and urandom, but I was thinking the
behaviour should be consistent between kernels, so it's not really a
kernel question. If someone can suggest a more appropriate list, that's
helpful too.

BTW, I'm using linux 2.6.x. If anyone running a BSD variant could
compile this and compare the results, that might be interesting.

-Ron-
On 7 Jan 2005 09:33:44 -0500, Ron Peterson <rp******@mtholyoke.edu> wrote:

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: 20005061706352643760251034665507247403176742630660 50462223206040017306150002434274350703035033674561 20754173510400040000000050000000000007737204577300 00177356040504450022043404000034041773610464046404 00000000000000000000000000000000000000000000000000 00000000000000000000000000640423461000000000000000 00000000000000000000000000002404000000004100700000 00634610000000000000000000000000000000000000000000 00000000000000000000000000005604000000000000340437 73040037730504300000004773000000000000000000000000 00003000100000000000000000000000000000000000000000 00000000000000000000000000000450045004000000002000 70041304330407040000170434041704050427730704050400 30160457732404000067040000000000000000000070042000 64040000340400006404677300045004000000005773200070 04130433040704000017043404640440004773070440000770 00007773240400005704000000000000000000000000000034 04710007047773220417046704000000000000777300000000 00000000077007735404050416046304070457733773020470 00200040044773577311046414641437736504641457733404 000054041773220464045704

/dev/urandom: 10313700276075133047145322754731744715330540305544 55772411741125544374737071744665152471472301655103 21673032612147044376361336471103425426601777564215 27537506506760532046755677545002343626131545501130 60140067534031123241466461750705230751645572440071 57744425536470274352332415164131435115125573101442 74556544717777054520152351764241666207571007700122 35623563012311717741547124617262165454244161061517 74201651063200446176135471662402411424412532245563 11545142476223664702172000553652612247511550424514 72612104741103553240132614710710775524572432011176 15642610621436346764640170271720054525337367306022 20367455521635765367573615753123615162510360064030 26113642124742630634422243216772330177360713406462 47534536645354770361405340770217451441530701353725 67322557767603402406511316575637667506305617702430 35222250564070154307150656704155003661646277201332 46523045641760343566266442731667313365016666076430 23673210310073545356647564170524251663066260134503 70701275067537603265673560312322526077022157223404 211323047413633213326054

--
Ron Peterson
Network & Systems Manager
Mount Holyoke College

[Jens.Toerring]

Ron Peterson <rp******@mtholyoke.edu> wrote:

I was copying bits and pieces from other code, and made a couple of
errors. I should have typed: char dat[RAND_LEN + 1]; (so I'm not going beyond end of array) and dat[i] = (dat[i] & 0x07) + '0'; (I don't need to bit shift, I just want
three bits). Anyway, when I do these things, I still get long strings of zeroes from
/dev/random. ? Not exactly a C question, I know. I could direct this to the kernel
list, as the kernel provides random and urandom, but I was thinking the
behaviour should be consistent between kernels, so it's not really a
kernel question. If someone can suggest a more appropriate list, that's
helpful too.

Joona set the follow-up to comp.unix.programmer where it's more
on-topic and where I tried to answer the question...

Regards, Jens
--
\ Jens Thoms Toerring ___ Je***********@physik.fu-berlin.de
\__________________________ http://www.toerring.de

[Christopher Benson-Manica]

infobahn <in******@btinternet.com> spoke thus:

if( fd != -1 ) {
read( fd, dat, RAND_LEN );
for( i = 0; i < RAND_LEN; i++ ) {
dat[i] = (dat[i] >> 4 & 0x07) + 48;

Again, undefined behaviour. This time it's because you're reading
an indeterminate value, dat[i].

It isn't necessarily undefined behavior, if RAND_LEN bytes happen to
have been read. Unless I'm missing something, the code could be
corrected with

if( fd != EOF ) { /* right? */
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++ ) {
/* ... */
}
}
/* ... */
}

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

[infobahn]

Ron Peterson wrote:

I was copying bits and pieces from other code, and made a couple of
errors. I should have typed:
Oh dear. We'd prefer to debug your program errors, not your
typographical errors. :-(

char dat[RAND_LEN + 1]; (so I'm not going beyond end of array)
Fair enough.

and

dat[i] = (dat[i] & 0x07) + '0'; (I don't need to bit shift, I just want
three bits).

This is still broken. Please refer to my earlier reply.

[Chris Croughton]

On 7 Jan 2005 09:33:44 -0500, Ron Peterson
<rp******@mtholyoke.edu> wrote:

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?
For a start, your question is not really C related, it could happen in
any language. Not only is /dev/random device specific but you are also
using POSIX I/O functions (open/read etc.) rather than the C ones.
read( fd, dat, RAND_LEN );
What is the length read? It is quite possible that read() is returning
when it gets the first byte or few bytes, and the rest of the array is
undefined.
for( i = 0; i < RAND_LEN; i++ ) {

You are assuming that you know that the whole array was filled. I
suggest that it wasn't.

(I have a reason for suggesting this. I used dd(1) to read a block from
/dev/random into a file. The first time it got 1024 bytes. The next
time it got two, the one after around 30. I'd be pretty sure that dd(1)
is using the same mechanism to read data. That was on Linux kernel
2.2.19...)

Which does make it a sort-of C question, because if you used the C I/O
(fopen, fread etc.) you might find different behaviour. Or perhaps
not...

Chris C

[infobahn]

Christopher Benson-Manica wrote:

infobahn <in******@btinternet.com> spoke thus:

if( fd != -1 ) {
read( fd, dat, RAND_LEN );
for( i = 0; i < RAND_LEN; i++ ) {
dat[i] = (dat[i] >> 4 & 0x07) + 48;

Again, undefined behaviour. This time it's because you're reading
an indeterminate value, dat[i].

It isn't necessarily undefined behavior, if RAND_LEN bytes happen to
have been read.

My apologies to the OP. I didn't spot the read()! (Duh...)

In that case, I am not sure that anything remains for comp.lang.c
to contribute here. Perhaps comp.unix.programmer could help.

[Ron Peterson]

On 7 Jan 2005 11:46:47 -0500, Ron Peterson <rp******@mtholyoke.edu> wrote:

Anyway, when I do these things, I still get long strings of zeroes from
/dev/random. ?

Not exactly a C question, I know. I could direct this to the kernel
list, as the kernel provides random and urandom, but I was thinking the
behaviour should be consistent between kernels, so it's not really a
kernel question.

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.

Best.

--
Ron Peterson
Network & Systems Manager
Mount Holyoke College

[Christopher Benson-Manica]

Ron Peterson <rp******@mtholyoke.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)cyberspace.org | don't, I need to know. Flames welcome.

[Michael Wojcik]

In article <41********@nap.mtholyoke.edu>, Ron Peterson <rp******@mtholyoke.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.programmer.

--
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**********@chessie.cirr.com>, Christopher Benson-Manica <at***@nospam.cyberspace.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*****@newsguy.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)cyberspace.org | don't, I need to know. Flames welcome.

[Martin Ambuhl]

Christopher Benson-Manica wrote:

Michael Wojcik <mw*****@newsguy.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.cyberspace.org> writes:

Michael Wojcik <mw*****@newsguy.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_Keith) 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*****@newsguy.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******@btinternet.com> writes:

Christopher Benson-Manica wrote:

Michael Wojcik <mw*****@newsguy.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.org> 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)cyberspace.org | don't, I need to know. Flames welcome.

[Keith Thompson]

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

Keith Thompson <ks***@mib.org> 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_Keith) 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.

[Villy Kruse]

On Thu, 13 Jan 2005 00:18:48 GMT,
Keith Thompson <ks***@mib.org> wrote:

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

Occasionally confused with the standard library function called "system".
Villy

[Keith Thompson]

Villy Kruse <ve*@station02.ohout.pharmapartners.nl> writes:

On Thu, 13 Jan 2005 00:18:48 GMT,
Keith Thompson <ks***@mib.org> wrote:

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

Occasionally confused with the standard library function called "system".

Good point.

<OT>
system() is typically implemented as a library function, not as a
system call.
</OT>

--
Keith Thompson (The_Other_Keith) 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.