printig effort

[Bill Cunningham]

I have patched together a print routine for my oscillator program and
one problem after another. This will not complie. But it has fewer errors
than it did.

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

void
prn (double input)
{
FILE *fp;
double *inpt;
inpt = &input;
fopen ("data", "wt");
if ((fwrite (inpt, sizeof (size_t), 1, fp)) != EOF);
if ((fclose (fp)) != EOF);
}

int
main (int argc, char *argv[])
{
double input;
input = strtod (argv[1], NULL);
prn (argv[1]);
return 0;
}

in main the argument to prn is incompatible. I changed it to a double.
Whew.

Bill

[Barry Schwarz]

On Sun, 08 Jun 2008 02:14:49 GMT, "Bill Cunningham" <no****@nspam.com>
wrote:

I have patched together a print routine for my oscillator program and
one problem after another. This will not complie. But it has fewer errors
than it did.

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

void
prn (double input)
{
FILE *fp;
double *inpt;
inpt = &input;
fopen ("data", "wt");

You are opening the file in text mode.

if ((fwrite (inpt, sizeof (size_t), 1, fp)) != EOF);

But you are writing a binary value to it.

Furthermore, fwrite returns a size_t which is guaranteed to be
unsigned. EOF, on the other hand, is guaranteed to be negative.
Attempting to compare the two is not what you want to do.

And yet, since the semicolon represents an empty statement, it doesn't
matter whether the if evaluates to true or false. If it is true, you
do nothing. If it is false, you skip the empty statement and still do
nothing.

if ((fclose (fp)) != EOF);

Ditto.

>}

int
main (int argc, char *argv[])
{
double input;
input = strtod (argv[1], NULL);
prn (argv[1]);

prn takes a double. argv[1] is a pointer. Why are you passing
argv[1] when you went to all the trouble to convert the value it
points at to a double in input?

return 0;
}

in main the argument to prn is incompatible. I changed it to a double.

No you didn't.
Remove del for email

[Bill Cunningham]

"Barry Schwarz" <sc******@dqel.comwrote in message
news:bq********************************@4ax.com...

You are opening the file in text mode.

> if ((fwrite (inpt, sizeof (size_t), 1, fp)) != EOF);

But you are writing a binary value to it.

I've never really written to text mode before. I don't know what to do.

Furthermore, fwrite returns a size_t which is guaranteed to be
unsigned. EOF, on the other hand, is guaranteed to be negative.
Attempting to compare the two is not what you want to do.

I must want to do something like this.

size_t t;
if ((t=fwrite ( inpt,sizeof(size_t),1,fp))==NULL)
puts("error");

And yet, since the semicolon represents an empty statement, it doesn't
matter whether the if evaluates to true or false. If it is true, you
do nothing. If it is false, you skip the empty statement and still do
nothing.

> if ((fclose (fp)) != EOF);

Ditto.

>>}

int
main (int argc, char *argv[])
{
double input;
input = strtod (argv[1], NULL);
prn (argv[1]);

prn takes a double. argv[1] is a pointer. Why are you passing
argv[1] when you went to all the trouble to convert the value it
points at to a double in input?

> return 0;
}

in main the argument to prn is incompatible. I changed it to a double.

No you didn't.

I didn't? Do I not need the strtod function there then?

I'm so glad somebody out there knows what they're doing because I sure
don't. And I forget too. I've used error checking with fwrite before. But
its been along time.

Thanks much

Bill

[Bill Cunningham]

"Barry Schwarz" <sc******@dqel.comwrote in message
news:bq********************************@4ax.com...

[snip]

prn takes a double. argv[1] is a pointer. Why are you passing
argv[1] when you went to all the trouble to convert the value it
points at to a double in input?

> return 0;
}

Do I not want to use strtod to convert argv[1] to a double? What if
someone entered a string? Which is what is taken. Is an error check needed
here?

Bill

[Richard Heathfield]

Barry Schwarz said:

On Sun, 08 Jun 2008 02:14:49 GMT, "Bill Cunningham" <no****@nspam.com>
wrote:

> I have patched together a print routine for my oscillator program and
one problem after another. This will not complie. But it has fewer errors
than it did.

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

void
prn (double input)
{
FILE *fp;
double *inpt;
inpt = &input;
fopen ("data", "wt");

You are opening the file in text mode.

No, he isn't. He is opening the file in "undefined behaviour" mode.
See 4.9.5.3 of C89 or 7.19.5.3(3) of C99.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Richard]

"Bill Cunningham" <no****@nspam.comwrites:

I have patched together a print routine for my oscillator program and
one problem after another. This will not complie. But it has fewer errors
than it did.

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

void
prn (double input)
{
FILE *fp;
double *inpt;
inpt = &input;
fopen ("data", "wt");
if ((fwrite (inpt, sizeof (size_t), 1, fp)) != EOF);

What the hell is the line above? Do you ever read your own code?

if ((fclose (fp)) != EOF);

Ditto.

}

int
main (int argc, char *argv[])
{
double input;
input = strtod (argv[1], NULL);
prn (argv[1]);
return 0;
}

in main the argument to prn is incompatible. I changed it to a double.
Whew.

Bill

[Bartc]

"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:46******************************@bt.com...

Barry Schwarz said:

>On Sun, 08 Jun 2008 02:14:49 GMT, "Bill Cunningham" <no****@nspam.com>
wrote:

>> I have patched together a print routine for my oscillator program and
one problem after another. This will not complie. But it has fewer errors
than it did.

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

