write a binary file?

[cylin]

Dear all,

I open a binary file and want to write 0x00040700 to this file.
how can I set write buffer?
---------------------------------------------------
typedef unsigned char UCHAR;
int iFD=open(szFileName,O_CREAT|O_BINARY|O_TRUNC|O_WRO NLY,S_IREAD|S_IWRITE);
UCHAR buffer[5]; //???????????
write(iFD,buffer,5);
---------------------------------------------------

Thanks.

Regards,
cylin.

[Richard Bos]

"cylin" <cy***@avant.com.tw> wrote:

I open a binary file and want to write 0x00040700 to this file.
how can I set write buffer?
Not like this, in ISO C. What you've got is system-specific, either
POSIX or not-quite-POSIX-M$.
typedef unsigned char UCHAR;
Yeugh.
int iFD=open(szFileName,O_CREAT|O_BINARY|O_TRUNC|O_WRO NLY,S_IREAD|S_IWRITE);
Hungarian notation. Double yeugh. HN used to declare what everybody
reading your code, including the compiler, already knows: the types of
your identifiers. Triple yeugh, and go to the self-confidence shop and
buy some.
UCHAR buffer[5]; //???????????
Mixing declarations and executable statements is legal in C99 and C++,
but not in C89. Beware the snark.
write(iFD,buffer,5);

No idea how to solve this using your low-level, unlikely-to-port
functions. In _real_ C, you'd do something like this:

#include <stdio.h>

unsigned char buf[5];
FILE *outfile;

if (!(outfile=fopen(filename, "wb")) {
puts("This is the place where you'd handle a file open error.");
} else {
if (fwrite(buf, sizeof *buf, sizeof buf/sizeof *buf, outfile) !=
sizeof buf/sizeof *buf) {
puts("Handle a write error here.");
}
/* Or, since you know that buf is an unsigned char array and
therefore sizeof *buf must be 1:
fwrite(buffer, 1, sizeof buf, outfile);
*/
fclose(outfile);
/* For critical applications, you should even check the return value
of fclose(), but I rarely do this. */
}

Issa dat si'ple.

Richard

[Irrwahn Grausewitz]

"cylin" <cy***@avant.com.tw> wrote:

I open a binary file and want to write 0x00040700 to this file.
how can I set write buffer?
Do you want to
[1] write bytes in exactly the order you gave above (portable
result), or
[2] write an unsigned long value to the file (non-portable
result)?
---------------------------------------------------
typedef unsigned char UCHAR;
int iFD=open(szFileName,O_CREAT|O_BINARY|O_TRUNC|O_WRO NLY,S_IREAD|S_IWRITE);
UCHAR buffer[5]; //???????????
write(iFD,buffer,5);
---------------------------------------------------

Neither open nor write are standard C functions.
What you want is something like:

#include <stdio.h>
#include <stdlib.h>

int main( void )
{
unsigned char buf[] = { 0x00, 0x04, 0x07, 0x00 };
unsigned long ul = 0x00040700UL;
FILE *fp;

if ( ( fp = fopen( "foo", "wb" ) ) != NULL )
{
fwrite( buf, sizeof buf, 1, fp ); /* [1] */
fwrite( &ul, sizeof ul, 1, fp ); /* [2] */
fclose( fp );
return EXIT_SUCCESS;
}
return EXIT_FAILURE;
}

HTH
Regards
--
Irrwahn Grausewitz (ir*******@freenet.de)
welcome to clc: http://www.ungerhu.com/jxh/clc.welcome.txt
clc faq-list : http://www.faqs.org/faqs/C-faq/faq/
clc OT guide : http://benpfaff.org/writings/clc/off-topic.html

[Martin Dickopp]

"cylin" <cy***@avant.com.tw> writes:

Dear all,

I open a binary file and want to write 0x00040700 to this file.
how can I set write buffer?
Use shifts and mask operations (bitwise AND) to extract the individual
bytes. The details depend on the byte order in which you want to write
to the file.
---------------------------------------------------
typedef unsigned char UCHAR;
int iFD=open(szFileName,O_CREAT|O_BINARY|O_TRUNC|O_WRO NLY,S_IREAD|S_IWRITE);
No such function in standard C. Use `fopen'.
UCHAR buffer[5]; //???????????
write(iFD,buffer,5);
No such function in standard C. Use `fwrite'.
---------------------------------------------------

This program should give you same hints:
#include <stdlib.h>
#include <stdio.h>

int main (void)
{
const unsigned long value = 0x00040700;
unsigned char buffer [4];
FILE *f;

/* This as known as "big-endian" byte order. */
buffer [0] = value >> 24;
buffer [1] = (value >> 16) & 0xFF;
buffer [2] = (value >> 8) & 0xFF;
buffer [3] = value & 0xFF;

f = fopen ("testfile", "wb");
if (f != NULL)
{
if (fwrite (buffer, sizeof *buffer, sizeof buffer, f) < sizeof buffer
|| fclose (f) == EOF)
{
fputs ("Error writing to testfile.\n", stderr);
return EXIT_FAILURE;
}
}
else
{
fputs ("Cannot open testfile for writing.\n", stderr);
return EXIT_FAILURE;
}

return 0;
}
Martin
--
,--. Martin Dickopp, Dresden, Germany ,= ,-_-. =.
/ ,- ) http://www.zero-based.org/ ((_/)o o(\_))
\ `-' `-'(. .)`-'
`-. Debian, a variant of the GNU operating system. \_/

[Martin Dickopp]

rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:

if (fwrite(buf, sizeof *buf, sizeof buf/sizeof *buf, outfile) !=
sizeof buf/sizeof *buf) {
puts("Handle a write error here.");
}
fclose(outfile);
/* For critical applications, you should even check the return value
of fclose(), but I rarely do this. */

Why do you check the return value of `fwrite' then? Most operating
systems don't write immediately to the underlying device when `fwrite'
is called, but have some buffering mechanism. Therefore, an error is
far more likely to show up in `fclose' than in `fwrite' on such systems.

