I think that endian issues are abstracted from literals. The place it's going to be an issue is the specifiers for pack/unpack or whatever replaces them.
But the presence of the >>> operator (and speaking of low-frequency operators, what about bitwise rotation? Will that be the (( and )) operators?) means that signed/unsigned conversions need to be thought out. Is 0xDEADBEEF >>> 3 going to be positive or negative? =Austin --- Markus Laire <[EMAIL PROTECTED]> wrote: > On 28 Oct 2002 at 16:42, Dan Sugalski wrote: > > > At 4:39 PM -0500 10/28/02, brian wheeler wrote: > > >On Mon, 2002-10-28 at 16:25, Michael Lazzaro wrote: > > > > > >> explicit radix specifications for integers: > > >> 0123 - decimal > > >> 2:0110 - binary [also b:0110?] > > >> 8:123 - octal [also o:123?] > > >> 16:123 - hex [also h:123?] > > >> 256:192.168.1.0 - base 256 > > >> (...etc...) > > >> > > > > > >I've got to admit that I've not paid alot of attention to this > > >thread...but does that mean 0x1234 and 01234 (octal) go away or is > > >this an omission? > > > > While we're at it, maybe we can add in 0rMCM to allow roman > numerals > > too... -- > > What about specifying endiannes also, or would that be too low-level > to even consider? Currently I don't have any examples for where it > might even be used... > > > -- > Markus Laire 'malaire' <[EMAIL PROTECTED]> > > __________________________________________________ Do you Yahoo!? Y! Web Hosting - Let the expert host your web site http://webhosting.yahoo.com/
