On Friday, 10 May 2019 04:17:03 PDT Roland Hughes wrote: > > Data is different. std::byte is unsigned and "unsigned char" is the actual > > definition of byte. QByteArray should actually get an API to treat its > > contents as bytes, not just chars. > > > > But we weren't talking about data, we were talking about metadata: sizes, > > indices, offsets. > > I was talking about the devices needing the sizes sent in unsigned > octates. Sorry if there was any confusion. The static casts most often > occur here.
Only if we're talking about sizes between 0 to 255. That's what a single unsigned octet can represent. Doesn't strike me as very useful. If you meant transmitting sizes as unsigned values over the network or medium, that's fine, since negative counts are physically meaningless. The bit pattern of any size in signed and unsigned is the same, so the choice between them is irrelevant. You may as well treat the protocol field as signed. > > Then you use a 64-bit signed integer for that. That's why Qt uses qint64 > > for file sizes, regardless of architecture. [cut] > Or the size incoming and outgoing is required to be unsigned and it is > to/from a device where one does not control the firmware. Which, just like the above, you can treat as *signed* 64-bit, since your item count will not likely be more than 9223372036854775807. If it is, then you should use signed 128-bit, not unsigned 64-bit. I understand your argument that the other side may have specified that the field is unsigned. That's fine. But my argument is that all values between 0 and 9223372036854775807 have the exact same bit pattern in both signed and unsigned 64-bit. However, I can now think of one particular case where unsigned math may be useful: dealing with untrusted data (and network definitely is untrusted). Until you confirm that all values are in the expected range, you should keep it unsigned. > We really really really need those things which cannot be negative to be > unsigned. I understand there is great resistance to this for reasons > which make no sense when viewed from the place of one who actually has > to interface with this stuff. No, we do not "really really" need that. Just because one field can't be negative does not mean that others can't. Take the example of a string / vector / bytearray size. As I said above, sizes cannot meaningfully be negative. But functions like indexOf() take an offset position that can be negative and the function can return a negative value indicating that the search failed. Using unsigned for size() is much more likely to cause you to need casts, for no appreciable gain since you cannot have more items in that vector or string than the maximum signed value. > As a compromise, every container should have a usize() method which > returns the value as an unsigned datatype. To make things even more > bullet proof it could be something like > > usize( bool * wasNegative = nullptr) > > ulength(bool * wasNegative = nullptr) Sorry, not convinced. This is as much an ugly band-aid as std::ssize() function. > Then we only have to jump through hoops for things like DICOM. > > https://www.dicomstandard.org/faq/ > > ==== > > Following the (group number, data element number) pair is a length field > that is a 32 bit unsigned even integer that describes the number of > bytes from the end of the length field to the beginning of the next data > element. > > ==== This is fine, but since you can't operate on this much data on a 32-bit system without implementing windowed access through the data in your own code, I don't see as in impediment. You will code your application to deal with a possible 4 GB distance by seeking in the file -- and remember off_t is signed! If you only allow your application on 64-bit systems, then qsizetype can represent all 32-bit unsigned values without loss of information. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products _______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
