Program works on screen but not on disk...

[Blankdraw]

I have a program below that runs fine. It accesses a datafile for
random-access transfers. Supposedly, it does this by accessing the
file in binary mode. I do not understand how it does this without
any such parameter. The lower-level open() functions use a |O_BINARY
or some such specification.
Q: Can someone tell me how I can use/modify this program and be left
with a datafile that has sensible (read: ASCII) data in it???



/* RWARRAY.C - Loads and saves an array from a database file on-disk
*/

#include <stdio.h>
#include <string.h>
#include <process.h>

#define ITEMS 7

int main()
{
char filename[85];
int count;
FILE *fileptr;
int data[ITEMS] = {8, 57, 5, 309, 33, 87, 55};
int data2[ITEMS];

printf("\nEnter filename: ");
gets(filename);

/* write array to file */
if ((fileptr = fopen(filename, "w")) == NULL)
{
printf("Error: Cannot open your pants\n");
exit(0);
}

printf("Writing data items to file %s....\n", filename);

fwrite(data, sizeof(data), 1, fileptr);
fclose(fileptr);

/* Read file into array */
if ((fileptr = fopen(filename, "r")) == NULL)
{
printf("Error: Cannot open your pants\n");
exit(0);
}

printf("Reading data items from file....\n");
fread(&data2, sizeof(data), 1, fileptr);


fclose(fileptr);
printf("The elements of the array are: \n");
for (count = 0; count < ITEMS; count++)
{
printf("Element %d is %d\n", count, data2[count]);
}

return 0;
}

 

[Jens.Toerring]

I have a program below that runs fine. It accesses a datafile for
random-access transfers. Supposedly, it does this by accessing the
file in binary mode. I do not understand how it does this without
any such parameter. The lower-level open() functions use a |O_BINARY
or some such specification.

Binary or non-binary mode doesn't make any difference when you use
fwrite() and fread(), it is only relevant (on some systems) when
using fprintf() and fscanf() (mostly about how the '\n' character
is interpreted).

Q: Can someone tell me how I can use/modify this program and be left
with a datafile that has sensible (read: ASCII) data in it???

/* RWARRAY.C - Loads and saves an array from a database file on-disk
*/

#include <stdio.h>
#include <string.h>

Not requred for your program.

#include <process.h>

What is process.h? That's not a standard header file and there's
nothing in your program that would make it necessary to include
the file.

#define ITEMS 7

int main()
{
char filename[85];
int count;
FILE *fileptr;
int data[ITEMS] = {8, 57, 5, 309, 33, 87, 55};
int data2[ITEMS];

printf("\nEnter filename: ");
gets(filename);

Never, ever use gets(). There's no way you can make sure that the
input will fit into the buffer you pass to gets(). Use fgets()
instead.

/* write array to file */
if ((fileptr = fopen(filename, "w")) == NULL)
{
printf("Error: Cannot open your pants\n");
exit(0);
}

printf("Writing data items to file %s....\n", filename);

fwrite(data, sizeof(data), 1, fileptr);

If you want to write out everything in ASCII you need the fprintf()
function, i.e.

for ( i = 0; i < ITEMS; i++ )
fprintf( fileptr, "%d\n", data[ i ] );

fclose(fileptr);

/* Read file into array */
if ((fileptr = fopen(filename, "r")) == NULL)
{
printf("Error: Cannot open your pants\n");
exit(0);
}

printf("Reading data items from file....\n");
fread(&data2, sizeof(data), 1, fileptr);

And, if you have written out the data in ASCII, you would use fscanf():

for ( i = 0; i < ITEMS; i++ )
if ( fscanf( fileptr, "%d", data2 + i ) != 1 )
{
fprintf( stderr, "Input file is broken.\n" );
fclose( fileptr );
exit( EXIT_FAILURE );
}

fclose(fileptr);
printf("The elements of the array are: \n");
for (count = 0; count < ITEMS; count++)
{
printf("Element %d is %d\n", count, data2[count]);
}

return 0;
}

Regards, Jens
--
_ _____ _____
| ||_ _||_ _| (e-mail address removed)-berlin.de
_ | | | | | |
| |_| | | | | | http://www.physik.fu-berlin.de/~toerring
\___/ens|_|homs|_|oerring

 

[Gordon Burditt]

I have a program below that runs fine. It accesses a datafile for
The second argument of fopen() may be, for example, "r" vs. "rb" for
text vs. binary mode.

Binary or non-binary mode doesn't make any difference when you use
fwrite() and fread(), it is only relevant (on some systems) when
using fprintf() and fscanf() (mostly about how the '\n' character
is interpreted).

The difference between text and binary mode affects how the '\n'
character is interpreted, *REGARDLESS* of whether you use fwrite()
or fprintf().

Assuming that string points at a string (no embedded \0 characters)
that contains newline(s), and foo is a stream opened for output,
you should get the same result in the file from:

char *string;
FILE *foo;

fprintf(foo, "%s", string);
OR
fwrite(string, 1, strlen(string), foo)


What matters (if there is any difference at all: on some systems
there isn't) is how the file was opened.

Gordon L. Burditt

 

[Irrwahn Grausewitz]

(e-mail address removed) (Gordon Burditt) wrote in
<[email protected]>:

The difference between text and binary mode affects how the '\n'
character is interpreted, *REGARDLESS* of whether you use fwrite()
or fprintf().

Assuming that string points at a string (no embedded \0 characters)
that contains newline(s), and foo is a stream opened for output,
you should get the same result in the file from:

char *string;
FILE *foo;

fprintf(foo, "%s", string);
OR
fwrite(string, 1, strlen(string), foo)


What matters (if there is any difference at all: on some systems
there isn't) is how the file was opened.

Question: is it good or bad practice if I fopen() text-files
in binary mode to avoid possible automatic line delimiter
translation (CR, LF, CRLF, ...) on different OSs and leave
the control over line delimiting to my program?

Irrwahn

 

[Gordon Burditt]

Question: is it good or bad practice if I fopen() text-files
in binary mode to avoid possible automatic line delimiter
translation (CR, LF, CRLF, ...) on different OSs and leave
the control over line delimiting to my program?

If they really *ARE* text files, treat them as such. Among other
things, FTP in ASCII mode should automatically translate line
delimiters from one format to another (using a fixed standard for
traffic on the net, neither system needs to know what the OTHER
system uses). Also, you're going to have problems with your binary
so-called text files if you ever expect to manipulate them with
standard tools like a text editor or print spooler.

If you need to share the files among machines with different OSs
and line-ending conventions via, say, NFS, then maybe you should
use a portable binary format. (Portable in this sense means laying
down format rules like: NO MULTIBYTE INTEGERS (or specify the byte
ordering and size), NO FLOATING POINT (or specify the exact format
used), line endings (if you even have lines) are THIS, etc.).

Gordon L. Burditt