void
prn (double input)
{
FILE *fp;
double *inpt;
inpt = &input;
fopen ("data", "wt");

You are opening the file in text mode.

No, he isn't. He is opening the file in "undefined behaviour" mode.
See 4.9.5.3 of C89 or 7.19.5.3(3) of C99.

I wonder how much trouble it would have been for these committees to have
simply allowed "t" as an option? (Especially as this was a microsoft
extension).

Then code would have been self-documenting for those not familiar enough
with '4.9.5.3 of C89 or 7.19.5.3(3) of C99' to know whether the default mode
is text or binary.

(Just a question about text mode -- which I never use so I'm not too
bothered -- does it translate only the expected newline characters of the
host system to \n or will it cope with mixed files?

So if a program was opening text files from Windows, Linux and Mac, say,
would it translate newline characters from all of those successfully into
\n? Ie. just \n and no superfluous \r characters.

If it does, how does it do it? If not (and some brief tests suggest so),
then what actual use is a text mode which doesn't work?)

--
Bartc

[Jens Thoms Toerring]

Bill Cunningham <no****@nspam.comwrote:

I have patched together a print routine for my oscillator program and
one problem after another. This will not complie. But it has fewer errors
than it did.

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

void
prn (double input)
{
FILE *fp;
double *inpt;
inpt = &input;
fopen ("data", "wt");
if ((fwrite (inpt, sizeof (size_t), 1, fp)) != EOF);
if ((fclose (fp)) != EOF);
}

int
main (int argc, char *argv[])
{
double input;
input = strtod (argv[1], NULL);
prn (argv[1]);
return 0;
}

Here's a program that does things (hopefully) correctly and does
all the possible checks I could think of.

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>
#include <math.h>

void
prn( double input )
{
FILE *fp;

/* Open file named 'data' for writing in binary mode */

if ( ( fp = fopen( "data", "wb") ) == NULL )
{
fprintf( stderr, "Failed to open file\n" );
exit( EXIT_FAILURE );
}

/* Write one item with size of 'input' into the file */

if ( ( fwrite( &input, sizeof input, 1, fp ) ) != 1 )
{
fprintf( stderr, "Failed to write to file\n" );
exit( EXIT_FAILURE );
}

/* Close the file */

if ( fclose( fp ) != 0 )
{
fprintf( stderr, "Failed to close file\n" );
exit( EXIT_FAILURE );
}
}

int
main ( int argc,
char * argv[ ] )
{
double input;
char *endptr;

/* Check that we've got at least one argument */

if ( argc < 2 )
{
fprintf( stderr, "Missing argument\n" );
return EXIT_FAILURE;
}

/* Try to convert argument to a double */

input = strtod( argv[ 1 ], &endptr );

/* Check if a conversion could be performed */

if ( endptr == argv[ 1 ] )
{
fprintf( stderr, "Invalid argument\n" );
return EXIT_FAILURE;
}

/* Check that the input did consist of a floating point number only */

if ( *endptr != '\0' )
{
fprintf( stderr, "Trailing garbage in argument\n" );
return EXIT_FAILURE;
}

/* Check if correct result would underflow */

if ( input == 0.0 && errno == ERANGE )
{
fprintf( stderr, "Argument too small\n" );
return EXIT_FAILURE;
}

/* Check if correct result would overflow */

if ( ( input == HUGE_VAL || input == -HUGE_VAL ) && errno == ERANGE )
{
fprintf( stderr, "Argument too large\n" );
return EXIT_FAILURE;
}

/* Write result to a file */

prn( input );

return 0;
}
Regards, Jens
--
\ Jens Thoms Toerring ___ [e-mail]
\__________________________ http://toerring.de

[Ben Bacarisse]

"Bill Cunningham" <no****@nspam.comwrites:

"Barry Schwarz" <sc******@dqel.comwrote in message
news:bq********************************@4ax.com...

<snip>

>>>int
main (int argc, char *argv[])
{
double input;
input = strtod (argv[1], NULL);
prn (argv[1]);

prn takes a double. argv[1] is a pointer. Why are you passing
argv[1] when you went to all the trouble to convert the value it
points at to a double in input?

>> return 0;
}

in main the argument to prn is incompatible. I changed it to a double.

No you didn't.

I didn't? Do I not need the strtod function there then?

Your misunderstanding is something of a moving target so maybe it is
best to stick with one thing. Let examine this prn call.

The prn function is declared as taking a single argument of type
double. You call it like this:

prn (argv[1]);

argv is of type char ** so argv[1] is a char *. Your compiler should
be telling you that you are trying to call prn with an incompatible
argument.

When you say "I changed it to a double" presumably you are talking
about the previous line:

input = strtod (argv[1], NULL);

This sets the variable called input to the floating point value
represented by the characters pointed to by argv[1]. If argv[1]
points to "3.14" then input will get the value 3.14. argv[1] is not
changed, and this line has no effect on the following line:

prn (argv[1]);

You probably intended to write

prn (input);

which called prn with argument of the right type and makes use of the
variable you defined and so carefully set.

--
Ben.

[Ben Bacarisse]

"Bartc" <[e-mail]:
<snip>

(Just a question about text mode -- which I never use so I'm not too
bothered

I suspect you do use it. Any program that just uses stdin and stdout
is using text mode. If you don't use it for text files you open
yourself, how do you ensure your programs are portable? It seems odd
to reject a simple and effective mechanism that is guaranteed to be
available.

-- does it translate only the expected newline characters of the
host system to \n or will it cope with mixed files?

So if a program was opening text files from Windows, Linux and Mac, say,
would it translate newline characters from all of those successfully into
\n? Ie. just \n and no superfluous \r characters.

It maps the system's line ending to, and from, '\n'. That is (pretty
much) all.

If it does, how does it do it? If not

No, it just does the local conversion, if required.

(and some brief tests suggest so),
then what actual use is a text mode which doesn't work?)

I'd have thought that was obvious. It solves only one simple problem
-- how to write programs that read and write text files so that they
will work on any system with a correct C implementation. It does not
try to solve the problem of reading foreign files (e.g. Mac Classic
text files that have been byte-copied to a Unix system).

--
Ben.

[Keith Thompson]

"Bartc" <[e-mail]:

"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:46******************************@bt.com...

>Barry Schwarz said:

>>On Sun, 08 Jun 2008 02:14:49 GMT, "Bill Cunningham" <no****@nspam.com>
wrote:

I have patched together a print routine for my oscillator program and
one problem after another. This will not complie. But it has fewer errors
than it did.

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

void
prn (double input)
{
FILE *fp;
double *inpt;
inpt = &input;
fopen ("data", "wt");

You are opening the file in text mode.

No, he isn't. He is opening the file in "undefined behaviour" mode.
See 4.9.5.3 of C89 or 7.19.5.3(3) of C99.

I wonder how much trouble it would have been for these committees to have
simply allowed "t" as an option? (Especially as this was a microsoft
extension).

It wouldn't have been much trouble at all. But it's even less trouble
to omit the 't' when you write a call to fopen().

Then code would have been self-documenting for those not familiar
enough with '4.9.5.3 of C89 or 7.19.5.3(3) of C99' to know whether
the default mode is text or binary.

I don't think a whole lot of effort should be expended in making C
legible to readers who don't know the language.

(Just a question about text mode -- which I never use so I'm not too
bothered -- does it translate only the expected newline characters of the
host system to \n or will it cope with mixed files?

So if a program was opening text files from Windows, Linux and Mac, say,
would it translate newline characters from all of those successfully into
\n? Ie. just \n and no superfluous \r characters.

If it does, how does it do it? If not (and some brief tests suggest so),
then what actual use is a text mode which doesn't work?)

Text mode typically deals correctly with text files in the format used
by the implementation. Translating foreign files from one text format
to another is beyond the scope of stdio. (You can certainly do it by
*using* stdio, but the conversions aren't built in.)

In fact, as far as the standard is concerned, *anything* might have to
be re-mapped in text mode; there's nothing special about the new-line
character.

C99 7.19.2p2:

A text stream is an ordered sequence of characters composed into
lines, each line consisting of zero or more characters
plus a terminating new-line character. Whether the
last line requires a terminating new-line character is
implementation-defined. Characters may have to be added,
altered, or deleted on input and output to conform to differing
conventions for representing text in the host environment. Thus,
there need not be a oneto- one correspondence between the
characters in a stream and those in the external representation.
Read the rest of 7.19.2 as well.

On most systems you're likely to encounter, mapping between '\n' and
whatever sequence the implementation uses to mark end-of-line is
probably the only non-trivial mapping that's done in binary mode. But
it's theoretically possible that attempting to read a text file in
binary mode won't give you anything sensible; it might not even be
possible to open it.

(Just a question about text mode -- which I never use so I'm not too
bothered -- does it translate only the expected newline characters
of the host system to \n or will it cope with mixed files?

stdio provides a sophisticated mechanism for dealing with whatever
text file format your system happens to provide, so you don't have to
know how text files are represented. Why would you not take advantage
of that?

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Keith Thompson]

"Bill Cunningham" <no****@nspam.comwrites:

"Barry Schwarz" <sc******@dqel.comwrote in message
news:bq********************************@4ax.com...

[...]

>>>int
main (int argc, char *argv[])
{
double input;
input = strtod (argv[1], NULL);
prn (argv[1]);

[An attribution line was lost somewhere. The above was written by
Bill Cunningham.]

>prn takes a double. argv[1] is a pointer. Why are you passing
argv[1] when you went to all the trouble to convert the value it
points at to a double in input?

>> return 0;
}

in main the argument to prn is incompatible. I changed it to a double.

No you didn't.

I didn't? Do I not need the strtod function there then?

I'm so glad somebody out there knows what they're doing because I sure
don't. And I forget too. I've used error checking with fwrite before. But
its been along time.

Here's something that might or might not help you understand what's
going on.

strtod(argv[1], NULL) "converts" argv[1] (a char* that points to (the
first character of) a string) to a value of type double.

(I put the word "converts" in quotation marks because this isn't a
type conversion of the kind you get with a cast; we're using the word
"converts" in a somewhat looser sense.)

But when we say that it's converted, that doesn't mean that the thing
being converted is itself changed in any way. Conversion doesn't
*change* the thing being converted. It creates a new value that's the
*result* of the conversion, and leaves the original thing alone.

Calling strtod(argv[1], NULL) doesn't change argv[1] in any way.
argv[1] is still a char* pointing to a string. What strtod() does is
create a new result, a value of type double, that didn't exist before.
You then copy that value into the object "input".

double input;
input = strtod(argv[1], NULL);
prn(argv[1]); /* WRONG */

Since prn() expects a double, passing argv[1] to it makes no sense.
It wouldn't make any more or less sense if you deleted the strtod()
call.

What you want to pass to prn() is the *result* of the conversion,
which you've conveniently stored in the variable "input":

double input;
input = strtod(argv[1], NULL);
prn(input); /* RIGHT */

(Or you could replace these 3 lines with:
prn(strtod(argv[1], NULL));
..)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Bill Cunningham]

"Richard" <rg****@gmail.comwrote in message
news:g2**********@registered.motzarella.org...

> if ((fwrite (inpt, sizeof (size_t), 1, fp)) != EOF);

What the hell is the line above? Do you ever read your own code?

> if ((fclose (fp)) != EOF);

An attempt at error checking.

Bill

[Richard]

"Bill Cunningham" <no****@nspam.comwrites:

"Richard" <rg****@gmail.comwrote in message
news:g2**********@registered.motzarella.org...

>> if ((fwrite (inpt, sizeof (size_t), 1, fp)) != EOF);

What the hell is the line above? Do you ever read your own code?

>> if ((fclose (fp)) != EOF);

An attempt at error checking.

Bill

An attempt is the right word. Now, once again, what is the line above
and what do you think it is doing?

[Harald van =?UTF-8?b?RMSzaw==?=]

On Sun, 08 Jun 2008 19:05:03 +0000, Bill Cunningham wrote:

"Richard" <rg****@gmail.comwrote in message
news:g2**********@registered.motzarella.org...

>> if ((fwrite (inpt, sizeof (size_t), 1, fp)) != EOF);

What the hell is the line above? Do you ever read your own code?

>> if ((fclose (fp)) != EOF);

An attempt at error checking.

You check if fwrite fails, and if it does, you do nothing about it and
pretend it succeeded. That is no different from not checking at all. Try
to understand the code you are writing.

[Bill Cunningham]

"Ben Bacarisse" <be********@bsb.me.ukwrote in message
news:87************@bsb.me.uk...

When you say "I changed it to a double" presumably you are talking
about the previous line:

input = strtod (argv[1], NULL);

[snip]

Yes.

[Bill Cunningham]

"Jens Thoms Toerring" <[e-mail] in message
news:6b*************@mid.uni-berlin.de...

Here's a program that does things (hopefully) correctly and does
all the possible checks I could think of.

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>
#include <math.h>

void
prn( double input )
{
FILE *fp;

/* Open file named 'data' for writing in binary mode */

if ( ( fp = fopen( "data", "wb") ) == NULL )
{
fprintf( stderr, "Failed to open file\n" );
exit( EXIT_FAILURE );
}

/* Write one item with size of 'input' into the file */

if ( ( fwrite( &input, sizeof input, 1, fp ) ) != 1 )
{
fprintf( stderr, "Failed to write to file\n" );
exit( EXIT_FAILURE );
}

/* Close the file */

if ( fclose( fp ) != 0 )
{
fprintf( stderr, "Failed to close file\n" );
exit( EXIT_FAILURE );
}
}

int
main ( int argc,
char * argv[ ] )
{
double input;
char *endptr;

/* Check that we've got at least one argument */

if ( argc < 2 )
{
fprintf( stderr, "Missing argument\n" );
return EXIT_FAILURE;
}

/* Try to convert argument to a double */

input = strtod( argv[ 1 ], &endptr );

/* Check if a conversion could be performed */

if ( endptr == argv[ 1 ] )
{
fprintf( stderr, "Invalid argument\n" );
return EXIT_FAILURE;
}

/* Check that the input did consist of a floating point number only */

if ( *endptr != '\0' )
{
fprintf( stderr, "Trailing garbage in argument\n" );
return EXIT_FAILURE;
}

/* Check if correct result would underflow */

if ( input == 0.0 && errno == ERANGE )
{
fprintf( stderr, "Argument too small\n" );
return EXIT_FAILURE;
}

/* Check if correct result would overflow */

if ( ( input == HUGE_VAL || input == -HUGE_VAL ) && errno == ERANGE )
{
fprintf( stderr, "Argument too large\n" );
return EXIT_FAILURE;
}

/* Write result to a file */

prn( input );

return 0;
}
Regards, Jens

I think alot of what my problem is too is not understanding pointers fully.
When and where to use them. That's where Jen I get lost in your code above
is the pointers. For example,

if ( *endptr != '\0' )

{
fprintf( stderr, "Trailing garbage in argument\n" );
return EXIT_FAILURE;
}

if(*endptr!='\0')

Most of the time when I use pointers I do not use * again in front of the
pointer. Is what you are doing called "dereferencing" ? When to use * and &
too can give me trouble. My understanding is that & assigns an address in
memory to a pointer. Like this,

int *ip;
ip=&word;

Bill

[Richard]

"Bill Cunningham" <no****@nspam.comwrites:

"Jens Thoms Toerring" <[e-mail] in message
news:6b*************@mid.uni-berlin.de...

>Here's a program that does things (hopefully) correctly and does
all the possible checks I could think of.

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>
#include <math.h>

void
prn( double input )
{
FILE *fp;

/* Open file named 'data' for writing in binary mode */

if ( ( fp = fopen( "data", "wb") ) == NULL )
{
fprintf( stderr, "Failed to open file\n" );
exit( EXIT_FAILURE );
}

/* Write one item with size of 'input' into the file */

if ( ( fwrite( &input, sizeof input, 1, fp ) ) != 1 )
{
fprintf( stderr, "Failed to write to file\n" );
exit( EXIT_FAILURE );
}

/* Close the file */

if ( fclose( fp ) != 0 )
{
fprintf( stderr, "Failed to close file\n" );
exit( EXIT_FAILURE );
}
}

int
main ( int argc,
char * argv[ ] )
{
double input;
char *endptr;

/* Check that we've got at least one argument */

if ( argc < 2 )
{
fprintf( stderr, "Missing argument\n" );
return EXIT_FAILURE;
}

/* Try to convert argument to a double */

input = strtod( argv[ 1 ], &endptr );

/* Check if a conversion could be performed */

if ( endptr == argv[ 1 ] )
{
fprintf( stderr, "Invalid argument\n" );
return EXIT_FAILURE;
}

/* Check that the input did consist of a floating point number only */

if ( *endptr != '\0' )
{
fprintf( stderr, "Trailing garbage in argument\n" );
return EXIT_FAILURE;
}

/* Check if correct result would underflow */

if ( input == 0.0 && errno == ERANGE )
{
fprintf( stderr, "Argument too small\n" );
return EXIT_FAILURE;
}

/* Check if correct result would overflow */

if ( ( input == HUGE_VAL || input == -HUGE_VAL ) && errno == ERANGE )
{
fprintf( stderr, "Argument too large\n" );
return EXIT_FAILURE;
}

/* Write result to a file */

prn( input );

return 0;
}
Regards, Jens

I think alot of what my problem is too is not understanding pointers
fully.

This would be in addition to not understanding braces either I guess?

When and where to use them. That's where Jen I get lost in your code above
is the pointers. For example,

if ( *endptr != '\0' )

> {
fprintf( stderr, "Trailing garbage in argument\n" );
return EXIT_FAILURE;
}

if(*endptr!='\0')

Most of the time when I use pointers I do not use * again in front of
the

Do you know what * does in front of a pointer?

pointer. Is what you are doing called "dereferencing" ? When to use * and &
too can give me trouble. My understanding is that & assigns an address in
memory to a pointer. Like this,

int *ip;
ip=&word;

Use a debugger and play with it.

In the "real world" a pointer holds the address of an object. In other
words it "points to" that object. So yes! You are right. "&" gives the
address of an object so

int * p;
p=&myint;

means assign the address of the object myint to the point p.

Once more : use a debugger. Play with the values.

>
Bill

[Richard Heathfield]

Harald van D?k said:

On Sun, 08 Jun 2008 19:05:03 +0000, Bill Cunningham wrote:

>"Richard" <rg****@gmail.comwrote in message
news:g2**********@registered.motzarella.org...

>>> if ((fwrite (inpt, sizeof (size_t), 1, fp)) != EOF);

What the hell is the line above? Do you ever read your own code?

if ((fclose (fp)) != EOF);

An attempt at error checking.

You check if fwrite fails,

No, he isn't doing that. I'm not sure what he /is/ doing, but he isn't
checking whether fwrite failed.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Bill Cunningham]

"Richard" <rg****@gmail.comwrote in message
news:g2**********@registered.motzarella.org...

[snip]

Use a debugger and play with it.

In the "real world" a pointer holds the address of an object. In other
words it "points to" that object. So yes! You are right. "&" gives the
address of an object so

int * p;
p=&myint;

means assign the address of the object myint to the point p.

Once more : use a debugger. Play with the values.

I have gdb installed but alas I don't know anything about it and this
wouldn't be the place to ask questions.

Bill

[Richard]

"Bill Cunningham" <no****@nspam.comwrites:

"Richard" <rg****@gmail.comwrote in message
news:g2**********@registered.motzarella.org...

[snip]

>Use a debugger and play with it.

In the "real world" a pointer holds the address of an object. In other
words it "points to" that object. So yes! You are right. "&" gives the
address of an object so

int * p;
p=&myint;

means assign the address of the object myint to the point p.

Once more : use a debugger. Play with the values.

I have gdb installed but alas I don't know anything about it and this
wouldn't be the place to ask questions.

Bill

There's a wonderful thing called the internet. On it you will find
something called the world wide web and then Google. Try it.

[Jens Thoms Toerring]

Bill Cunningham <no****@nspam.comwrote:

I think alot of what my problem is too is not understanding pointers fully.
When and where to use them. That's where Jen I get lost in your code above
is the pointers. For example,

if ( *endptr != '\0' )

{
fprintf( stderr, "Trailing garbage in argument\n" );
return EXIT_FAILURE;
}

if(*endptr!='\0')

Most of the time when I use pointers I do not use * again in front of the
pointer. Is what you are doing called "dereferencing" ?

Yes. 'endptr' is a pointer and thus '*endptr' tells me what's
stored at the location in memory where it's pointing to. And
after a call like

input = strtod( argv[ 1 ], &endptr );

and everything went well 'endptr' will point to the trailing
'\0' character of argv[1]. If it doesn't I know that not
everything in argv[1] was something that could be interpreted
as being part of a floating point number. As an example let's
assume that argv[1] is "4.2e1XYZ". After the above call
'endptr' would point to the 'X' in argv[1] since that can't
be a valid part of a floating point number.

When to use * and &
too can give me trouble. My understanding is that & assigns an address in
memory to a pointer. Like this,

int *ip;

Take care: this is no dereference. This the way to define a pointer.
You can only dereference a pointer after it has been defined and
has been assigned a value (with a pointer, pointing to memory that
is yours).

ip=&word;

This is an assignment. It says the compiler to assign the address
of the variable 'word' to 'ip'. If you afterwards dereference 'ip'
you will get the same value as is stored in 'word'. So if you have

int word = 3; /* define an int variable named 'word' and
initialize it to the value 3 */
int *ip = &word; /* define an int pointer variable named 'ip'
and initialize it with the address of the
variable 'word' */

printf( "%d %d\n", word, *ip );

This will print '3' twice since that's the value stored in 'word'
and, of course, at the location 'ip' points to (i.e. the the va-
riable 'word').
Regards, Jens
--
\ Jens Thoms Toerring ___ [e-mail]
\__________________________ http://toerring.de

[Keith Thompson]

"Bill Cunningham" <no****@nspam.comwrites:

"Richard" <rg****@gmail.comwrote in message
news:g2**********@registered.motzarella.org...

>> if ((fwrite (inpt, sizeof (size_t), 1, fp)) != EOF);

Look at the arguments you're passing. Does "sizeof (size_t)" make any
sense in the context of your program? What made you think that
"sizeof (size_t)" is the right thing?

Why are you comparing the value returned by fwrite() against EOF?
What values does fwrite() return, and under what circumstances?

Did you *read the documentation for fwrite* before trying to call it?

You have an if statement. What do you do if the condition is true?
What do you do if the condition is false?

>What the hell is the line above? Do you ever read your own code?

>> if ((fclose (fp)) != EOF);

An attempt at error checking.

What do you do if there's an error? What do you do if there isn't an
error? Don't you think there should be a difference?

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Keith Thompson]

Richard<rg****@gmail.comwrites:
[...]

In the "real world" a pointer holds the address of an object. In other
words it "points to" that object.

[...]

What is the purpose of the ``In the "real world"'' qualification?

A pointer does hold the address of an object, even in the world of the
C standard. (Or it holds a null pointer value, or ...)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Richard]

Keith Thompson <ks***@mib.orgwrites:

Richard<rg****@gmail.comwrites:
[...]

>In the "real world" a pointer holds the address of an object. In other
words it "points to" that object.

[...]

What is the purpose of the ``In the "real world"'' qualification?

Hmm. I seem to recall being told it wasn't really the "address" by some
language lawyer. Regardless.

>
A pointer does hold the address of an object, even in the world of the
C standard. (Or it holds a null pointer value, or ...)

[Bartc]

"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...

"Bartc" <[e-mail]:

[fopen("data","wt")]

>I wonder how much trouble it would have been for these committees to have
simply allowed "t" as an option? (Especially as this was a microsoft
extension).

It wouldn't have been much trouble at all. But it's even less trouble
to omit the 't' when you write a call to fopen().

The "t" option would be optional of course.

>Then code would have been self-documenting for those not familiar
enough with '4.9.5.3 of C89 or 7.19.5.3(3) of C99' to know whether
the default mode is text or binary.

I don't think a whole lot of effort should be expended in making C
legible to readers who don't know the language.

Some effort clearly was expended. Unless "r" for read, "w" for write, "a"
for append and "b" for binary were purely coincidental.

probably the only non-trivial mapping that's done in binary mode. But
it's theoretically possible that attempting to read a text file in
binary mode won't give you anything sensible; it might not even be
possible to open it.

I can't believe this. Why shouldn't you be able to open a file in binary
mode and just read it byte by byte?

>(Just a question about text mode -- which I never use so I'm not too
bothered -- does it translate only the expected newline characters
of the host system to \n or will it cope with mixed files?

stdio provides a sophisticated mechanism for dealing with whatever
text file format your system happens to provide, so you don't have to
know how text files are represented. Why would you not take advantage
of that?

So long as it's possible that my program might read a text file which has
non-standard newlines for my system, then I will have to deal with that,
probably by using binary mode.

Otherwise it will sometimes fail, as an input file expected to be full of
short lines is presented as one line long probably with lots of embedded \r
characters.

--
Bartc

[Bill Cunningham]

"Jens Thoms Toerring" <[e-mail] in message
news:6b*************@mid.uni-berlin.de...

[snip]

This is an assignment. It says the compiler to assign the address
of the variable 'word' to 'ip'. If you afterwards dereference 'ip'
you will get the same value as is stored in 'word'. So if you have

int word = 3; /* define an int variable named 'word' and
initialize it to the value 3 */
int *ip = &word; /* define an int pointer variable named 'ip'
and initialize it with the address of the
variable 'word' */

printf( "%d %d\n", word, *ip );

This will print '3' twice since that's the value stored in 'word'
and, of course, at the location 'ip' points to (i.e. the the va-
riable 'word').
Regards, Jens

Ok if *ip is a pointer what about the FILE struct ? I declare a pointer
like FILE *fp; and use it like this

fp=fopen()

Why is this different? Shouldn't it be *fp=fopen...

Bill

[Keith Thompson]

Richard<rg****@gmail.comwrites:

Keith Thompson <ks***@mib.orgwrites:

>Richard<rg****@gmail.comwrites:
[...]

>>In the "real world" a pointer holds the address of an object. In other
words it "points to" that object.

[...]

What is the purpose of the ``In the "real world"'' qualification?

Hmm. I seem to recall being told it wasn't really the "address" by some
language lawyer. Regardless.

>>
A pointer does hold the address of an object, even in the world of the
C standard. (Or it holds a null pointer value, or ...)

In the standard, the terms "address" and "pointer" (or, more
specifically, "pointer value") are used interchangeably.

But an address in the C standard sense is not necessarily a machine
address, though it's *usually* represented as one. And conceptually,
a C "address" includes the type, which a machine address typically
does not.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Keith Thompson]

"Bill Cunningham" <no****@nspam.comwrites:

"Jens Thoms Toerring" <[e-mail] in message
news:6b*************@mid.uni-berlin.de...

[...]

>int *ip = &word; /* define an int pointer variable named 'ip'
and initialize it with the address of the
variable 'word' */

[...]

>
Ok if *ip is a pointer

No, *ip is not a pointer. *ip is an int. ip is a pointer.

"int *ip;" declares ip as a pointer.

what about the FILE struct ?

What about it?

I declare a pointer
like FILE *fp; and use it like this

fp=fopen()

Right.

Why is this different? Shouldn't it be *fp=fopen...

It would be if fopen() returned a result of type FILE.

What type does fopen() return? (Look it up.)

Section 4 of the comp.lang.c FAQ covers pointers, but it's mostly
intended to clear up misunderstandings for people who already
understand the basic concepts. Your C textbook or tutorial should
have a section on pointers. Re-read it.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Harald van =?UTF-8?b?RMSzaw==?=]

