program can't read its own data files 
Author Message
 program can't read its own data files

Hi.
I've got a suite of programs, one component of which translates an ASCII
data file into a binary data file. Now, under DOS and OS/2, the programs
can read their own data files. However, when I compile the software under
SunOS 4.1.3, the programs compile, and the ASCII-to-binary converter runs
without errors, but the other programs cannot read the numbers stored in
the binary data file. The text in the binary file comes out just fine,
but the integer, float, and double values come out garbage. I've taken
great pains to ensure that the sizes (in bytes) of the various data types
are the same across platforms. What could the problem be?

--
                                -- Joe Heafner

Joe Heafner, Astronomy and Physics Instructor. Work:(704)327-7000 x246
my surname with my first initial at mercury dot interpath dot com
<URL: http://www.*-*-*.com/ ~heafnerj/>



Sat, 29 Jul 2000 03:00:00 GMT  
 program can't read its own data files



Quote:
>Hi.
>I've got a suite of programs, one component of which translates an ASCII
>data file into a binary data file. Now, under DOS and OS/2, the programs
>can read their own data files. However, when I compile the software under
>SunOS 4.1.3, the programs compile, and the ASCII-to-binary converter runs
>without errors, but the other programs cannot read the numbers stored in
>the binary data file. The text in the binary file comes out just fine,
>but the integer, float, and double values come out garbage. I've taken
>great pains to ensure that the sizes (in bytes) of the various data types
>are the same across platforms. What could the problem be?

Sounds like a byte ordering problem. Size is not the only way that C types
can differ between implementations. On DOS, and other OSes running on an
80x86 processor, numeric types are arranged in memory with the least
significant byte first. On other processors, including the sparc or m68k
which you are running SunOS on, they are arranged with the most significant
byte first. So if you write a long int with a value of 1 to a binary file
under DOS, the binary value 0000000000000000000001 is written as

00000001 00000000 00000000 00000000

While under SunOS, it will be written as

00000000 00000000 00000000 00000001

In the comp.lang.c FAQ there are some suggestions on how to work around this
problem. The FAQ can be found in the same place as all the other usenet FAQs:
on the ftp site rtfm.mit.edu in /pub/usenet.
--
Alan Curry
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS d? s++:-- a-- C++ UB+++L++++ P+ L+++>++++ E--- W-- N++ o K? w--- O? M--
V? PS+ PE+ Y+ PGP-(--) t* 5++ X+++ R- tv++ b-- DI- D++ G+++ !e h! r-->+++ y?
------END GEEK CODE BLOCK------



Sat, 29 Jul 2000 03:00:00 GMT  
 program can't read its own data files


: Hi.
: I've got a suite of programs, one component of which translates an ASCII
: data file into a binary data file. Now, under DOS and OS/2, the programs
: can read their own data files. However, when I compile the software under
: SunOS 4.1.3, the programs compile, and the ASCII-to-binary converter runs
: without errors, but the other programs cannot read the numbers stored in
: the binary data file. The text in the binary file comes out just fine,
: but the integer, float, and double values come out garbage. I've taken
: great pains to ensure that the sizes (in bytes) of the various data types
: are the same across platforms. What could the problem be?

There are three common ways to order bytes in eg: a 32-bit int.  Reading
from low to high memory they are:

1 2 3 4 - Intel
4 3 2 1 - Motorola
3 4 1 2 - VAX (or is it 2 1 4 3 ?)

Anyway, chances are that's part of your problem.  Another snag may
be that even when the byte ordering is corrected, the floating point
layouts are incompatible.

Will



Sat, 29 Jul 2000 03:00:00 GMT  
 program can't read its own data files

Can you write each byte one at a time?

(I don't read FAQs.  That's what nice, helpful people are for.  :)



Sat, 29 Jul 2000 03:00:00 GMT  
 program can't read its own data files



Quote:
>Hi.
>I've got a suite of programs, one component of which translates an ASCII
>data file into a binary data file. Now, under DOS and OS/2, the programs
>can read their own data files. However, when I compile the software under
>SunOS 4.1.3, the programs compile, and the ASCII-to-binary converter runs
>without errors, but the other programs cannot read the numbers stored in
>the binary data file. The text in the binary file comes out just fine,
>but the integer, float, and double values come out garbage. I've taken
>great pains to ensure that the sizes (in bytes) of the various data types
>are the same across platforms. What could the problem be?

It sounds like the two components are not matched in their portability.  For
example, the ASCII to binary converter might be written such that it creates a
portable file format; when run on dis-similar platforms such as the Sun or
MS-DOS, it produces the same binary file nevertheless---whereas the other
parts of the program use non-portable techniques to read the data.
Or vice versa.

Scour your code in search of constructs that depend on machine-specific
representation of data, such as byte ordering, etc.

