octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug: 2.1.xx can't read binary files generated from 2.0.16


From: John W. Eaton
Subject: bug: 2.1.xx can't read binary files generated from 2.0.16
Date: Mon, 20 Nov 2000 16:02:34 -0600

On 20-Nov-2000, =?iso-8859-1?Q?Jo=E3o?= Cardoso <address@hidden> wrote:

| the subject says everything:
| 
| from: GNU Octave, version 2.0.16 (alpha-suse-linux-gnu) -- a suse rpm
| package
| 
| octave:1> a=1;save -binary po a
| 
| bash-2.04$ od -x po
| 0000000 634f 6174 6576 312d 4c2d 0100 0000 6100
| 0000020 0000 0000 0100 0007 0000 0000 f000 003f
|                           ^
| 
| from GNU Octave, version 2.1.31 (i686-pc-linux-gnu) -- current CVS
| sources
| 
| octave:1> a=1;save -binary po a
| 
| address@hidden od -x po
| 0000000 634f 6174 6576 312d 4c2d 0100 0000 6100
| 0000020 0000 0000 0100 0009 0000 0000 f000 003f
|                           ^
| 
| octave:1> load "~jcard/po"
| error: load: trouble reading binary file `~jcard/po'
| 
| This also happens with binary files generated from previous versions of
| 2.1.xx, don't know which.

I think the trouble started after this change:

2000-06-29  James R. Van Zandt  <address@hidden>

        * data-conv.cc (read_doubles): Handle EIGHT_BYTE_INT cases.
        (write_doubles): Ditto.
        * data-conv.h: Ditto.
        (enum save_type): New values, LS_U_LONG and LS_LONG.

Here is a patch:

2000-11-20  John W. Eaton  <address@hidden>

        * data-conv.h (enum save_type): Move LS_U_LONG and LS_LONG to the
        end of the list, to be compatible with previous versions of Octave.


Index: data-conv.h
===================================================================
RCS file: /usr/local/cvsroot/octave/liboctave/data-conv.h,v
retrieving revision 1.7
diff -c -r1.7 data-conv.h
*** data-conv.h 2000/06/29 22:50:24     1.7
--- data-conv.h 2000/11/20 21:19:43
***************
*** 85,106 ****
    static data_type string_to_data_type (const std::string& s);
  };
  
  enum save_type
    {
!     LS_U_CHAR,
!     LS_U_SHORT,
!     LS_U_INT,
! #ifdef EIGHT_BYTE_INT
!     LS_U_LONG,
! #endif
!     LS_CHAR,
!     LS_SHORT,
!     LS_INT,
! #ifdef EIGHT_BYTE_INT
!     LS_LONG,
! #endif
!     LS_FLOAT,
!     LS_DOUBLE
    };
  
  extern void
--- 85,106 ----
    static data_type string_to_data_type (const std::string& s);
  };
  
+ // Add new entries to the end of this enum, otherwise Octave will not
+ // be able to read binary data files stored in Octave's binary data
+ // format that were created with previous versions of Octave.
+ 
  enum save_type
    {
!     LS_U_CHAR  = 0,
!     LS_U_SHORT = 1,
!     LS_U_INT   = 2,
!     LS_CHAR    = 3,
!     LS_SHORT   = 4,
!     LS_INT     = 5,
!     LS_FLOAT   = 6,
!     LS_DOUBLE  = 7,
!     LS_U_LONG  = 8,
!     LS_LONG    = 9
    };
  
  extern void


Unfortunately, this means that anyone who has been using the current
versions of Octave over the past 5 months or so and saving data in
Octave's binary format will have some trouble.  I'm not sure what I
can do about that.

Thanks for catching this problem.

jwe



reply via email to

[Prev in Thread] Current Thread [Next in Thread]