Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!columbia!rutgers!dayton!viper!john
From: john@viper.UUCP (John Stanley)
Newsgroups: comp.lang.c,net.sources
Subject: Re: binary radix (+ some source) + my $0.02
Message-ID: <883@viper.UUCP>
Date: Thu, 23-Apr-87 13:48:16 EST
Article-I.D.: viper.883
Posted: Thu Apr 23 13:48:16 1987
Date-Received: Sat, 25-Apr-87 12:23:49 EST
References: <213@pyuxe.UUCP> <710@brl-sem.ARPA> <422@ivax.doc.ic.ac.uk> <2970@pegasus.UUCP> <581@csun.UUCP> <11336@topaz.RUTGERS.EDU>
Reply-To: john@viper.UUCP (John Stanley)
Organization: DynaSoft Systems
Lines: 28
Keywords: octal, hex, binary
Xref: mnetor comp.lang.c:1865 net.sources:4364

In article <11336@topaz.RUTGERS.EDU> gaynor@topaz.RUTGERS.EDU (Silver) writes:

 >For an example, instead of saying something like 143b9, say something
 >like rad_conv(143,9) (for those of you who like typing,
 >convert_to_radix(142,9)).
 >
 >It doesn't read as well, but it is a portable solution.  

  Well, that almost does the trick.  The problem is that there's no way
on many machines to use a macro to generate a string from a non-string.
If your macro was to call a function, you'd logicaly need to pass the
function a string, which would be impossible to generate.  You'd need
to write:

       rad_conv("149",9)

which would work fine for the case of passing the info to a function, but
really screws things up if you wanted to macro-substitute a true arbitrary
radix format constant on machines that support such things.

  If you're going to use odd constants, it's best to define the constant
as a #define value (in base 10 or 16) and leave a comment as to what it 
would be in the "other radix".

--- 
John Stanley (john@viper.UUCP)
Software Consultant - DynaSoft Systems
UUCP: ...{amdahl,ihnp4,rutgers}!{meccts,dayton}!viper!john