FILE objects

J

John Tsiombikas (Nuclear / the Lab)

I know what they mean. var is a variable. A place in memory for an int.
And *var is a pointer to a location in memory that is an int. What I confuse
is how to use this in function parameters.

For example int function(void**)
That's a pointer to a pointer to a void. But what do you do with it in
code ?

Bill

You may need to pass to a function a pointer to a pointer for various
reasons. For example you may want to pass an array of strings to a
function and use it like this:

void foo(char **str_array, int count) {
int i;
for(i=0; i<count; i++) {
printf("string[%d]: %s\n", i, str_array);
}
}

or you may have a pointer that you want to change inside that function,
for example:

void foo(int **bar) {
if(*bar == 0) {
*bar = malloc(sizeof(int));
}
**bar = 10;
}
 
M

Marcin Hoppe

Irrwahn said:
Minor correction: sizeof(char) is 1 byte per definition on every
conforming C implementation. What might be different on different
platforms is the number of bits per byte.

You're right. What's the proper name for 8 bits then? Octet?
 
A

Arthur J. O'Dwyer

You're right. What's the proper name for 8 bits then? Octet?

IMO yes.[/QUOTE]

On this newsgroup, certainly. Saying "octet" will not only
make it clear what you mean, it will actually prevent the regulars'
jumping on you for calling 8 bits a "byte." Everyone wins! :)


Although I don't freak out or cry when people refer to 8 bits as a
byte.

I just don't understand those people who will use "byte" to refer
to 8 bits, and then insist that a "word" isn't necessarily 16 bits.
Heresy! ;-)
</OT>

-Arthur
 
D

Dan Pop

Bill Cunningham is beyond any help.
printf("EnterFilename-> ");
fflush(stdout);
char fname;

Bad and misplaced definition.
scanf("%c",&fname);

Correct, but useless function call.
FILE *fp;

Misplaced definition.
fopen(fname,30,30,fp);

Bad function call.
fread(fname,"rb");

Bad function call.
fwrite("file",30,30,fp);

Bad function call.
fclose(fp);

Bad function call, fp is still uninitialised.
Now I know there should be some casts here.

Nope, there should be some thought process behind the code you write.

I could fix all this pile of shit, but I know you well enough to realise
that I would be wasting my time.

Dan
 
D

Dan Pop

In said:
Malcolm said:
Conventionally, argv[0] is the name of the program.

In the not-too-distant past, there was a rather extended (I think)
discussion about this point; I'd be most grateful if someone could
remind me what the end consensus was.

For once, Malcolm is right. As any convention, this one can be broken,
too ;-)

If argv[0] is not a null pointer, it is *supposed* to provide the program
name.

- If the value of argc is greater than zero, the string pointed
to by argv[0] represents the program name; argv[0][0] shall be
the null character if the program name is not available from
the host environment.

In practice, on Unix platforms, at least, it is possible to provide a
string completely unrelated to the program name, via argv[0], when
executing a program. But this is not a good reason for not assuming
that argv[0], when not a null pointer or pointing to an empty string,
does not provide the program name (if the user wants to shoot himself in
the foot, you should kindly oblige ;-)

Dan
 
D

Dan Pop

In said:
My suggestion to you is to stay completely away from
pointers and file operations until you have a better grasp
of the language.

He's been posting idiotic questions in this newsgroup for over one year.
At this point, it is highly unrealistic to expect him to *ever* have a
better grasp on the language.

Dan
 
I

Irrwahn Grausewitz

Vic Dura said:
I'm curious as to why the fflush is necessary?

In order to guarantee that the prompt will be displayed before any
user input is subsequently requested. It's not really necessary
on most systems in their default configuration, but it's definitely
the right thing to have in portable code. Another option is to
terminate the output with a new line character, but that's usually
not desirable for prompts like above. And always remember to
terminate the last line of output with a '\n'.

Regards
 
D

Dan Pop

In said:
I'm curious as to why the fflush is necessary?

According to the standard, it isn't. I'm not aware of any implementation
needing it, but some people feel safer if they include it, nevertheless.
It's harmless, anyway.

Dan
 
G

Gordon Burditt

printf("EnterFilename->");
According to the standard, it isn't. I'm not aware of any implementation
needing it, but some people feel safer if they include it, nevertheless.
It's harmless, anyway.

On UNIX (specifically FreeBSD 4.9 here, but I suspect most any
version of UNIX will do the same thing), if you invoke the program
with its output directed to a pipe:

./prog | tee /dev/null

You *DO* need that fflush() or you won't see the prompt until after
you answer a following input request.

Gordon L. Burditt
 
D

Dan Pop

In said:
On UNIX (specifically FreeBSD 4.9 here, but I suspect most any
version of UNIX will do the same thing), if you invoke the program
with its output directed to a pipe:

./prog | tee /dev/null

You *DO* need that fflush() or you won't see the prompt until after
you answer a following input request.

That's not the way interactive programs are supposed to be run in the
first place.

Dan
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads


Members online

Forum statistics

Threads
474,141
Messages
2,570,817
Members
47,366
Latest member
IanCulpepp

Latest Threads

Top