16604 2012-04-02 21:46:20 +0000 RFE: add unsigned byte as synonym for octet 2013-06-17 01:14:08 +0000 1 1 1 Unclassified WebAppsWG WebIDL unspecified PC Windows 3.1 RESOLVED WONTFIX P2 enhancement --- 1 kbr cam annevk ian mike public-script-coord therandshow w3c public-webapps-bugzilla oldest_to_newest 66339 0 kbr 2012-04-02 21:46:20 +0000 Would it be possible to add the type 'unsigned byte' as a synonym for 'octet'? Doing so would improve symmetry with the other signed and unsigned types in the spec (short/unsigned short, etc.). 66352 1 annevk 2012-04-03 07:30:52 +0000 Why do we have both byte and octet to begin with? This is confusing with many specifications that use byte as terminology and treat e.g. 0xFF as byte. I'd prefer renaming octet to byte and dropping the current byte. 66385 2 kbr 2012-04-03 19:21:10 +0000 From the standpoint of the typed array and WebGL specs it's essential to have both signed and unsigned byte concepts, so dropping support for signed bytes doesn't work for us. Since the other integer types in Web IDL are signed, and use the "unsigned" modifier for the unsigned variants, it seems most symmetric to do the same for byte. 66396 3 ian 2012-04-03 21:58:20 +0000 "byte" should (and indeed does, in almost all contexts) mean 0..255, IMHO. I recommend "short int" and "unsigned short int" if you need symmetric names, with "byte" as a synonym for "unsigned short int". Or alternatively, "tinyint" and "unsigned tinyint". 66397 4 kbr 2012-04-03 22:11:41 +0000 short and unsigned short already exist in Web IDL and map to C's int16 / uint16. Those typedefs are also needed for the typed array spec and likely elsewhere. "tiny" / "tiny int" and unsigned variants could work. Not sure about the potential for namespace collisions with existing code. Changing byte to be an unsigned type has downsides. It requires updating all existing HTML5 specs which refer to that type, and would imply introducing a "signed byte" type which is again asymmetric with how the other integer types in Web IDL behave. I would still prefer "byte" and "unsigned byte", but would also prefer the pair of types "signed byte" and "byte" over introducing a new "tiny" concept. 66406 5 annevk 2012-04-04 07:34:33 +0000 How many specifications are we talking about here? I cannot find usage of this within HTML itself for instance. We could also name the type "short short", just like we have "long long" for longer than long, "short short" could be shorter than short. 66425 6 w3c 2012-04-04 19:20:48 +0000 I still think if we go down this route we should just be allowed to define custom ranges (e.g., percent [0-100], angle [0-360], richter[0-10.0], etc.) 66426 7 therandshow 2012-04-05 00:02:03 +0000 Nice context for byte vs octet - http://www.tcpipguide.com/free/t_BinaryInformationandRepresentationBitsBytesNibbles-3.htm Careful with "short int" and "unsigned short int" as octet I believe generally (though w/ basic data type lengths you can never be sure) maps to C/C++ signed/unsigned char != signed/unsigned int http://www.cplusplus.com/doc/tutorial/variables/ Ultimately, even though you might confuse byte with short with octet, you will rarely confuse octet with something that is not 8-bits long. Also, with octet - it's not about range, it's about storage size, although if an octet's unsigned (which I think it has to be), it should go from 0-255 66463 8 cam 2012-04-06 01:47:18 +0000 Bits, bytes, words and longs, how many were going to St Ives? octet came from OMG IDL, where it already meant an unsigned 8 bit integer type. When we needed to introduce a signed type, because OMG IDL didn't have one, I used byte because Java's byte type is signed, rather than introduce "signed octet". I agree the current names are a bit sucky, though. But I'm not really in favour of introducing synonyms. Seeing different names for the same concept in different specs, depending on the style preferences of the author, will be confusing. I think there are sufficiently few specs using byte that updating them if we decide to change the names will be easy enough. (It might even just be WebGL and the Typed Arrays spec.) If people think the status quo is unacceptable, then I think my next preference would be to have "byte" and "signed byte", or "octet" and "signed octet". The former looks and sounds nicer, but the latter more strongly feels like something unsigned to me. (And true enough maybe technically a byte doesn't imply 8 bits necessarily, but I don't think it's a real enough concern.) 66466 9 annevk 2012-04-06 06:40:38 +0000 byte and signed byte works. E.g. http://dvcs.w3.org/hg/encoding/raw-file/tip/Overview.html and HTML and many other specifications always talk about bytes in the unsigned sense. I think it would make sense if we did that consistently throughout the platform standards. 89373 10 cam 2013-06-17 01:14:08 +0000 I don't think it's worth changing at this point.