On Sun, 08 Jun 2008 22:25:19 +0000, Richard Heathfield wrote:

Harald van D?k said:

>>>> if ((fwrite (inpt, sizeof (size_t), 1, fp)) != EOF);

You check if fwrite fails,

No, he isn't doing that. I'm not sure what he /is/ doing, but he isn't
checking whether fwrite failed.

Oops. Quite right.

[CBFalconer]

Bartc wrote:

"Keith Thompson" <ks***@mib.orgwrote:

.... snip ...

>

>probably the only non-trivial mapping that's done in binary mode.
But it's theoretically possible that attempting to read a text
file in binary mode won't give you anything sensible; it might
not even be possible to open it.

I can't believe this. Why shouldn't you be able to open a file in
binary mode and just read it byte by byte?

Imagine a file system based on the disks used with CP/M 1. All
records are 128 bytes. A text line consists of bytes up to the
final '\n', and then the next line starts on the next record. You
can't read that file byte by byte. But you can search for record
numbers rapidly.

Binary files just stuff fixed length records.

And that is just one of many file systems in existance.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
** Posted from http://www.teranews.com **

[Richard]

"Bill Cunningham" <no****@nspam.comwrites:

"Jens Thoms Toerring" <[e-mail] in message
news:6b*************@mid.uni-berlin.de...

