Re: RFC: getting a unique integer value

Subject: Re: RFC: getting a unique integer value
From: Mike Nordell (
Date: Mon Oct 15 2001 - 07:13:22 CDT

Hubert Figuiere wrote:

> According to Patrick Lam <>:
> > > Thanks to Pat Lam we have a great XP random number generator. This
will on
> > > average give you an identical random number one in 2^32 attempts.
> > > approximately 1 in 4,000,000,000 attempts so we're pretty safe :-)
> >
> > Yes, I used the random number generator from some library.
> >
> > If you get a collision with two numbers returned from UT_rand in a
> > address space, you've got other things to worry about; it's far more
> > likely that you'll get hit by a truck, or your roof will spontaneously
> > cave in.
> There are still people that wins lottery. So why not in this case do. In
> short, I disagree when you consider that method to be safe.

I agree with Hub here. If we are to get unique numbers used as IDs for
something, anything, why not use an incrementing ID? Random numbers (even
that this is no RNG, it's like most implementations a PRNG) are used for
quite different purposes. We don't really _need_ random numbers, do we?
Isn't what we actually need unique IDs, or?

Looking into this I (of course) stumbled across List ID's. With a PRNG we
can get 2^32-1 as the first ListID. Does this makes any sense?

I also stumbled across a comment and (horror) a #define in fl_AutoLists.h,
where the comment says 10000 but the define says 1000.

Since I already looked at this file I also got shocked by the amount of
string constant created by #define in it. Is there a reason to use those
macros (and inside them do _casts_!) when a simple const char [] would cut
it? E.g. instead of

#define fmt_NUMBERED_LIST ((const char *)"%*%d")

one could use

const char fmt_NUMBERED_LIST[] = "%*%d";

You can of course replace those signs with your favorite !isalphanum()
sequence for bad language (oh, wasn't that the intent of the string
constant? :-) ).

Another thing that bugged me was "typedef enum { ... } List_Type;". Is This
code ever to be included by C code?

> > Keeping a counter introduces other problems too. You need to lock your
> > counter (to prevent problems with concurrency), etc. And it won't make
> > you do better.
> That is not a really big deal IMHO as you can encaspulate this in a class
> that do the whole job.

Not to mention that this PRNG is in no way thread safe either.

Since it's now included in the AbiWord tree I might add some gripes about
not conforming to AW coding standards (it's GNU-style), not to mention it
invokes implementation defined behaviour by using identifiers containing two
consecutive underscores.

Just a few observations.


This archive was generated by hypermail 2b25 : Mon Oct 15 2001 - 07:14:32 CDT