[issue23816] struct.unpack returns null pascal strings - [first] bug report

2017-05-04 Thread Mark Dickinson
Mark Dickinson added the comment: Specifically, I believe what's happening here is that "8s4spp" is interpreted as "8s4s1p1p", so it decodes a single byte (which can only encode an empty string) for each of the "1p" cases. I wonder whether the struct module should raise an exception if the

[issue23816] struct.unpack returns null pascal strings - [first] bug report

2017-05-03 Thread Xiang Zhang
Xiang Zhang added the comment: My previous two messages are not clear enough so I delete them. Sorry for the noise. :-( When unpacking a pascal string, you cannot simply specify a p format character otherwise struct calculate a wrong size of the format. That's why unpack fails. When count

[issue23816] struct.unpack returns null pascal strings - [first] bug report

2017-05-03 Thread Xiang Zhang
Changes by Xiang Zhang : -- Removed message: http://bugs.python.org/msg292959 ___ Python tracker ___

[issue23816] struct.unpack returns null pascal strings - [first] bug report

2017-05-03 Thread Xiang Zhang
Changes by Xiang Zhang : -- Removed message: http://bugs.python.org/msg292958 ___ Python tracker ___

[issue23816] struct.unpack returns null pascal strings - [first] bug report

2017-05-03 Thread Xiang Zhang
Xiang Zhang added the comment: Note in the doc: Note that for unpack(), the 'p' format character consumes count bytes I think this means you still need to specify the repeat count for unpacking 'p'. -- ___ Python tracker

[issue23816] struct.unpack returns null pascal strings - [first] bug report

2017-05-03 Thread Xiang Zhang
Xiang Zhang added the comment: Hmm, code->size is determined by repeat count at initilization stage so I don't understand why it should be updated in s_unpack_internal to 255. And the repro script works well for me. -- nosy: +xiang.zhang resolution: -> not a bug stage: -> resolved

[issue23816] struct.unpack returns null pascal strings - [first] bug report

2015-03-30 Thread Jon Heiner
New submission from Jon Heiner: I believe there is an issue with the _struct.c handling of Pascal style strings. In the _struct.c:s_unpack_internal() function (reading 2.7.6 and 2.7.9 source from tgz ball), the size parameter 'n' is clamped to code-size-1. As far as I can tell, 'n' is set to