search for: chartyid

...normally is in GCC. If char defaulted to unsigned char > several things would be possible. Single char constants that are > defined would be almost always stored in one byte instead of the present > usual two. So, if I get you correctly, you're advocating the creation of a Type::CharTyID in the TypeID enumeration that is always written as a single byte? Note that right now all ASCII values ( <128 ) will be written as a single byte for UByteTyID but for SByteTyID (often the default from FE compilers like GCC), you're right, they'll take two bytes if the value > 63....

On Fri, 20 Aug 2004, Reid Spencer wrote: > > defined would be almost always stored in one byte instead of the present > > usual two. > > So, if I get you correctly, you're advocating the creation of a Type::CharTyID > in the TypeID enumeration that is always written as a single byte? Note that > right now all ASCII values ( <128 ) will be written as a single byte for > UByteTyID but for SByteTyID (often the default from FE compilers like GCC), > you're right, they'll take two bytes if th...

Dear Chris and Reid: Some other random ideas I've had as I've been sifting through the new bytecode format. Please let me know what you think. 1) ANSI C allows for char to default to unsigned char. This is I guess not how it normally is in GCC. If char defaulted to unsigned char several things would be possible. Single char constants that are defined would be almost always stored

At 05:09 PM 8/20/2004, you wrote: >On Fri, 20 Aug 2004, Reid Spencer wrote: > > > defined would be almost always stored in one byte instead of the present > > > usual two. > > > > So, if I get you correctly, you're advocating the creation of a > Type::CharTyID > > in the TypeID enumeration that is always written as a single byte? Note > that > > right now all ASCII values ( <128 ) will be written as a single byte for > > UByteTyID but for SByteTyID (often the default from FE compilers like GCC), > > you're right, they...

...in GCC. If char defaulted to unsigned char >>several things would be possible. Single char constants that are defined >>would be almost always stored in one byte instead of the present usual two. > >So, if I get you correctly, you're advocating the creation of a >Type::CharTyID in the TypeID enumeration that is always written as a >single byte? Note that right now all ASCII values ( <128 ) will be written >as a single byte for UByteTyID but for SByteTyID (often the default from >FE compilers like GCC), you're right, they'll take two bytes if the &g...