Martin
--
,--. Martin Dickopp, Dresden, Germany ,= ,-_-. =.
/ ,- ) http://www.zero-based.org/ ((_/)o o(\_))
\ `-' `-'(. .)`-'
`-. Debian, a variant of the GNU operating system. \_/

[Martin Dickopp]

Martin Dickopp <ex****************@zero-based.org> writes:

if (fwrite (buffer, sizeof *buffer, sizeof buffer, f) < sizeof buffer

That's inconsistent. Make that:

if (fwrite (buffer, 1, sizeof buffer, f) < sizeof buffer

Martin
--
,--. Martin Dickopp, Dresden, Germany ,= ,-_-. =.
/ ,- ) http://www.zero-based.org/ ((_/)o o(\_))
\ `-' `-'(. .)`-'
`-. Debian, a variant of the GNU operating system. \_/

[cylin]

Great. Thank all.

I use low-level I/O functions because I want to the speed faster than
stardard I/O functions.
Can't low-level I/O functions do this case?

Regards,
cylin.

[Martin Dickopp]

"cylin" <cy***@avant.com.tw> writes:

I use low-level I/O functions because I want to the speed faster than
stardard I/O functions.
Can't low-level I/O functions do this case?

They can, but they're off-topic in comp.lang.c, which is only about
standard C.

<OT>
They are also harder to use correctly. Note, e.g., that it is not
necessarily an indication of error if the POSIX function `write' writes
less bytes than requested.
</OT>

Martin
--
,--. Martin Dickopp, Dresden, Germany ,= ,-_-. =.
/ ,- ) http://www.zero-based.org/ ((_/)o o(\_))
\ `-' `-'(. .)`-'
`-. Debian, a variant of the GNU operating system. \_/

[Joona I Palaste]

cylin <cy***@avant.com.tw> scribbled the following:

Great. Thank all. I use low-level I/O functions because I want to the speed faster than
stardard I/O functions.
Can't low-level I/O functions do this case?

First of all, your "low-level I/O functions" might not even be available
on all platforms. Second of all, there is no guarantee they will be any
faster than standard I/O functions. They could even be slower.

