Migrating issues to Github, please follow the new discussion here: https://github.com/Mudlet/Mudlet/issues/784
This issue needs to be closed and there is no appropriate status, so will set it to "Opinion" just for migration purposes. ** Bug watch added: github.com/Mudlet/Mudlet/issues #784 https://github.com/Mudlet/Mudlet/issues/784 ** Changed in: mudlet Status: New => Opinion -- You received this bug notification because you are a member of Mudlet Makers, which is subscribed to Mudlet. https://bugs.launchpad.net/bugs/1471406 Title: Insuffienctly well defined object types could theoretically at least cause problems Status in Mudlet: Opinion Bug description: In a forum post inquiring about the maximum number of room IDs that could be used {http://forums.mudlet.org/viewtopic.php?f=13&t=4825} I realised that the TRoom::roomId member is specified as an "int" but as far as I understand it as a signed integer (using 16 bits in total) is only guaranteed to have a maximum positive value of 2^16-1 or 32767 - now in practice it is likely to be using 4 bytes but it need not be so. I would suggest that for this variable - and indeed *for* *all* *simple* *numeric* *types* *that* *get* *stored* *in* *a* *file* we define precisely the size of the object using the Qt provided signed/unsigned types: quint16, qint16 quint32, qint32 quint64, qint64 For the map file I suggest the next time we revise the format we change to read/write the above types, and downgrade to reading generic "ints" etc. from old file formats. For the Mudlet profile I note that we write a version 1.0 into the start BUT WE HAVE COMMENTED OUT THE CHECK FOR THIS ON READING IN EXISTING CODE - that needs to be reimplemented ASAP to minimise "current" code getting broken when we do fix a few items in the future (e.g. the command "seperater"/"separator" element cock-up) as the existing code in the field will break or at least spew out "not understood element" debug messages on future "new/improved/fixed" saved files. Also, in regard to char types (Qt offers: quint8 & qint8): whilst the char type is definitely 8 bits I note especially in the cTelnet class some cases where it is not entire clear whether it is used as a signed or unsigned object - as used it suggests signed but when e.g. we use constants for Telnet options that are more than 127 in value - this implies unsigned values may be put into plain "char" variables. The Qt documents themselves also note: " QDataStream's binary format has evolved since Qt 1.0, and is likely to continue evolving to reflect changes done in Qt. When inputting or outputting complex types, it's very important to make sure that the same version of the stream (version()) is used for reading and writing. If you need both forward and backward compatibility, you can hardcode the version number in the application: stream.setVersion(QDataStream::Qt_4_0); " We do not currently do this, so, theoretically if someone tries to load a map file format version 4 (the earliest that we still support) there is no guarantee that the current Qt libraries will parse the serialized bytes in the same manner as they did in the past - however by addressing that, this become an issue that we can solve for the future. To manage notifications about this bug go to: https://bugs.launchpad.net/mudlet/+bug/1471406/+subscriptions _______________________________________________ Mailing list: https://launchpad.net/~mudlet-makers Post to : [email protected] Unsubscribe : https://launchpad.net/~mudlet-makers More help : https://help.launchpad.net/ListHelp
