[Interest] Operator QMap<uint, uint>[] is casting to int?

[Thiago Macieira]

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