Quote:
>--
>                                -- Joe Heafner

>Joe Heafner, Astronomy and Physics Instructor. Work:(704)327-7000 x246
>my surname with my first initial at mercury dot interpath dot com
><URL:http://mercury.interpath.com/~heafnerj/>



Sat, 29 Jul 2000 03:00:00 GMT  
 program can't read its own data files


Quote:

>(I don't read FAQs.  That's what nice, helpful people are for.  :)

That giant *plonk*ing sound you hear is you, being ignored, by everybody.

--
Alan Curry
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS d? s++:-- a-- C++ UB+++L++++ P+ L+++>++++ E--- W-- N++ o K? w--- O? M--
V? PS+ PE+ Y+ PGP-(--) t* 5++ X+++ R- tv++ b-- DI- D++ G+++ !e h! r-->+++ y?
------END GEEK CODE BLOCK------



Sat, 29 Jul 2000 03:00:00 GMT  
 program can't read its own data files

: Sounds like a byte ordering problem. Size is not the only way that C types
: can differ between implementations. On DOS, and other OSes running on an
: 80x86 processor, numeric types are arranged in memory with the least
: significant byte first. On other processors, including the sparc or m68k
: which you are running SunOS on, they are arranged with the most significant
: byte first. So if you write a long int with a value of 1 to a binary file
: under DOS, the binary value 0000000000000000000001 is written as

: 00000001 00000000 00000000 00000000

: While under SunOS, it will be written as

: 00000000 00000000 00000000 00000001

I'm aware of the big-endian/little-endian problem, and I even have a
program that comverts one format to the other so this is not an issue. My
problem is that the SunOS-compiled program cannot correctly read data
files created with Sun-OS compiled software! This is not a cross-platform
problem...I'm trying to get everything on SunOS 4.1.3. I just don't see
why a program compiles under SunOS can't read its own binary data files
which were also created under SunOS.

--
                                -- Joe Heafner

Joe Heafner, Astronomy and Physics Instructor. Work:(704)327-7000 x246
my surname with my first initial at mercury dot interpath dot com
<URL:http://mercury.interpath.com/~heafnerj/>



Sat, 29 Jul 2000 03:00:00 GMT  
 program can't read its own data files



Quote:
>Hi.
>I've got a suite of programs, one component of which translates an ASCII
>data file into a binary data file. Now, under DOS and OS/2, the programs
>can read their own data files. However, when I compile the software under
>SunOS 4.1.3, the programs compile, and the ASCII-to-binary converter runs
>without errors, but the other programs cannot read the numbers stored in
>the binary data file.

Are you referring to data moved between platforms or a program trying to
read output generated on the same platform. If the former you will encounter
representation issues such as byte ordering. If the latter then most likey
there is simply a bug in your program. Without seeing any code it would be
rather difficult to say what that might be.

--
-----------------------------------------


-----------------------------------------



Sat, 29 Jul 2000 03:00:00 GMT  
 program can't read its own data files


Quote:

> I'm aware of the big-endian/little-endian problem, and I even have a
> program that comverts one format to the other so this is not an issue. My
> problem is that the SunOS-compiled program cannot correctly read data
> files created with Sun-OS compiled software! This is not a cross-platform
> problem...I'm trying to get everything on SunOS 4.1.3. I just don't see
> why a program compiles under SunOS can't read its own binary data files
> which were also created under SunOS.

> --
>                                 -- Joe Heafner

Is it possible that your compiler switches have been set differently
between the program that generates and the program that reads data.
For instance, you may have a structure padding/crunching switch which
will help optimise your program for speed (aligning data on easy to
find boundaries, and leaving holes in the middle of structures), or
for data size (pushing structure elements closer together with less
holes, but in a less ideal arrangement for the processor to access).
Using fwrite() to write structures will write the structure including
holes, which may be in different places when you come to fread() the
structure in the other program if compiled with different switches.
More in the FAQ - 2.11, 2.12, 20.5.

Simon.



Sat, 29 Jul 2000 03:00:00 GMT  
 program can't read its own data files


[...]
: I'm aware of the big-endian/little-endian problem, and I even have a
: program that comverts one format to the other so this is not an issue. My
: problem is that the SunOS-compiled program cannot correctly read data
: files created with Sun-OS compiled software! This is not a cross-platform
: problem...I'm trying to get everything on SunOS 4.1.3. I just don't see
: why a program compiles under SunOS can't read its own binary data files
: which were also created under SunOS.

Because you are writing text files, and reading binary files?  You'll
have to post some reader/writer code to get a clear answer on this one.

Will



Sat, 29 Jul 2000 03:00:00 GMT  
 program can't read its own data files


Quote:

