hansen@pegasus.UUCP (04/16/87)
< From: dcw@doc.ic.ac.uk (Duncan C White) < 2). In Article 1155 of comp.lang.c, bright@dataio.Data-IO.COM, says : < > How about allowing numbers to be specified in binary radix, < > as in 0b00110101 ? No existing code would be broken, and it < > would be very useful to those of us writing graphics code, < > ... < > As a corollary, support %b in printf and scanf. < < I agree completely. I too agree. ...open toolbox...rummage, rummage...ahh, here's an occassionally handy tool right here that I wrote quite some time ago. /* Convert the numeric arguments into decimal, octal, hexadecimal, and binary. A octal number is prefixed with "0". A hex number is prefixed with "0x" or "0X". A binary number is prefixed with "0b" or "0B". */ Enjoy! Tony Hansen ihnp4!pegasus!hansen P.S. Some notes on portability: This program makes use of two non-universally available features. The first is strtol(), which is very similar to atol() except that it can be set to check the first two characters for "0", "0x" or "0X" and adjust the base accordingly. Public domain versions of this routine have been posted in the past. An alternative is to write your own. Another alternative is to check for these prefixes separately and parallel btol() with otol() and xtol(). The second is the value HIBITL taken from <values.h>. This is simply a long with the highest bit turned on. One way of getting it is to use: #define HIBITL ((unsigned long)(~((unsigned long)~0>>1))) Some people may be able to find a similar value in <limits.h>. #!/bin/sh # This is a shar archive. # The rest of this file is a shell script which will extract: # # octhex.c # # To extract the files from this shell archive file simply # create a directory for this file, move the archive file # to it and enter the command # # sh filename # # The files will be extracted automatically. # Note: Do not use csh. # # Archive created: Thu Apr 16 14:37:22 EDT 1987 # echo x - octhex.c sed 's/^X//' > octhex.c << '~FUNKY STUFF~' /* Convert the numeric arguments into decimal, octal, hexadecimal, and binary. A octal number is prefixed with "0". A hex number is prefixed with "0x" or "0X". A binary number is prefixed with "0b" or "0B". */ #include <stdio.h> #include <values.h> long strtol(); /* print out the number */ void prnum(i) long i; { unsigned long mask; printf("%d 0%o 0x%x 0b", i, i, i); /* print a number as a bit pattern */ for (mask = HIBITL; mask != 0; mask >>= 1) if ((i & mask) != 0) putchar('1'); else putchar('.'); putchar('\n'); } /* convert a number specified by a bit pattern into a long. */ long btol(s) char *s; { unsigned long i = 0; for (s += 2; *s; s++) { i <<= 1; if (*s == '1') i |= 1; } return i; } main(argc,argv) int argc; char **argv; { while (--argc) { char *num = *++argv; if (num[0] == '0' && (num[1] == 'b' || num[1] == 'B')) prnum(btol(num)); else prnum(strtol(num, (char**)NULL, 0)); } return 0; } ~FUNKY STUFF~ ls -l octhex.c # The following exit is to ensure that extra garbage # after the end of the shar file will be ignored. exit 0
aeusemrs@csun.UUCP (Mike Stump) (04/20/87)
In article <2970@pegasus.UUCP> hansen@pegasus.UUCP (60021254-Tony L. Hansen;LZ 3B-315;6243) writes: >< From: dcw@doc.ic.ac.uk (Duncan C White) >< 2). In Article 1155 of comp.lang.c, bright@dataio.Data-IO.COM, says : >< > How about allowing numbers to be specified in binary radix, >< > as in 0b00110101 ? No existing code would be broken, and it >< > would be very useful to those of us writing graphics code, >< > ... >< > As a corollary, support %b in printf and scanf. >< I agree completely. >I too agree. One of the great things about writing your very own C compiler, is that you get the source code! And with the source code you can CHANGE things, and one of the few things I did to my C compiler, was to add in binary constants, as in 0b1001111. I figure, If I ever give one of my programs to anybody worth his weight, he could figure out what I meant, and change it, or if he had source code to his compiler, add binary constants as a feature... People of the net unite; someone, post the diffs to the Vax, and/or System V C compiler to add binary constants, and everyone else, patch your C compiler, so that it can understand binary constants, after all it will only make your C compiler bigger by a few bytes, and you haver the memory to burn. Do you want to be one of the only people left with an outdated C compiler that does not understand binary constants? Please, no flames; read the above as an attemt to get people seriously thinking about a nice feature. The use of such a feature, until it is widely supported, should be used with a little bit of caution; such as if anybody posts a program to net.source (or whatever they call it this week) with a 0b111011 in it, they should expect to get flames! -- Mike Stump, Cal State Univ, Northridge Comp Sci Department uucp: {sdcrdcf, ihnp4, hplabs, ttidca, psivax, csustan}!csun!aeusemrs
physh@well.UUCP (JonPhysh Foreman) (04/22/87)
I had a hack in a C compiler for 4.1 BSD (which went away as well as the source <sorry> for 4.3 BSD) which would accept 0R<Roman Numerals> So that it would be valid to say: pagenumber = 0rvii; /* pagenumber = 7 */ etc. At the same time I also added a special routine which would take 0f<base>.<number>. The "f" is "fix radix", base is the number base to use, and number is the number in "base" base. So: 0f12.10 = 12 (decimal) 0f0x10.10 = 0f16.10 = 16(decimal) /*note imbedded reference 0x..*/ 0f2.10 = 2 (decimal) and "0f18." would consist of the set of { 0123456789abcdefgh } digits. Note, this method only worked up to base 36. I forget what I did with "0f0." and "0f1.". This could get really complicated quickly, but think how good it would do for the C obfustication awards! I don't think I ever implemented printf & scanf functions to deal with this kind of tripe. Jon ------------------------------- Disclaimer: Today, I'm probably insane (or at least I'll plead it that way), who knows about tomorrow. Addresses .. ucbvax!dual!unicom!physh .. hplabs!well!physh .. killer!ssbn!physh
daniels@cae780.TEK.COM (Scott Daniels) (04/23/87)
In article <2924@well.UUCP> physh@well.UUCP (JonPhysh Foreman) writes: >... Format for arbitrary bases: 0f<base>.<number> During an investigation for arbitrary base notations (in SAIL, an ALGOL-holics language), I had proposed: '<char>.<number> , where <char> is the character for radix-1 (a must-be-representable character). A C-like version might be: .<char>.number. Thus .7.xxx is octal, .1.xxx is binary, .F.xxx is hex, .2.xxx is trinary, and .0.xxx is unary (although it is not clear whether 0 is .0.0 or .0.). The advantage of this representation is that it is radix-independent (assuming there is a well-defined mapping of characters to digits); you may unambiguously write a number down whatever the default radix. FROM: Scott Daniels, Tektronix CAE 5302 Betsy Ross Drive, Santa Clara, CA 95054 UUCP: daniels@cae780.UUCP (Scott Daniels) tektronix!teklds!cae780!daniels {ihnp4, decvax!decwrl}!amdcad!cae780!daniels {nsc, hplabs, resonex, qubix, leadsv}!cae780!daniels
gaynor@topaz.RUTGERS.EDU (Silver) (04/23/87)
Until generally recognized as builtins, it might be a good idea to make references to numbers in non-standard radixes as macros or routines to do the radix conversion. 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. But that shouldn't make a big difference, since such fine programmers as ourselves <:-D minimize the number of instances of magik numbers in our code. "The Laughing Fool ( <:-D )" Silver
manis@ubc-cs.UUCP (Vincent Manis) (04/23/87)
Mike Stump proposes changing compilers to support binary radix. While I support the 'b' notation (and hope that X3J11 will consider including it), I *strongly* disagree with the notion of bringing language changes in by changing compilers. First: what are the precise semantics? Are they *exactly* the same as 0x? This is not an entirely trivial question: remember the difference between signed and unsigned, depending on whether a value is decimal or hex. Will all compiler changers do it ``right''? More important, what is to stop a compiler changer from adding more goodies, say the proposed [...] notation for expressions which may not be optimised, or subrange types, or ... ? I'm not saying any of these are bad, but what happens to C's portability when every compiler accepts a peculiar language of its own making? (I say this having, with great trepidation, added a number of trivial language features to a BCPL compiler once. When I handed the compiler over to another person, and went away for a month, I came back only to find that the language accepted by the compiler had changed radically.) There are certainly defects in C, as are there defects in UNIX (what good can you say about a system call named 'creat'???) But the whole point in standardisation is so that we can take code and run it on a new machine or compiler, with no horde of #ifdefs protecting various quirky features. Thanks, Mike, but no, thanks. ----- Vincent Manis {seismo,uw-beaver}!ubc-vision!ubc-cs!manis Dept. of Computer Science manis@cs.ubc.cdn Univ. of British Columbia manis%ubc.csnet@csnet-relay.arpa Vancouver, B.C. V6T 1W5 manis@ubc.csnet (604) 228-6770 or 228-3061 "Long live the ideals of Marxism-Lennonism! May the thoughts of Groucho and John guide us in word, thought, and deed!"
john@viper.UUCP (John Stanley) (04/23/87)
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