pointers
Bill Cunningham
size_t fread(void *buf...,
The address seems to be passed to fread's first parameter a lot. Does it
have to be done that way? What I see is fread wanting a pointer to
something. And it doesn't have to be a char* because the generic pointer is
declared.
char *name="file";
fread(&name,
Why not
fread(name, or
fread(*name,
To dereference? *name points to the same address as returned by &name. Does
something about the first parameter scream out "Pass the address being
pointed too!" All I see is that void *buf wants a pointer.
Bill
Lew Pitcher
> Ok concering the first parameter of fread.
>
> size_t fread(void *buf...,
>
> The address seems to be passed to fread's first parameter a lot. Does
> it
> have to be done that way? What I see is fread wanting a pointer to
> something. And it doesn't have to be a char* because the generic pointer
> is declared.
>
> char *name="file";
> fread(&name,
[snip]
Bill, you misunderstand what fread() uses that first parameter for.
The first parameter is /not/ the name of a file (as your example above
suggests). Instead, the parameter is a pointer to a buffer in which the
fread() function will place the data obtained from the file.
If fread() were only interested in obtaining character data, then that first
parameter /could have been/ defined as a char *.
But, fread() was intentionally designed to be able to read other forms of
data as well. With fread(), (by design) you /could/ read int values, or
float values, or even struct {} values. And, each read would need a buffer
of like type to store the results in.
An fread() of int values would need an int * buffer
An fread() of double values would need a double * buffer
An fread() of struct foo values would need a struct foo * buffer.
So, the first parameter to fread() is not only a pointer to a buffer, but it
must be a "typeless" pointer, to accomodate the alternative types that the
buffer may have.
Further, since fread() can read /multiple/ values, the buffer /may be/ an
array of the appropriate type.
In other words, fread()'s prototype must be able to cope with
FILE * raw_data_file;
struct foo { int bar; double baz; char blech[20]} foo_array[4];
fread(foo_array, sizeof foo_array[0], 4, raw_data_file);
as well as
FILE * character_data_file;
char buffer[256];
fread(buffer,1,256,character_data_file);
HTH
--
Lew Pitcher
Master Codewright & JOAT-in-training | Registered Linux User #112576
Me: http://pitcher.digitalfreehold.ca/ | Just Linux: http://justlinux.ca/
---------- Slackware - Because I know what I'm doing. ------
Andrew Poelstra
> Ok concering the first parameter of fread.
>
> size_t fread(void *buf...,
>
> The address seems to be passed to fread's first parameter a lot. Does it
> have to be done that way? What I see is fread wanting a pointer to
> something. And it doesn't have to be a char* because the generic pointer is
> declared.
>
> char *name="file";
> fread(&name,
>
&name is a pointer to a pointer to "file". But you want just a pointer
to "file". (Also, bear in mind that because you wrote "file" out as a
string constant, you can't legally read into it. Better to have written
char name[] = "file";
instead.)
> Why not
> fread(name, or
This one is what you want.
> fread(*name,
>
*name is a char. Specifically, the char 'f'. It doesn't point to
anything, so fread can't use it.
> To dereference? *name points to the same address as returned by &name. Does
> something about the first parameter scream out "Pass the address being
> pointed too!" All I see is that void *buf wants a pointer.
>
It wants a pointer to some memory that you're allowed to write
to. It will then write to said memory. That's all.
Andrew
Bill Cunningham
"Lew Pitcher" <lpit...@teksavvy.com> wrote in message
news:YjHcn.24796$aU4....@newsfe13.iad...
So then in the above the buffer is created kind of as a work around for
what malloc() does it sound to me like. I seldom use fread. I prefer moving
things a bit or byte at a time so I focus more of getc and putc. I am
reading "Applied Cryptography" right now so in the future I might need to
work some with blocks of data so fread() may just be what I'm looking for.
I noticed above you didn't use fread(&buffer... so does that mean you
don't have to pass the address pointed to but the pointer itself in this
case the char array.
My question started with pointers and I guess I'm misunderstanding
fread() too.
Bill
Kleuskes & Moos
> "Lew Pitcher" <lpitc...@teksavvy.com> wrote in message
In some applications it is not convenient to "malloc/free" buffers
every time you read a block. You would rather malloc it once (or not
at all) and recycle the buffer. Hence the pointer.
> I seldom use fread. I prefer moving things a bit or byte at a time so I focus more of getc and putc.
That may be called for in some apps. But in many/most cases the file
is buffered, and still reads a block at at time.
> I am
> reading "Applied Cryptography" right now so in the future I might need to
> work some with blocks of data so fread() may just be what I'm looking for.
> I noticed above you didn't use fread(&buffer... so does that mean you
> don't have to pass the address pointed to but the pointer itself in this
> case the char array.
Yes.
> My question started with pointers and I guess I'm misunderstanding
> fread() too.
:).
Andrew Poelstra
>
> what malloc() does it sound to me like. I seldom use fread. I prefer moving
Well, it's putting the onus on /you/ to allocate the memory
before you call it. So it's kinda a workaround for malloc()
but you can still use malloc() if you want. You just have a
choice.
A common idiom is to use a local array:
char buffer[BLOCK_SIZE];
fread(buffer, 1, sizeof buffer, fh);
And that way you avoid potential memory allocation failures
and also likely save yourself a lot of CPU time because the
buffer will be in roughly the same area as your other local
data, which lets the CPU cache everything.
> things a bit or byte at a time so I focus more of getc and putc. I am
> reading "Applied Cryptography" right now so in the future I might need to
> work some with blocks of data so fread() may just be what I'm looking for.
It's a tough book. Good luck.
And yes, fread() would be optimal for this purpose.
> I noticed above you didn't use fread(&buffer... so does that mean you
> don't have to pass the address pointed to but the pointer itself in this
> case the char array.
The pointer /is/ the address pointed to. That's it's value.
You can think of it as an integer if you like, though often
that is not quite true. (DOS for example used funny segment
information that was crammed in there somehow.)
In any case, the pointer's value is what is passed. And that
value is the address pointed to.
> My question started with pointers and I guess I'm misunderstanding
> fread() too.
>
Only a little. You just need to make sure you know
what all the arguments you pass are supposed to be.
Andrew
Joe Wright
--
Joe Wright
"If you rob Peter to pay Paul you can depend on the support of Paul."
Bill Cunningham
"Andrew Poelstra" <apoe...@localhost.localdomain> wrote in message
news:slrnhn6gf4.b...@localhost.localdomain...
[snip]
> &name is a pointer to a pointer to "file". But you want just a pointer
> to "file". (Also, bear in mind that because you wrote "file" out as a
> string constant, you can't legally read into it. Better to have written
>
So to use &name for example, The first parameter would look like
fread(void **buf...? I have seen the ampersand passed to this first
parameter before. And it seems always to be used as scanf()'s first
parameter. To me a void ** is a generic two dimensional array with an
unspecified number of elements. Possibly leading to overflow if one isn't
careful.
Reading parameters and knowing what they are asking for is something I
need to learn. I need to know when a parameter is calling for this:
char *name;
So just name,
*name, or
&name.
Bill
Barry Schwarz
<apoe...@localhost.localdomain> wrote:
>On 2010-02-10, Bill Cunningham <nos...@nspam.invalid> wrote:
>>
snip
>> My question started with pointers and I guess I'm misunderstanding
>> fread() too.
>>
>
>Only a little. You just need to make sure you know
>what all the arguments you pass are supposed to be.
On the contrary. As his code amply demonstrates, his misunderstanding
is monumental.
--
Remove del for email
Andrew Poelstra
>
> "Andrew Poelstra" <apoe...@localhost.localdomain> wrote in message
> news:slrnhn6gf4.b...@localhost.localdomain...
>
> [snip]
>
>> &name is a pointer to a pointer to "file". But you want just a pointer
>> to "file". (Also, bear in mind that because you wrote "file" out as a
>> string constant, you can't legally read into it. Better to have written
>>
> So to use &name for example, The first parameter would look like
> fread(void **buf...? I have seen the ampersand passed to this first
Well, if you were reading into a variable - rather than a buffer - you
would need the & operator. Like, if you were reading an int value you
might have
int i;
fread(&i, 1, sizeof i, ...
But since a character buffer is /already/ a pointer to its data, there
is no need to use &.
> parameter before. And it seems always to be used as scanf()'s first
> parameter. To me a void ** is a generic two dimensional array with an
Nope, sorry. void* can be a "pointer to anything", but unfortunately void**
is a specific type - pointer to void*, and you lose a lot of the genericity
that void* gets you.
> unspecified number of elements. Possibly leading to overflow if one isn't
> careful.
>
> Reading parameters and knowing what they are asking for is something I
> need to learn. I need to know when a parameter is calling for this:
>
Google and your manpages (if you have them) will help you.
> char *name;
> So just name,
> *name, or
> &name.
>
name is a pointer to char.
*name is the char that name points to.
&name is a pointer to name.
Andrew
Michael Tsang
Hash: SHA1
Stefan Ram wrote:
> Andrew Poelstra <apoe...@localhost.localdomain> writes:
>>A common idiom is to use a local array:
>>char buffer[BLOCK_SIZE];
>>fread(buffer, 1, sizeof buffer, fh);
>>And that way you avoid potential memory allocation failures
>
> Allocating BLOCK_SIZE bytes with automatic storage duration
> cannot fail?
It can certainly fail. Even worse, once it fails, the program has no chance
to recover. However, when malloc() fails, it returns NULL and the program
can abort().
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAkt0GlMACgkQm4klUUKw07BDnwCcD8vd+Ewn6R8hg+e9CxJ5umli
RAYAn2A72v3Bc19zO9FdQ553ITL9d+YH
=Qcim
-----END PGP SIGNATURE-----
Default User
> On February 10, 2010 18:11, in comp.lang.c, nos...@nspam.invalid
> wrote:
>
> > Ok concering the first parameter of fread.
> >
> > size_t fread(void *buf...,
> >
> > The address seems to be passed to fread's first parameter a
> > lot. Does it
> > have to be done that way? What I see is fread wanting a pointer to
> > something. And it doesn't have to be a char* because the generic
> > pointer is declared.
> >
> > char *name="file";
> > fread(&name,
> [snip]
>
> Bill, you misunderstand what fread() uses that first parameter for.
Oddly, back a few years ago, he did know they were for:
<http://groups.google.com/group/comp.lang.c/browse_frm/thread/4b3be51aba
38d613>
In 2004, after another long thread about how to use fread(), Dan Pop
posted the following:
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.
Nothing has changed since then, I'd say. He's either incapable of
learning, or trolling.
Brian
--
Day 374 of the "no grouchy usenet posts" project
Bill Cunningham
"Andrew Poelstra" <apoe...@localhost.localdomain> wrote in message
> Google and your manpages (if you have them) will help you.
>
My man pages were the first thing I looked at. Reading the parameters
didn't help and the man page was a little obscure. I don't have kandr2 with
me and my little C book didn't show any examples which didn't help much; I
have recently moved and haven't brought kandr2 yet. Since I don't use fread
I needed to remind myself what exactly the buf was for.
If one didn't want to use that first parameter what would you pass to it
? I might just try malloc.
Bill
Tom St Denis
In what way are you *not* a troll?
man fread
----------
NAME
fread, fwrite - binary stream input/output
SYNOPSIS
#include <stdio.h>
size_t fread(void *ptr, size_t size, size_t nmemb, FILE
*stream);
DESCRIPTION
The function fread() reads nmemb elements of data, each size
bytes long, from the stream pointed to by stream, storing them at the
location given by ptr.
----------
Learn to read.
Tom
Seebs
> In what way are you *not* a troll?
One presumes that he *can't* read, at some fairly fundamental level.
Google "alexia" sometime and compare it to his posts.
-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
Tom St Denis
> On 2010-02-11, Tom St Denis <t...@iahu.ca> wrote:
>
> > In what way are you *not* a troll?
>
> One presumes that he *can't* read, at some fairly fundamental level.
> Google "alexia" sometime and compare it to his posts.
So if he has a reading comprehension problem the solution is an even
longer prose explanation? if he can't follow A=A, B=B, C=C then there
is no hope.
The real answer is he's either a troll or just unwilling to spend 3
seconds reading a man page [or both]. Since most of his posts are
about complete and fundamental misunderstanding of the basics of C I'd
think he's deliberately starting these threads to get attention.
Granted his tone isn't negative, he's still a waste of time.
Andrew Poelstra
>
> news:slrnhn6tkd.k...@localhost.localdomain...
>
>> Google and your manpages (if you have them) will help you.
>>
> My man pages were the first thing I looked at. Reading the parameters
> didn't help and the man page was a little obscure. I don't have kandr2 with
> me and my little C book didn't show any examples which didn't help much; I
> have recently moved and haven't brought kandr2 yet. Since I don't use fread
> I needed to remind myself what exactly the buf was for.
In fread(), like in fgets() and other functions, the buffer a
pointer to where the data that you read needs to go.
> If one didn't want to use that first parameter what would you pass to it
> ? I might just try malloc.
>
You have to use the parameter. You have to give the data a
place to go.
Andrew
Tom St Denis
> "Andrew Poelstra" <apoels...@localhost.localdomain> wrote in message
If you actually read the man page for 'fread' you'd see the first
parameter is NOT the file name.
However, since that's what you assumed we can only conclude you DID
NOT read the man page.
Bill Cunningham
"Tom St Denis" <t...@iahu.ca> wrote in message
news:6be7786d-b3b1-412d...@z26g2000yqm.googlegroups.com...
If you actually read the man page for 'fread' you'd see the first
parameter is NOT the file name.
However, since that's what you assumed we can only conclude you DID
NOT read the man page.
The man page that I understood was
size_t fread (void* buf...etc.
void *buf tells me nothing except a pointer is wanted. It's been so long
since I've used fread. Well I understand now.
B
Bill Cunningham
man fread
----------
NAME
fread, fwrite - binary stream input/output
SYNOPSIS
#include <stdio.h>
size_t fread(void *ptr, size_t size, size_t nmemb, FILE
*stream);
DESCRIPTION
The function fread() reads nmemb elements of data, each size
bytes long, from the stream pointed to by stream, storing them at the
location given by ptr.
"Storing at the location given by ptr" ???? huh
Didn't remember that meant buffer. Sorry my C book says void * buf not the
man page.
Default User
> On 2010-02-11, Tom St Denis <t...@iahu.ca> wrote:
> > In what way are you not a troll?
>
> One presumes that he can't read, at some fairly fundamental level.
> Google "alexia" sometime and compare it to his posts.
All I know is that in 2008, Bill seemed to know how fread() worked just
fine, now he doesn't. Trolling. Regressing. Take your pick. Either way,
a complete waste of time replying.
Richard Heathfield
<snip>
> Granted his tone isn't negative, he's still a waste of time.
Well, *he* isn't a waste of time. But I agree with what I am sure you
actually meant - i.e. it's a waste of time to read his articles. What I
don't understand is why you feel it necessary to waste everyone's time
by telling us what we already know. :-)
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within
Nick Keighley
> "Tom St Denis" <t...@iahu.ca> wrote in messagenews:9652f5dd-e07e-4861...@y7g2000vbb.googlegroups.com...
> man fread
> ----------
so this is the output from the
man command yes?
> NAME
> fread, fwrite - binary stream input/output
>
> SYNOPSIS
> #include <stdio.h>
>
> size_t fread(void *ptr, size_t size, size_t nmemb, FILE
> *stream);
>
> DESCRIPTION
> The function fread() reads nmemb elements of data, each size
> bytes long, from the stream pointed to by stream, storing them at the
> location given by ptr.
>
> "Storing at the location given by ptr" ???? huh
in what way is this unclear? "location" means "memory location". What
else /could/ it mean?
> Didn't remember that meant buffer.
what do you think "buffer" means?
> Sorry my C book says void * buf not the
> man page.
it /does/ I can see it!!!!!!!!!!!!! look
size_t fread(void *ptr, size_t size, size_t nmemb, FILE
WHAT IS THE TYPE OF ptr?
Ben Bacarisse
> On 11 Feb, 19:53, "Bill Cunningham" <nos...@nspam.invalid> wrote:
<snip>
>> man fread
<snip>
> so this is the output from the
> man command yes?
>
>> NAME
>> fread, fwrite - binary stream input/output
>>
>> SYNOPSIS
>> #include <stdio.h>
>>
>> size_t fread(void *ptr, size_t size, size_t nmemb, FILE
>> *stream);
<snip>
>> Sorry my C book says void * buf not the
>> man page.
>
> it /does/ I can see it!!!!!!!!!!!!!
I can't.
> look
> size_t fread(void *ptr, size_t size, size_t nmemb, FILE
>
> WHAT IS THE TYPE OF ptr?
It's void *, of course.
You and I both know that void *ptr and void *buf are the same. It
could even read fread(void *, size_t, size_t, FILE *); and we'd be
happy with that. We know that the name (and even if there is one) has
no effect on the meaning of the function prototype. But I suspect
that Bill does not.
When I reply to Bill, if I think that more that two consecutive !s are
called for, or if I feel drawn to the cap lock key, I stop writing and
kill the post. Just a thought.
--
Ben.
Bill Cunningham
"Nick Keighley" <nick_keigh...@hotmail.com> wrote in message
news:9e824b77-0222-4bc0...@b7g2000yqd.googlegroups.com...
what do you think "buffer" means?
It could mean a location somewhere in a stream. For example *nix's dd
command. I use it a bit. It could mean point to a specific place in a
buffer. Like dd's seek option and like C's fseek. I guess you can't use that
parameter for that though.
clc is so topic specific that when a thead goes on and on there is not
much left to talk about except standard C functions. The same thing over and
over.
Bill
Lew Pitcher
>
> "Nick Keighley" <nick_keigh...@hotmail.com> wrote in message
> news:9e824b77-0222-4bc0...@b7g2000yqd.googlegroups.com...
>
> what do you think "buffer" means?
>
> It could mean a location somewhere in a stream. For example *nix's dd
> command. I use it a bit. It could mean point to a specific place in a
> buffer. Like dd's seek option and like C's fseek. I guess you can't use
> that parameter for that though.
Bill, these /might/ be valid uses of the word "buffer", but I've never
encountered them. In fact, the dd(1) manual page doesn't use the
word "buffer" to indicate "a location in a stream"; heck, it doesn't use
the word "buffer" at all.
~ $ man dd | grep buffer
~ $
OTOH, FOLDOC's definition (http://foldoc.org/buffer) is almost exactly what
I learned over 30 years ago in my programming classes; something
that /every/ programmer I've ever talked to seems to agree with
1. An area of memory used for storing messages. Typically, a buffer will
have other attributes such as an input pointer (where new data will be
written into the buffer), and output pointer (where the next item will
be read from) and/or a count of the space used or free. Buffers are
used to decouple processes so that the reader and writer may operate at
different speeds or on different sized blocks of data.
2. An electronic device to provide compatibility between two signals, e.g.
changing voltage levels or current capability.
> clc is so topic specific that when a thead goes on and on there is not
> much left to talk about except standard C functions. The same thing over
> and over.
Hmmmm..... Perhaps that's not a bad thing. In your case, you could learn a
lot from such a discussion.
But, I've seen a lot of discussions here on general programming practice, as
applied to programming in the C language. (I.e. sorting techniques,
recursion, string handling, tree management, etc.)
And, I've seen a lot of discussions on various "non-standard" elements, as
approached by C code that meets the C standard (i.e. handling "packed
decimal" values in C code, handling characterset translations in C code,
etc.)
As I said, you could learn a lot from reading /and trying to comprehend/
those discussions.
Bill Cunningham
"Lew Pitcher" <lpit...@teksavvy.com> wrote in message news:B9hdn.97216
[snip]
> 1. An area of memory used for storing messages. Typically, a buffer will
> have other attributes such as an input pointer (where new data will be
> written into the buffer), and output pointer (where the next item will
> be read from) and/or a count of the space used or free. Buffers are
> used to decouple processes so that the reader and writer may operate
> at
> different speeds or on different sized blocks of data.
That's exactly what confused me. With a parameter like void *ptr it
could mean a buffer or the "location" of an input or output ptr.
Bill