This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author loewis
Recipients alexandre.vassalotti, loewis, pitrou, serhiy.storchaka
Date 2012-11-17.15:41:26
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1353166886.63.0.042280526364.issue12848@psf.upfronthosting.co.za>
In-reply-to
Content
IMO, the right solution is to finish PEP 3154, and support large strings in the format.

For the time being, I'd claim that signed length in the existing implementations are just a bug, and that unsigned lengths are the intended semantics of these opcodes. I can't see anything that is gained by allowing negative lengths.

OTOH, I also think that it won't matter much in practive: if you try to unpickle a string with more than 2GiB on a 32-bit system, chances are really high that you run out of memory. So whether any bug fix needs to be backported, I don't know.
History
Date User Action Args
2012-11-17 15:41:26loewissetrecipients: + loewis, pitrou, alexandre.vassalotti, serhiy.storchaka
2012-11-17 15:41:26loewissetmessageid: <1353166886.63.0.042280526364.issue12848@psf.upfronthosting.co.za>
2012-11-17 15:41:26loewislinkissue12848 messages
2012-11-17 15:41:26loewiscreate