--
/-- Joona Palaste (pa*****@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"C++ looks like line noise."
- Fred L. Baube III

[CBFalconer]

Martin Dickopp wrote:

"cylin" <cy***@avant.com.tw> writes:

I open a binary file and want to write 0x00040700 to this file.
how can I set write buffer?
Use shifts and mask operations (bitwise AND) to extract the
individual bytes. The details depend on the byte order in which
you want to write to the file.

.... snip ...
This program should give you same hints:

#include <stdlib.h>
#include <stdio.h>

int main (void)
{
const unsigned long value = 0x00040700;
unsigned char buffer [4];
FILE *f;

/* This as known as "big-endian" byte order. */
buffer [0] = value >> 24;
buffer [1] = (value >> 16) & 0xFF;
buffer [2] = (value >> 8) & 0xFF;
buffer [3] = value & 0xFF;

f = fopen ("testfile", "wb");
if (f != NULL)
{
if (fwrite (buffer, sizeof *buffer, sizeof buffer, f) < sizeof buffer
|| fclose (f) == EOF)
{
fputs ("Error writing to testfile.\n", stderr);
return EXIT_FAILURE;
}
}
else
{
fputs ("Cannot open testfile for writing.\n", stderr);
return EXIT_FAILURE;
}

return 0;
}

There is nothing wrong with your code above, and it illustrates
most things admirably, I suggest that the use of embedded tests
will facilitate a clearer order of things. This is a style
question, not a flame, and just a suggestion. My version follows:

#include <stdlib.h>
#include <stdio.h>

int main (void)
{
const unsigned long value = 0x00040700;
unsigned char buffer [4];
FILE *f;

/* This as known as "big-endian" byte order. */
buffer [0] = value >> 24;
buffer [1] = (value >> 16) & 0xFF;
buffer [2] = (value >> 8) & 0xFF;
buffer [3] = value & 0xFF;

if (!(f = fopen("testfile", "wb"))) {
fputs("Cannot open testfile for writing.\n", stderr);
}
else if ((fwrite(buffer, sizeof *buffer, sizeof buffer, f)
< sizeof buffer)
|| (EOF == fclose(f))) {
fputs("Error writing to testfile.\n", stderr);
}
else {
return 0;
}
return EXIT_FAILURE;
}

although the neophyte is still going to have trouble comprehending
the combined fwrite/fclose failure test. I have also added the
odd extraneous parentheses to make the meanings explicit.

This now follows the pattern "if phasefails exit else nextphase".

--
Some useful references:
<http://www.ungerhu.com/jxh/clc.welcome.txt>
<http://www.eskimo.com/~scs/C-faq/top.html>
<http://benpfaff.org/writings/clc/off-topic.html>
<http://anubis.dkuug.dk/jtc1/sc22/wg14/www/docs/n869/> (C99)

[Dan Pop]

In <40*****************@news.individual.net> rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:

fclose(outfile);
/* For critical applications, you should even check the return value
of fclose(), but I rarely do this. */

Bad idea: most of the things that can go wrong (after fopen succeeded)
happen at fclose time.

To optimise the error checking, when I generate an output file in a
compact succession of operations, I only check fclose and a fflush call
immediately preceding it (which is probably redundant).

OTOH, long running programs that generate output constantly (e.g. one
printf call per main loop iteration) should check each output call,
even if it's on stdout (that gets redirected to a file when the program
is run in non-interactive mode). No point in continuing the execution
if the program can no longer generate output.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Dan Pop]

In <c6************@ID-230325.news.uni-berlin.de> "cylin" <cy***@avant.com.tw> writes:

I use low-level I/O functions because I want to the speed faster than
stardard I/O functions.
Where did you get this silly idea from? The low-level I/O functions have
a relatively high cost and the stardard I/O functions are designed to
minimise the number of low-level I/O function calls, by doing some local
buffering.

As a result of this, it is trivially easy for the ignorant to slow down
his I/O by one order of magnitude, while an expert can only speed up his
I/O by a small percentage, by using the low-level functions instead of the
standard ones and removing one level of buffering, when and where it is
not necessary.
Can't low-level I/O functions do this case?

Why bother?

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[kal]

> Use shifts and mask operations (bitwise AND) to extract the individual

bytes. The details depend on the byte order in which you want to write
to the file.

IMHO one is better off using "htnl()." This will work fine so long as
all you are writing are 32 bit values.

[Christopher Benson-Manica]

kal <k_*****@yahoo.com> spoke thus:

IMHO one is better off using "htnl()." This will work fine so long as
all you are writing are 32 bit values.

I suspect you meant htonl().

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.

[Martin Dickopp]

k_*****@yahoo.com (kal) writes:

Use shifts and mask operations (bitwise AND) to extract the individual
bytes. The details depend on the byte order in which you want to write
to the file.

IMHO one is better off using "htnl()."

Wheather such a non-standard method of doing things is preferable when a
standard method exists is certainly debatable.

