From: SourceForge.net <no...@so...> - 2009-05-07 18:51:42
|
Bugs item #2788582, was opened at 2009-05-07 14:51 Message generated for change (Tracker Item Submitted) made by dgp You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2788582&group_id=10894 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 12. ByteArray Object Group: development: 8.6b1.1 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Don Porter (dgp) Assigned to: Donal K. Fellows (dkf) Summary: [binary] ugly formatSpec parsing Initial Comment: The formatSpec parser for [binary format|scan] uses strtoul() to parser the count part, but then stores in an int. This yields ugly, and platform dependent results: On 32-bit system: % binary scan \x41 a0 a 1 % set a % binary scan \x41 a1 b 1 % set b A % binary scan \x41 a2 c 0 % binary scan \x41 a[expr 0x7fffffff] c 0 % binary scan \x41 a[expr 0x80000000] c 1 % set c % binary scan \x41 a[expr 0x80000001] d 1 % set d % binary scan \x41 a[expr 0xfffffffd] e 1 % set e % binary scan \x41 a[expr 0xfffffffe] f; # BINARY_NOCOUNT 1 % set f A % binary scan \x41 a[expr 0xffffffff] g; # BINARY_ALL 1 % set g A % binary scan \x41 a[expr 0x100000000] h 1 % set h A % binary scan \x41 a[expr 0x100000001] i 1 % set i A % binary scan \x41 a[expr 0x100000002] j 1 % set j A On 64-bit system: % binary scan \x41 a0 a 1 % set a % binary scan \x41 a1 b 1 % set b A % binary scan \x41 a2 c 0 % binary scan \x41 a[expr 0x7fffffff] c 0 % binary scan \x41 a[expr 0x80000000] c 1 % set c % binary scan \x41 a[expr 0x80000001] d 1 % set d % binary scan \x41 a[expr 0xfffffffd] e 1 % set e % binary scan \x41 a[expr 0xfffffffe] f; # BINARY_NOCOUNT 1 % set f A % binary scan \x41 a[expr 0xffffffff] g; # BINARY_ALL 1 % set g A % binary scan \x41 a[expr 0x100000000] h 1 % set h % binary scan \x41 a[expr 0x100000001] i 1 % set i A % binary scan \x41 a[expr 0x100000002] j 0 This has always been ugly and nonportable. Seems even more so now that bignums are the norm in many places. Good news is it's unlikely programs get here on purpose, and those that were intentionally trying to parse such long bytearrays are about to either run out of memory or overrun Tcl's limits on value storage anyway. Reporting just to get it on the record. Also someone might want to look closer if there are cases which could lead to a crash. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=2788582&group_id=10894 |