>I'm aware of the big-endian/little-endian problem, and I even have a
>program that comverts one format to the other so this is not an issue. My
>problem is that the SunOS-compiled program cannot correctly read data
>files created with Sun-OS compiled software! This is not a cross-platform
>problem...I'm trying to get everything on SunOS 4.1.3. I just don't see
>why a program compiles under SunOS can't read its own binary data files
>which were also created under SunOS.

We cannot solve this problem without you posting some source.
It seems like a plain error in the pgm.
(f)read and (f)write on a C "basic type" or "composite" type should
be compatible. Either your pgm's aligment is wrong ( often fixed silently
by OSses) , or you are writing/reading pointers to disk.
Could you produce a minimal source code example demonstrating the
problem ?
Quote:
>--
>                                -- Joe Heafner

>Joe Heafner, Astronomy and Physics Instructor. Work:(704)327-7000 x246
>my surname with my first initial at mercury dot interpath dot com
><URL:http://mercury.interpath.com/~heafnerj/>

NOTE: there is no spam-blocker in your reply-address !!

--
Happy hacking,

Adriaan van Kessel.
Ingres DBA, C/Unix hacker

(remove NotThere. from the above address)
*** Nederlandstalige zachtwaar is een pijn in de aars ***



Sat, 29 Jul 2000 03:00:00 GMT  
 program can't read its own data files


Quote:

>Can you write each byte one at a time?

>(I don't read FAQs.  That's what nice, helpful people are for.  :)

Nice, helpful people write FAQ lists.

FAQs are like a high speed cache. If you ask a question that is in the
FAQ list, you have to wait for a response. If you look it up in the FAQ,
you get an instant response. What's worse, if you ask a FAQ, the response
you get might simply tell you to go to the FAQ.

Any time you ask a question in the newsgroup, you also have to read
many responses, some of which will invariably be wrong. The FAQ list
answer is shorter and is known to be accurate.

Statistically, it is more efficient to use the FAQ than to go immediately to
the slower medium, which means that you are simply being foolish.



Sat, 29 Jul 2000 03:00:00 GMT  
 program can't read its own data files

How am I given any guarantee that the FAQ will have the answer I'm looking
for?  What if I just waste my time looking through it?  I'm almost always sure
to get a response from a benevolent human who happens to be skimming through
the group.



Sat, 29 Jul 2000 03:00:00 GMT  
 program can't read its own data files


|> How am I given any guarantee that the FAQ will have the answer I'm
|> looking for?  What if I just waste my time looking through it?  I'm
|> almost always sure to get a response from a benevolent human who
|> happens to be skimming through the group.

Aha.  So instead of *you* wasting *your* precious time reading
well-established, long-scrutinized, and informative documents, with of
course the ever-present danger that you might actually learn something
useful for yourself, you believe that it is the time of the newsgroup
*participants* that should be wasted, answering a question that may
have been asked countless times before (or at least enough times to
warrant inclusion in a FAQ list.)  Interesting, to say the least.

I was going to point out that reading a newsgroup's FAQ before posting
a question is 1) common courtesy to everyone 2) longstanding Usenet
etiquette and 3) an effective means of reducing bandwidth usage and
increasing signal-to-noise ratio.  However, in light of the brilliant
defense that you have presented, I fear the argument would be useless.

Small wonder that Usenet has essentially gone to hell.

--
Chris Engebretson - Raytheon STX Corporation | Ph#: (605)594-6829
USGS EROS Data Center, Sioux Falls, SD 57198 | Fax: (605)594-6940

Opinions are not those of  Raytheon Systems Company  or the USGS.



Sat, 29 Jul 2000 03:00:00 GMT  
 program can't read its own data files

Quote:

> Can you write each byte one at a time?

Each byte of what one at a time where? (At a guess, I'd say that, using
fwrite() you could, but without context it's hard to tell.)

Quote:
> (I don't read FAQs.  That's what nice, helpful people are for.  :)

If this group were interested in answering the same question over and over,
would the FAQ -exist-? Learn some netiquette. Go read the FAQ.

--
Attempting to write in a hybrid which can be compiled by either a C compiler
or a C++ compiler produces a compromise language which combines the drawbacks
of both with the advantages of neither.



Sat, 29 Jul 2000 03:00:00 GMT  
 
 [ 25 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Can't Read Dbase data file from C program [HELP]

2. reading data file from C program

3. reading fortran data file from C program

4. Help with compiling a "canned" program

5. how to read data seperated by ','

6. Pointing to memory that the program itself doens't own

7. C program that views it's own source

8. geting program's own name and path

9. I'd like to use own DLL made from C functions in a VC program

10. Making a view own it's own DC in MFC

11. Beginner [Q] Using Canned File Open/Save dialog

12. Reading file..Saving data in new file...

 

 
Powered by phpBB® Forum Software