printig effort

[Keith Thompson]

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?

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]

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 ...)

 

[Richard]

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.

 

[Bartc]

[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.

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?

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.

 

[Bill Cunningham]

[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]

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]

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.

 

[Harald van Dijk]

Harald van D?k said:

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.

 

[Richard]

[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]

[...]
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]

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]

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]

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.



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]

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]

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]

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.

 

[Bartc]

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.

 

[Bartc]

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.

 

[Kenny McCormack]

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 ....[/QUOTE]

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

 

[Richard]

As I said ....

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

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.