| Ticket UUID: | 1809298 | |||
| Title: | binary scan / scan | |||
| Type: | Bug | Version: | obsolete: 8.4.16 | |
| Submitter: | nobody | Created on: | 2007-10-08 07:29:03 | |
| Subsystem: | 12. ByteArray Object | Assigned To: | dkf | |
| Priority: | 5 Medium | Severity: | ||
| Status: | Closed | Last Modified: | 2007-10-26 09:20:10 | |
| Resolution: | Works For Me | Closed By: | sf-robot | |
| Closed on: | 2007-10-26 02:20:10 | |||
| Description: |
I have a problem when I extract datas from a binary file named gshhs_f.b from a package located on this website : ftp://ftp.soest.hawaii.edu/pwessel/gshhs/gshhs_1.5.zip The use of C demo program from : ftp://ftp.soest.hawaii.edu/pwessel/gshhs/gshhs_1.8_src.zip and an hex edit with Xemacs show a value of byte number 35383703 to be B4 (hex), but when I read it from different ways (in tcl) the result is 7D. I use first a tcl script as the C demo program : it works fine until this byte. (file : cvrt2xdr.tcl). The line : 54 9853 2 112.353333 135.87...... must be 54 9908 2 .... (the second term is the offset of the next -55- data zone; you can see that is wrong ;output file : return_cvr2xdr) I create a test script (bug.tcl;output file : return_bug) to show the problem. My "uname -a" result is: Linux 2.6.12-31mdksmp #1 SMP Fri Mar 2 10:40:41 MST 2007 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ unknown GNU/Linux tcl is 8.4. I tested it on PC 32bits and I had the same results. 4 attached files (2 scripts and 2 output files) in a tar.gz file, the input file is on website (see beginning of text). thanks to answer me [email protected] | |||
| User Comments: |
sf-robot added on 2007-10-26 09:20:10:
Logged In: YES user_id=1312539 Originator: NO This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). dkf added on 2007-10-11 20:03:25: Logged In: YES user_id=79902 Originator: NO The 'b' flag is an 8.5 addition. Doing an [fconfigure $chan -translation binary] afterwards is precisely equivalent (that's what the 'b' flag causes to happen internally). avl42 added on 2007-10-11 19:07:38: Logged In: YES user_id=830354 Originator: NO If the input file is opened with [open ... r], then you only need to change that to [open ... rb], at least since 8.5... (not sure about 8.4.*) dkf added on 2007-10-08 17:33:31: Logged In: YES user_id=79902 Originator: NO At a guess, the problem is not using [fconfigure $channel -translation binary] before reading any data. Without that, we don't warrant that we'll handle binary data correctly at all. (The immediate problem is probably a disconnect between your system encoding and iso8859-1, but the right fix is to tell Tcl that the channel is dealing with binary data. Really.) nobody added on 2007-10-08 14:29:06: File Added - 248691: SCAN_PB.tar.gz | |||
Attachments:
- SCAN_PB.tar.gz [download] added by [email protected] on 2007-10-08 14:29:03. [details]