[snip]

>This is an assignment. It says the compiler to assign the address
of the variable 'word' to 'ip'. If you afterwards dereference 'ip'
you will get the same value as is stored in 'word'. So if you have

int word = 3; /* define an int variable named 'word' and
initialize it to the value 3 */
int *ip = &word; /* define an int pointer variable named 'ip'
and initialize it with the address of the
variable 'word' */

printf( "%d %d\n", word, *ip );

This will print '3' twice since that's the value stored in 'word'
and, of course, at the location 'ip' points to (i.e. the the va-
riable 'word').
Regards, Jens

Ok if *ip is a pointer

We just painstakingly stepped through this. *ip is NOT A POINTER. ip is
a pointer. Remember? It holds the address of the object ...

USE A DEBUGGER AND LOOK AT THE VALUES. For the 1000th time of
asking. That or give up.

[Richard]

Keith Thompson <ks***@mib.orgwrites:

Richard<rg****@gmail.comwrites:

>Keith Thompson <ks***@mib.orgwrites:

>>Richard<rg****@gmail.comwrites:
[...]
In the "real world" a pointer holds the address of an object. In other
words it "points to" that object.
[...]

What is the purpose of the ``In the "real world"'' qualification?

Hmm. I seem to recall being told it wasn't really the "address" by some
language lawyer. Regardless.

