FILE objects

[Bill Cunningham]

Re: FILE objects

If you have trouble with the difference between[color=blue]
> int var and int *var I suggest you stay away from FILE
> objects for now.
>[/color]
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

[Bill Cunningham]

Re: FILE objects


"Eric Sosman" <Eric.Sosman@su n.com> wrote in message
news:407F0D0E.4 963EB3D@sun.com ...[color=blue]
> Bill Cunningham wrote:[color=green]
> >[color=darkred]
> > >
> > > Let's see the code - I'm sure clc can help.[/color]
> >
> > printf("EnterFi lename-> ");
> > fflush(stdout);
> > char fname;
> > scanf("%c",&fna me);
> > FILE *fp;
> > fopen(fname,30, 30,fp);
> > fread(fname,"rb ");
> > fwrite("file",3 0,30,fp);
> > fclose(fp);
> > Now I know there should be some casts here. [...][/color]
>
> "This isn't right. It isn't even wrong." It's certainly
> beyond the power of casts to correct.
>[color=green]
> > I find k&r2's function
> > prototypes hard to read. Not the functions explained with bodies in the
> > book. But these file functions aren't described in detail. I don't
> > understand the parameters by looking at prototypes and no example of how[/color][/color]
to[color=blue][color=green]
> > write the code.[/color]
>
> You'll notice that Christopher asked you for *the* code,
> not just for *some* code. Please post *the* code, not a
> sawed-off bleeding chunk, nor yet a paraphrase: *the* code,
> cut'n'pasted straight from your editor into the message.
>
> As it stands, we're all left guessing about what's going
> on. You probably #include'd <stdio.h> because otherwise
> the compiler would have barfed on the undefined identifier
> `stdout' -- but if <stdio.h> was i#include'd the compiler
> would have barfed on the incorrect arguments to fopen() and
> fread(). Clearly you have done something very peculiar indeed,
> and nobody's likely to give you a good diagnosis until you
> reveal what you've done.
>
> Or (sudden sad disillusionment ) is it possible that you
> have in fact written no code at all, and you're simply trying
> to trick c.l.c. into writing your homework assignment for you?
> Say it ain't so, Joe.
>[/color]
That's *the* code. And it isn't a joke though alot of people in clc look
at my code and think that. And yes take it for granted #include <stdio.h> is
there. And int main(void).

Bill

[Irrwahn Grausewitz]

Re: FILE objects

Marcin Hoppe <marcinhoppe@po czta.onet.pl> wrote:[color=blue]
>Bill Cunningham wrote:[color=green]
>>
>> Those sizeof's in your code. Do they report to size_t ?
>>[/color]
>
> The sizeof operator returns the size of its argument. Its "unit" is the
>size of char (on x86 platform it is usually 1 byte)[/color]

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.
[color=blue]
>and the return type
>is size_t. It's written in K&R :).[/color]

Regards
--
Irrwahn Grausewitz (irrwahn33@free net.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

[Christopher Benson-Manica]

Re: FILE objects

Malcolm <malcolm@55bank .freeserve.co.u k> spoke thus:
[color=blue]
> Conventionally, argv[0] is the name of the program.[/color]

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.

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

[CBFalconer]

Re: FILE objects

Christopher Benson-Manica wrote:[color=blue]
> Malcolm <malcolm@55bank .freeserve.co.u k> spoke thus:
>[color=green]
> > Conventionally, argv[0] is the name of the program.[/color]
>
> 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.[/color]

As usual, "it depends". :-)

--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[John Tsiombikas (Nuclear / the Lab)]

Re: FILE objects

On 2004-04-15, Bill Cunningham <nospam@nspam.n et> wrote:[color=blue]
>
> 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
>[/color]

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[i]);
}
}

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(i nt));
}
**bar = 10;
}

--
John Tsiombikas (Nuclear / the Lab)
nuclear@siggrap h.org

http://thelab.demoscene.gr/nuclear/

[Marcin Hoppe]

Re: FILE objects

Irrwahn Grausewitz wrote:[color=blue]
> 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.[/color]

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

--
E-mail: marcinhoppe@poc zta.onet.pl
WWW: http://marcinhoppe.republika.pl
GaduGadu IM: 2222891
Looking for a job as a software developer.

[Severian]

Re: FILE objects

On Fri, 16 Apr 2004 09:33:48 +0200, Marcin Hoppe
<marcinhoppe@po czta.onet.pl> wrote:
[color=blue]
>Irrwahn Grausewitz wrote:[color=green]
>> 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.[/color]
>
> You're right. What's the proper name for 8 bits then? Octet?[/color]

IMO yes.

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

--
Sev

[Arthur J. O'Dwyer]

Re: FILE objects


On Fri, 16 Apr 2004, Severian wrote:[color=blue]
>
> On Fri, 16 Apr 2004 09:33:48 +0200, Marcin Hoppe wrote...[color=green]
> >Irrwahn Grausewitz wrote:[color=darkred]
> >> 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.[/color]
> >
> > You're right. What's the proper name for 8 bits then? Octet?[/color]
>
> IMO yes.[/color]

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! :)


<OT>[color=blue]
> Although I don't freak out or cry when people refer to 8 bits as a
> byte.[/color]

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

[Dan Pop]

Re: FILE objects

In <107u1hg36dvht0 c@corp.supernew s.com> "Bill Cunningham" <nospam@nspam.n et> writes:

[color=blue][color=green]
>> Let's see the code - I'm sure clc can help.[/color][/color]

Bill Cunningham is beyond any help.
[color=blue]
> printf("EnterFi lename-> ");
> fflush(stdout);
> char fname;[/color]

Bad and misplaced definition.
[color=blue]
> scanf("%c",&fna me);[/color]

Correct, but useless function call.
[color=blue]
> FILE *fp;[/color]

Misplaced definition.
[color=blue]
> fopen(fname,30, 30,fp);[/color]

Bad function call.
[color=blue]
> fread(fname,"rb ");[/color]

Bad function call.
[color=blue]
> fwrite("file",3 0,30,fp);[/color]

Bad function call.
[color=blue]
> fclose(fp);[/color]

Bad function call, fp is still uninitialised.
[color=blue]
>Now I know there should be some casts here.[/color]

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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de

[Dan Pop]

Re: FILE objects

In <c5ni9g$k1p$1@c hessie.cirr.com > Christopher Benson-Manica <ataru@nospam.c yberspace.org> writes:
[color=blue]
>Malcolm <malcolm@55bank .freeserve.co.u k> spoke thus:
>[color=green]
>> Conventionally, argv[0] is the name of the program.[/color]
>
>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.[/color]

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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de

[Dan Pop]

Re: FILE objects

In <c5n2pu$3nkfn$1 @ID-228872.news.uni-berlin.de> Thomas stegen <tstegen@cis.st rath.ac.uk> writes:
[color=blue]
>Bill Cunningham wrote:[color=green]
>>
>> Quite probably. I don't know when I need int var or int *var.[/color]
>
>My suggestion to you is to stay completely away from
>pointers and file operations until you have a better grasp
>of the language.[/color]

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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de

[Vic Dura]

Re: FILE objects

On Fri, 16 Apr 2004 00:27:04 +0200, RE: Re: FILE objects Marcin
Hoppe <marcinhoppe@po czta.onet.pl> wrote:
[color=blue]
> printf("EnterFi lename->");
> fflush(stdout);[/color]

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

--
To reply to me directly, remove the XXX characters from my email address.

[Irrwahn Grausewitz]

Re: FILE objects

Vic Dura <vpdura@XXXhiwa ay.net> wrote:[color=blue]
>On Fri, 16 Apr 2004 00:27:04 +0200, RE: Re: FILE objects Marcin
>Hoppe <marcinhoppe@po czta.onet.pl> wrote:
>[color=green]
>> printf("EnterFi lename->");
>> fflush(stdout);[/color]
>
>I'm curious as to why the fflush is necessary?[/color]

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
--
Irrwahn Grausewitz (irrwahn33@free net.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

[Eric Sosman]

Re: FILE objects

Vic Dura wrote:[color=blue]
>
> On Fri, 16 Apr 2004 00:27:04 +0200, RE: Re: FILE objects Marcin
> Hoppe <marcinhoppe@po czta.onet.pl> wrote:
>[color=green]
> > printf("EnterFi lename->");
> > fflush(stdout);[/color]
>
> I'm curious as to why the fflush is necessary?[/color]

This is Question 12.4 in the comp.lang.c Frequently
Asked Questions (FAQ) list

http://www.eskimo.com/~scs/C-faq/top.html

--
Eric.Sosman@sun .com