Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!nic.MR.NET!eta!com50!jhereg!mark
From: mark@jhereg.Jhereg.MN.ORG (Mark H. Colburn)
Newsgroups: comp.lang.c
Subject: Re: A Universal Random Number Generator.
Message-ID: <593@jhereg.Jhereg.MN.ORG>
Date: 25 Feb 89 23:12:16 GMT
References: <7354@pyr.gatech.EDU> <5873@bsu-cs.UUCP> <9704@smoke.BRL.MIL>
Reply-To: mark@jhereg.MN.ORG (Mark H. Colburn)
Organization: Minnetech Consulting, Inc., St. Paul, MN
Lines: 27

In article <9704@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes:
+In article <5873@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes:
+-In article <7354@pyr.gatech.EDU> naras@stat.fsu.edu (B. Narasimhan) presents
+-a universal random number generator that includes the definitions:
+->#define CONST_2 362436
+->#define CONST_3 7654321
+->#define CONST_4 16777213
+-Better make these long, with an L suffix.  Else some compilers I've
+-encountered will assume they are 16-bit ints, and truncate them
+-accordingly.
+
+Since that is in direct contradiction to K&R1's specs for integer
+constants, one could make a strong case that such a compiler is not
+worth using.  Could you tell us whose compilers are thus broken,
+so we could steer clear of them?

The XENIX compiler, which is a descendant of a Microsoft compiler (I
think), does this.  It has been a problem in PAX, and some other code,
where I had to explicitly cast the constant 1024 to to a long, so that the
compiler wouldn't puke.

Yuk!

-- 
Mark H. Colburn                  "Look into a child's eye;
Minnetech Consulting, Inc.        there's no hate and there's no lie;
mark@jhereg.mn.org                there's no black and there's no white."