>>>
A pointer does hold the address of an object, even in the world of the
C standard. (Or it holds a null pointer value, or ...)

In the standard, the terms "address" and "pointer" (or, more
specifically, "pointer value") are used interchangeably.

But an address in the C standard sense is not necessarily a machine
address, though it's *usually* represented as one. And conceptually,
a C "address" includes the type, which a machine address typically
does not.

As I said ....

[Richard]

Harald van Dijk <tr*****@gmail.comwrites:

On Sun, 08 Jun 2008 22:25:19 +0000, Richard Heathfield wrote:

>Harald van D?k said:

>>>>> if ((fwrite (inpt, sizeof (size_t), 1, fp)) != EOF);
>
You check if fwrite fails,

No, he isn't doing that. I'm not sure what he /is/ doing, but he isn't
checking whether fwrite failed.

Oops. Quite right.

Maybe you could explain?

When you replied you did include the fwrite call.

He was indeed trying to check for an error but unsurprisingly Bill did
not read the manual and realise to check for 0 or a short count.

,----
| fread() and fwrite() return the number of items successfully read or
| written (i.e., not the number of characters). If an error occurs, or
| the end-of-file is reached, the return value is a short item count (or
| zero).
`----

[Nick Keighley]

On 8 Jun, 04:47, "Bill Cunningham" <[e-mail]:

"Barry Schwarz" <[e-mail] in message
news:bq********************************@4ax.com...

prn takes a double. *argv[1] is a pointer. *Why are you passing
argv[1] when you went to all the trouble to convert the value it
points at to a double in input?

*return 0;
}

* * Do I not want to use strtod to convert argv[1] to a double?

RTFM. strtod() DOES NOT convert a char* to a double. It returns
a double value that corresponds to the char*. In C types cannot change
on the fly.

What if someone entered a string?

what?

Which is what is taken. Is an error check needed
here?

I've no idea what you talking about.
--
Nick Keighley

[Nick Keighley]

On 8 Jun, 17:59, Ben Bacarisse <[e-mail]:

"Bartc" <[e-mail]:

(Just a question about text mode -- which I never use so I'm not too
bothered

I suspect you do use it. *Any program that just uses stdin and stdout
is using text mode. *If you don't use it for text files you open
yourself, how do you ensure your programs are portable? *It seems odd
to reject a simple and effective mechanism that is guaranteed to be
available.

-- does it translate only the expected newline characters of the
host system to \n or will it cope with mixed files?

So if a program was opening text files from Windows, Linux and Mac, say,
would it translate newline characters from all of those successfully into
\n? Ie. just \n and no superfluous \r characters.

It maps the system's line ending to, and from, '\n'. *That is (pretty
much) all.

it may have to do some work at the end of the file such as insert a
^z.
I believe some systems have really weird files and it may have to pad
lines or lines may be in some sort of record structure with a count
at the beginning (VMS?). Some file systems insist the that there is a
^Z at the end of the file (DOS?).
<snip>

--
Nick Keighley

"XML is isomorphic to the subset of Lisp data
where the first item in a list is required to be atomic."
John McCarthy

[Richard]

Nick Keighley <ni******************@hotmail.comwrites:

On 8 Jun, 04:47, "Bill Cunningham" <[e-mail]:

>"Barry Schwarz" <[e-mail] in message
news:bq********************************@4ax.com.. .

prn takes a double. Â*argv[1] is a pointer. Â*Why are you passing
argv[1] when you went to all the trouble to convert the value it
points at to a double in input?

>Â*return 0;
}

Â* Â* Do I not want to use strtod to convert argv[1] to a double?

RTFM. strtod() DOES NOT convert a char* to a double. It returns
a double value that corresponds to the char*.

It converts the string addressed (or pointed to) by the char *. When explaining
to Bill it's best to be more precise.

[Nick Keighley]

On 8 Jun, 18:43, Keith Thompson <[e-mail]:

<snip>

stdio provides a sophisticated mechanism for dealing with whatever
text file format your system happens to provide, so you don't have to
know how text files are represented. *Why would you not take advantage
of that? * *

because he doesn't read or write text files?
An embedded application of some sort?
--
Nick Keighley

"Almost every species in the universe has an irrational fear of the
dark.
But they're wrong- cos it's not irrational. It's Vashta Nerada."
The Doctor

[Nick Keighley]

On 8 Jun, 22:53, "Bill Cunningham" <[e-mail]:

I think alot of what my problem is too is not understanding pointers fully.

no your major problem is not reading your text book
and then making wild guesses.

--
Nick Keighley

[Bartc]

"CBFalconer" <cb********@yahoo.comwrote in message
news:48***************@yahoo.com...

Bartc wrote:

>"Keith Thompson" <ks***@mib.orgwrote:

... snip ...

>>

>>probably the only non-trivial mapping that's done in binary mode.
But it's theoretically possible that attempting to read a text
file in binary mode won't give you anything sensible; it might
not even be possible to open it.

I can't believe this. Why shouldn't you be able to open a file in
binary mode and just read it byte by byte?

Imagine a file system based on the disks used with CP/M 1. All
records are 128 bytes. A text line consists of bytes up to the
final '\n', and then the next line starts on the next record. You
can't read that file byte by byte. But you can search for record
numbers rapidly.

Binary files just stuff fixed length records.

So? I've used CP/M and I've dealt with files with it, text and binary,
without using C and it's 'text mode'. I don't recall any problems. I think
text files expected to have byte 0x1A as an end-of-text-file marker.

I've considered up to now that C's notion of a text file is just a binary
file which uses a delimiter sequence D between 'lines' and a terminator
sequence E, for example:

abcdefDghDDijklDEmn

contains 4 lines "abcdef","gh","","ijkl".

With C's text mode simply translating D to and from it's version of \n for
this host and stopping at, or inserting, the E marker.

That's reasonable (except if it doesn't recognise D of an imported file, I
might as well make my own attempt at translation -- we all know the
possibilities for D are likely to be cr, crlf, lf, lfcr.).

For text files not to be openable in binary mode, it would have to do
something really weird, like store each line of the file in a separate
hidden file, or in compressed form. But this I don't believe; such goings-on
would surely be hidden behind a translation layer.

C's text mode is already giving me problems by being too clever:

I'm using a language superimposed on C's runtime, which generates CR,LF for
new lines. This seems to get translated, when writing to STDOUT, to
CR,CR,LF, which on the screen looks the same. But sent to a file (using
Windows' >), these lines cause my (15yo) editor to crash.

--
Bart

[Bartc]

"Bill Cunningham" <no****@nspam.comwrote in message
news:Zq03k.2857$lE3.2045@trnddc05...

fp=fopen()

Why is this different? Shouldn't it be *fp=fopen...

You could try this:

FILE f;

f=*(fopen("file","rb"));
....
fclose(&f);

But it won't work in practice because you are then using your own copy of
the FILE object, and the address of that (&f) won't match any such addresses
inside the file system.

--
Bartc

[Kenny McCormack]

In article <g2**********@registered.motzarella.org>,
Richard <rg****@gmail.comwrote:
....

>But an address in the C standard sense is not necessarily a machine
address, though it's *usually* represented as one. And conceptually,
a C "address" includes the type, which a machine address typically
does not.

As I said ....

You have, I assume, sent him a thank-you note for making your case for you...

[Richard]

ga*****@xmission.xmission.com (Kenny McCormack) writes:

In article <g2**********@registered.motzarella.org>,
Richard <rg****@gmail.comwrote:
...

>>But an address in the C standard sense is not necessarily a machine
address, though it's *usually* represented as one. And conceptually,
a C "address" includes the type, which a machine address typically
does not.

As I said ....

You have, I assume, sent him a thank-you note for making your case for
you...

I just wonder at the mindset that considers waffling out the above as a
good thing when one is involved in a thread with Bill "Braces are still
a bit confusing for me" Cunningham. What can it hope to achieve? But a
better case of "thanks for proving my point" is rare to see. Well,
in other technical groups anyway. But CLC never ceases to amaze.

[Ben Bacarisse]

"Bartc" <[e-mail]:
<snip>

C's text mode is already giving me problems by being too clever:

I'm using a language superimposed on C's runtime, which generates CR,LF for
new lines. This seems to get translated, when writing to STDOUT, to
CR,CR,LF, which on the screen looks the same. But sent to a file (using
Windows' >), these lines cause my (15yo) editor to crash.

It is not C being too clever, it the programmer not being clever
enough. If, in Windows, you are writing \r\n to a file, then one can
assume that you don't want to treat it as test file. If you do, it
will go wrong. You have two options:

(1) Treat your output as a binary stream. The downside is that you
will be putting \r\n into files even when your program is ported to a
system that prefers not to have these as line endings.

(2) If your output is text, treat it as text. Write the output in the
portable way C expects you to and the output will have the correct
line endings. The advantage you get is a simpler program that is
portable to other systems.

If your program is intended to generate output for use on "other"
systems, then (1) is the only way to go (and you need some way to tell
you program what sort of line ending to write). You will also not be
able to write to stdout[1]. If you are writing text files for use
"here" then (2) is the way to go.

Some programs need to do both, and then they have to know the mode of
each stream and the target line ending they must use for those stream
that are binary. Taking that a bit further, you might also need to
know the character encoding that the foreign system expects. Such
programs were quite common when truly diverse systems were more common.

Writing \r\n to a text stream is very unlikely to be the right thing
to do. Equally, not using text mode when writing text for the local
system just sounds like cutting your nose off to spite your face.

[1] There is often a system-specific way to re-open stdout in the mode
of your choice, so this is not a hard and fast rule.

--
Ben.

[Keith Thompson]

"Bartc" <[e-mail]:

"CBFalconer" <cb********@yahoo.comwrote in message
news:48***************@yahoo.com...

>Bartc wrote:

>>"Keith Thompson" <ks***@mib.orgwrote:

... snip ...

>>>
probably the only non-trivial mapping that's done in binary mode.
But it's theoretically possible that attempting to read a text
file in binary mode won't give you anything sensible; it might
not even be possible to open it.

I can't believe this. Why shouldn't you be able to open a file in
binary mode and just read it byte by byte?

Imagine a file system based on the disks used with CP/M 1. All
records are 128 bytes. A text line consists of bytes up to the
final '\n', and then the next line starts on the next record. You
can't read that file byte by byte. But you can search for record
numbers rapidly.

Binary files just stuff fixed length records.

So? I've used CP/M and I've dealt with files with it, text and binary,
without using C and it's 'text mode'. I don't recall any problems. I think
text files expected to have byte 0x1A as an end-of-text-file marker.

He said "CP/M 1". I'm not familiar with it, but apparently an early
version of CP/M used this fixed-length record representation for text
files.

I've considered up to now that C's notion of a text file is just a binary
file which uses a delimiter sequence D between 'lines' and a terminator
sequence E, for example:

abcdefDghDDijklDEmn

contains 4 lines "abcdef","gh","","ijkl".

With C's text mode simply translating D to and from it's version of \n for
this host and stopping at, or inserting, the E marker.

You were mistaken.

That's reasonable (except if it doesn't recognise D of an imported file, I
might as well make my own attempt at translation -- we all know the
possibilities for D are likely to be cr, crlf, lf, lfcr.).

Perhaps on the system you've used (though I've never heard of a system
that uses lfcr).

For text files not to be openable in binary mode, it would have to
do something really weird, like store each line of the file in a
separate hidden file, or in compressed form. But this I don't
believe; such goings-on would surely be hidden behind a translation
layer.

You don't have to believe it -- but it's perfectly true.

That translation layer, in C is called "text mode". If you choose
not to use it for some reason, you don't get its benefits.

The C standard says very little about how text files are actually
represented, or what you'll get if you read a text file in binary
mode. It doesn't even say anything specific about line endings;
that's just a special case of the more general translation. Take a
look at C99 7.19.2.

C's text mode is already giving me problems by being too clever:

I'm using a language superimposed on C's runtime, which generates CR,LF for
new lines. This seems to get translated, when writing to STDOUT, to
CR,CR,LF, which on the screen looks the same. But sent to a file (using
Windows' >), these lines cause my (15yo) editor to crash.

So don't write '\r' to a text file (unless you really want a '\r'
character in your text file).

If you're dealing with native text files, use text mode. There's no
good reason not to.

If you have to deal with non-native text files, things become more
difficult. You have to know the foreign format. Depending on the
system, you might be able to use native text mode with some tweaks
(such as explicitly adding a '\r' to each line, or ignoring it on
input), or you might have to use binary mode. If it's practical, it's
better to use a separate tool to convert text files to native format
(but that's not always practical).

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Harald van =?UTF-8?b?RMSzaw==?=]

On Mon, 09 Jun 2008 10:47:24 +0200, Richard wrote:

Harald van Dijk <tr*****@gmail.comwrites:

>On Sun, 08 Jun 2008 22:25:19 +0000, Richard Heathfield wrote:

>>Harald van D?k said:
>> if ((fwrite (inpt, sizeof (size_t), 1, fp)) != EOF);
>>
You check if fwrite fails,

No, he isn't doing that. I'm not sure what he /is/ doing, but he isn't
checking whether fwrite failed.

Oops. Quite right.

Maybe you could explain?

When you replied you did include the fwrite call.

He was indeed trying to check for an error but unsurprisingly Bill did
not read the manual and realise to check for 0 or a short count.

Exactly, he was trying to check, but checking whether fwrite(...) == EOF
does not actually check if fwrite fails.

[Eric Sosman]

Bartc wrote:

[...] we all know the
possibilities for [line terminator] are likely to be cr, crlf, lf, lfcr.).
[...]

0d 00 H e l l o , 20 w o r l d ! 00

(Not a product of my fevered imagination.)

--
Er*********@sun.com

[CBFalconer]

Bartc wrote:

"CBFalconer" <cb********@yahoo.comwrote in message

.... snip ...

>

>Imagine a file system based on the disks used with CP/M 1. All
records are 128 bytes. A text line consists of bytes up to the
final '\n', and then the next line starts on the next record. You
can't read that file byte by byte. But you can search for record
numbers rapidly.

Binary files just stuff fixed length records.

So? I've used CP/M and I've dealt with files with it, text and
binary, without using C and it's 'text mode'. I don't recall any
problems. I think text files expected to have byte 0x1A as an
end-of-text-file marker.

I didn't say a CP/M file system. Read the above carefully again.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
** Posted from http://www.teranews.com **

[Bill Cunningham]

There's a wonderful thing called the internet. On it you will find

something called the world wide web and then Google. Try it.

Already tried. I learned a little. Not really enough I think to do much
good.

Bill

[concerned c.l.c reader]

Richard wrote (for the 1000th time):

USE A DEBUGGER AND LOOK AT THE VALUES.

Are you by any chance related with Jeff Relf? You seem to be the
only person on usenet who shares his obsession with debuggers.

For the 1000th time of asking. That or give up.

You are not going to cry, are you?