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

[Eric Sosman]

Re: FILE objects

Bill Cunningham wrote:[color=blue]
>[color=green]
> >
> > 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=blue]
> 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 to
> 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.

--
Eric.Sosman@sun .com

[Bill Cunningham]

Re: FILE objects

> You have a problem with reading the filename. You declared it as a[color=blue]
> single character, not as an array of characters (string). The second
> problem I noticed is that you've misused fopen and fwrite functions.
> After some improvements your code should be similar to this:
>
> #include <stdio.h>
>
> int main() {
> /* File object */
> FILE *fp = NULL;
> /* File name */
> char fname[256];
> /* Some buffer to read, 30 bytes (on my computer) */
> char rd_buf[30];
>
> /* Nice prompt :) */
> printf("EnterFi lename->");
> fflush(stdout);
>
> /* This way you get the whole string */
> scanf("%s", fname);
>
> /* Open the file for reading in binary mode */
> fp = fopen(fname, "rb");
>
> /* Check if file was opened successfully */
> if(fp != NULL) {
> /* Read some bytes from the opened file */
> /* Data is read to the rd_buf buffer */
> /* Amount of data read is computed here, */
> /* so you don't need to worry if you change */
> /* size of the buffer */
> fread( (void *) rd_buf, sizeof(char),
> sizeof(rd_buf) / sizeof(rd_buf[0]), fp);
> }
>
> /* Close the file */
> fclose(fp);
>
> return 0;
> }
>
> I hope I've helped.
>[/color]
Those sizeof's in your code. Do they report to size_t ?

Bill

[Marcin Hoppe]

Re: FILE objects

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

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