Xref: utzoo comp.bugs.4bsd:1667 comp.std.c:4181 comp.lang.c:35488 Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!usc!apple!well!jef From: jef@well.sf.ca.us (Jef Poskanzer) Newsgroups: comp.bugs.4bsd,comp.std.c,comp.lang.c Subject: Re: Safe coding practices (was Re: Bug in users command) Message-ID: <22870@well.sf.ca.us> Date: 24 Jan 91 21:03:08 GMT References: <1991Jan24.060707.22566@tkou02.enet.dec.com> Reply-To: Jef Poskanzer Organization: Paratheo-Anametamystikhood Of Eris Esoteric, Ada Lovelace Cabal Lines: 36 In the referenced message, diamond@jit345.enet@tkou02.enet.dec.com (Norman Diamond) wrote: }In article <22855@well.sf.ca.us> Jef Poskanzer writes: }> #define MAXNAMES 1000 }> static char users[MAXNAMES][UT_NAMESIZE+1]; }> (void) strncpy( users[nusers], u.ut_name, UT_NAMESIZE ); }> users[nusers][UT_NAMESIZE] = '\0'; }>And yes, this will fail if more than 1000 users are logged in at }>the same time. Imagine how concerned I am. } }Uh, maybe equally concerned as people who knew that their operating system }would never last 10 years, or 28 years, or whatever? }Equally concerned as people who knew that the spacecraft would not last a }year, or when it did, they knew it wouldn't last another 4 years? Gosh, in ten years, if every trend in computer usage magically reverses itself, I'll get a message telling me to change the number from 1000 to 10000. Yes, it does check for overflow. }You should know to set a better example than this. I think this is an *excellent* example of appropriate programming technology. Dan Bernstein's hack of reading utmp twice and allocating 50 extra slots in case more users log in between the two is, when you come down to it, *no better*. Just more complicated. Worse, in fact, since he *doesn't* check for overflow. He complained about a hard limit of 200 users and then went and programmed a different hard limit of 50 new users in an unknowable time period. Foo on that. If you must handle an arbitrary number of users, do the doubling-realloc trick. But don't invest the effort until you get at least one report of someone overflowing the fixed-size array, since any malloc hacking that anyone does has a good chance of being buggy. End of sermon. --- Jef Jef Poskanzer jef@well.sf.ca.us {apple, ucbvax, hplabs}!well!jef "Why me, John Bigboote?"