Martin
--
,--. Martin Dickopp, Dresden, Germany ,= ,-_-. =.
/ ,- ) http://www.zero-based.org/ ((_/)o o(\_))
\ `-' `-'(. .)`-'
`-. Debian, a variant of the GNU operating system. \_/

[Richard Bos]

Martin Dickopp <ex****************@zero-based.org> wrote:

rl*@hoekstra-uitgeverij.nl (Richard Bos) writes:

if (fwrite(buf, sizeof *buf, sizeof buf/sizeof *buf, outfile) !=
sizeof buf/sizeof *buf) {
puts("Handle a write error here.");
}
fclose(outfile);
/* For critical applications, you should even check the return value
of fclose(), but I rarely do this. */

Why do you check the return value of `fwrite' then? Most operating
systems don't write immediately to the underlying device when `fwrite'
is called, but have some buffering mechanism. Therefore, an error is
far more likely to show up in `fclose' than in `fwrite' on such systems.

Good question. Guess I'm just too used to interactive output.

Richard

[Richard Bos]

Christopher Benson-Manica <at***@nospam.cyberspace.org> wrote:

kal <k_*****@yahoo.com> spoke thus:

IMHO one is better off using "htnl()." This will work fine so long as
all you are writing are 32 bit values.

I suspect you meant htonl().

And _I_ suspect that function is not ISO.

Richard

[Christopher Benson-Manica]

Richard Bos <rl*@hoekstra-uitgeverij.nl> spoke thus:

And _I_ suspect that function is not ISO.

Going off-topic doesn't have to mean making things up :)

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.

[kal]

Christopher Benson-Manica <at***@nospam.cyberspace.org> wrote

IMHO one is better off using "htnl()."

I suspect you meant htonl().

Yes, it is "htonl()." Thank you very much. It was my mistake.

Are there any equivalent functions in the standard C library?

Is there even the concept of byte ordering in C?

[Dan Pop]

In <a5**************************@posting.google.com > k_*****@yahoo.com (kal) writes:

Christopher Benson-Manica <at***@nospam.cyberspace.org> wrote

> IMHO one is better off using "htnl()."
I suspect you meant htonl().

Yes, it is "htonl()." Thank you very much. It was my mistake.

Are there any equivalent functions in the standard C library?

Nope.
Is there even the concept of byte ordering in C?

Nope. In theory the bits could be scattered all over the place, rather
than being nicely grouped in bytes, i.e. the physical representation of
a short could be:

b0 b7 b5 sign b4 b3 b1 b10 | b2 b14 b8 b9 b6 b12 b13 b12
---------------------------+----------------------------
first byte second byte

as long as all the operations generate the specified results (and unsigned
short replaces the sign bit by bit 15). Of course, this is not going
to happen in practice, but the standard is perfectly happy with it.
Some very popular (at the time) old architectures had glitches at the
byte ordering level (neither big endian nor little endian for 32-bit
integers) but they are gone now.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Keith Thompson]

k_*****@yahoo.com (kal) writes:

Christopher Benson-Manica <at***@nospam.cyberspace.org> wrote

IMHO one is better off using "htnl()." I suspect you meant htonl().

Yes, it is "htonl()." Thank you very much. It was my mistake.

Are there any equivalent functions in the standard C library?

Not really.
Is there even the concept of byte ordering in C?

Well, sort of. Any C object can be viewed as an array of bytes
(unsigned char), but the standard doesn't say much about what those
bytes are going to look like. For example:

#include <stdio.h>

int main(void)
{
unsigned int x = 0x12345678;
unsigned char *ptr = (unsigned char*)&x;
int i;

printf("x = 0x%x\n", x);
for (i = 0; i < sizeof x; i ++) {
printf(" 0x%x", (unsigned int)ptr[i]);
}
printf("\n");
return 0;
}

On one platform I just tried, the output is:

x = 0x12345678
0x12 0x34 0x56 0x78

On another, it's:

x = 0x12345678
0x78 0x56 0x34 0x12

but a valid implementation could produce:

x = 0x12345678
0x23 0x12 0x56 0x78

or any of a number of other possibilities.

But don't be afraid to use system-specific functions if they're
appropriate. If you need to use something like htonl(), chances are
your program is already doing plenty of stuff that's not directly
supported by the standard C library (htonl() is mostly used in
networking, and all networking support is system-specific). (Just
don't expect detailed advice about it in comp.lang.c.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"