small question
Bill Cunningham
standard C question. memset()'s first parameter is void* . But in this code
hints is of type struct addrinfo. So does that qualify hints as a pointer of
sorts?
Bill
Bill Cunningham
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/types.h>
#include <netdb.h>
#include <sys/socket.h>
struct addrinfo hints, *servinfo;
int main()
{
int status;
memset(&hints, '\0', sizeof hints);
hints.ai_family = AF_INET;
hints.ai_socktype = SOCK_STREAM;
hints.ai_flags = AI_PASSIVE;
if ((status = getaddrinfo(NULL, "23", &hints, &servinfo)) != 0) {
fprintf(stderr, "usage error...%s\n", gai_strerror(status));
exit(1);
}
return status;
}
Nick Keighley
> Oops forgot code.
oops forgot the question
> #include <stdio.h>
> #include <stdlib.h>
> #include <string.h>
> #include <sys/types.h>
> #include <netdb.h>
> #include <sys/socket.h>
>
> struct addrinfo hints, *servinfo;
> int main()
> {
> int status;
> memset(&hints, '\0', sizeof hints);
memeset() requires a pointer as the first parameter. The & on the
front of hints takes hints address hence &hints /is/ a pointer
Tucker
hints is not a pointer, but &hints is a pointer. However, &hints is not a variable, so you can't assign to it. You can only assign to *(&hints).
Seebs
>
> »A pointer type describes an object whose value provides
> a reference to an entity of the referenced type«
>
> but »&hints« is not an object, only a value. »&hints«
> seems to be an »address«. But, I am afraid, that in
> ISO/IEC 9899:1999 (E) itself, sometimes »pointer« is
> used for »address« and so. Or, one might argue that
> this usage /is/ correct and just the definition is wrong.
> In this case, »&hints« would be a pointer, indeed.
I seem to recall that it is for reasons such as this that C1X was
talking about "temporary storage duration" for intermediate parts of
expressions.
-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!
Keith Thompson
> Tucker <not...@nowhere.net> writes:
>>hints is not a pointer, but &hints is a pointer
>
> I used to think so, too, but in ISO/IEC 9899:1999 (E)
>
> »A pointer type describes an object whose value provides
> a reference to an entity of the referenced type«
>
> but »&hints« is not an object, only a value. »&hints«
> seems to be an »address«. But, I am afraid, that in
> ISO/IEC 9899:1999 (E) itself, sometimes »pointer« is
> used for »address« and so. Or, one might argue that
> this usage /is/ correct and just the definition is wrong.
> In this case, »&hints« would be a pointer, indeed.
The standard is quite clear that a "pointer" is a *value* of
pointer type. See for example, the description of malloc(), which
returns a pointer to the allocated space.
The standard is also incomplete regarding the meaning of "value".
The definition refers to the value stored in an object, without
explicitly acknowledging that a value can also be the result of
an expression.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Keith Thompson
> On 2010-04-11, Stefan Ram <r...@zedat.fu-berlin.de> wrote:
>> Tucker <not...@nowhere.net> writes:
>>>hints is not a pointer, but &hints is a pointer
>>
>> I used to think so, too, but in ISO/IEC 9899:1999 (E)
>>
>> »A pointer type describes an object whose value provides
>> a reference to an entity of the referenced type«
>>
>> but »&hints« is not an object, only a value. »&hints«
>> seems to be an »address«. But, I am afraid, that in
>> ISO/IEC 9899:1999 (E) itself, sometimes »pointer« is
>> used for »address« and so. Or, one might argue that
>> this usage /is/ correct and just the definition is wrong.
>> In this case, »&hints« would be a pointer, indeed.
>
> I seem to recall that it is for reasons such as this that C1X was
> talking about "temporary storage duration" for intermediate parts of
> expressions.
Not quite. It's temporary lifetime, not temporary storage duration,
and it's being introduced specifically for array members of non-lvalue
struct or union expressions.
In general -- um, in most cases -- there's no need to assume a
temporary object for an expression result of pointer type. &hints is
simply an expression that yields a value of pointer type.
N1425 6.2.4p8:
A non-lvalue expression with structure or union type, where
the structure or union contains a member with array type
(including, recursively, members of all contained structures
and unions) refers to an object with automatic storage
duration and _temporary lifetime_. Its lifetime begins when
the expression is evaluated and its initial value is the value
of the expression. Its lifetime ends when the evaluation of
the containing full expression or full declarator ends. Any
attempt to modify an object with temporary lifetime results in
undefined behavior.
For example:
#include <stdio.h>
struct foo {
int arr[3];
};
struct foo func(void) {
struct foo result = { 10, 20, 30 };
return result;
}
int main(void)
{
int *ptr = func().arr;
printf("*ptr = %d\n", *ptr); /* undefined behavior in C201X */
return 0;
}
Since func().arr is an expression of array type (and doesn't appear in
one of the special contexts), it decays to a pointer to the first
element of the corresponding array object. In C90 and C99, since the
result returned by a function is not an lvalue, there is no such
object, at least not in the abstract machine. C201X defines such an
object and specifies its lifetime.
Bill Cunningham
> hints is not a pointer, but &hints is a pointer. However, &hints is
> not a variable, so you can't assign to it. You can only assign to
> *(&hints).
[snip]
>>> #include <stdio.h>
>>> #include <stdlib.h>
>>> #include <string.h>
>>> #include <sys/types.h>
>>> #include <netdb.h>
>>> #include <sys/socket.h>
>>>
>>> struct addrinfo hints, *servinfo;
>>> int main()
>>> {
>>> int status;
>>> memset(&hints, '\0', sizeof hints);
>>
>> memeset() requires a pointer as the first parameter. The & on the
>> front of hints takes hints address hence &hints /is/ a pointer
>>
>>> hints.ai_family = AF_INET;
>>> hints.ai_socktype = SOCK_STREAM;
>>> hints.ai_flags = AI_PASSIVE;
>>> if ((status = getaddrinfo(NULL, "23", &hints, &servinfo)) != 0) {
>>> fprintf(stderr, "usage error...%s\n", gai_strerror(status));
>>> exit(1);
>>> }
>>> return status;
I thought & returns an address. Atleast in some cases I'm aware of. Hints is
simply of type struct addrinfo. In this situation does hints act as a
pointer?
Bill
Bill Cunningham
Shouldn't be here,
>>> memeset() requires a pointer as the first parameter. The & on the
>>> front of hints takes hints address hence &hints /is/ a pointer
Oh I see now I screwed up the quoting. And I am using OE quote fix.
Bill
Keith Thompson
[...]
> I thought & returns an address. Atleast in some cases I'm aware of. Hints is
> simply of type struct addrinfo. In this situation does hints act as a
> pointer?
No, Bill, hints is not a pointer, and does not act as a pointer, as
we've told you several times. Why do you not believe us?
hints is an object of type struct addrinfo; that's a struct type, not
a pointer type.
Yes, the unary "&" operator yields an address. An address is also
referred to as a pointer value, or just as a pointer. (The
unqualified word "pointer" often refers to an object of pointer type,
but it can also refer to a value of pointer type.)
So
hints
is not a pointer, but
&hints
is a pointer, specifically a pointer value, or an address.
Perhaps if you saved a copy of this, or printed it out, or wrote it
down, you might not need to ask the same question again.
Bill Cunningham
> No, Bill, hints is not a pointer, and does not act as a pointer, as
> we've told you several times. Why do you not believe us?
>
> hints is an object of type struct addrinfo; that's a struct type, not
> a pointer type.
>
> Yes, the unary "&" operator yields an address. An address is also
> referred to as a pointer value, or just as a pointer. (The
> unqualified word "pointer" often refers to an object of pointer type,
> but it can also refer to a value of pointer type.)
>
> So
> hints
> is not a pointer, but
> &hints
> is a pointer, specifically a pointer value, or an address.
I see. I'm confusing & with returning an address. But I've never thought
of it as a pointer. C with me is sink or swim. I just have to dive in.
Sometimes I sink sometimes I swim and sometimes I come back to the surface.
What could've been typed instead of &hints? Maybe (*hints)? I need to
review ponters. Maybe *(hints)?
Bill
Keith Thompson
> Keith Thompson wrote:
>
>> No, Bill, hints is not a pointer, and does not act as a pointer, as
>> we've told you several times. Why do you not believe us?
>>
>> hints is an object of type struct addrinfo; that's a struct type, not
>> a pointer type.
>>
>> Yes, the unary "&" operator yields an address. An address is also
>> referred to as a pointer value, or just as a pointer. (The
>> unqualified word "pointer" often refers to an object of pointer type,
>> but it can also refer to a value of pointer type.)
>>
>> So
>> hints
>> is not a pointer, but
>> &hints
>> is a pointer, specifically a pointer value, or an address.
>
> I see. I'm confusing & with returning an address. But I've never thought
> of it as a pointer.
Well there's your problem. In C, the words "address" and "pointer"
mean nearly the same thing, particularly when referring to values.
We don't usually talk about an address object or an address type;
rather we refer to these as a pointer object or a pointer type,
respecitvely. But an address value (such as the address of an
object) is a pointer value.
> C with me is sink or swim. I just have to dive in.
> Sometimes I sink sometimes I swim and sometimes I come back to the surface.
I have yet to see you surface.
> What could've been typed instead of &hints? Maybe (*hints)? I need to
> review ponters. Maybe *(hints)?
You could have typed anything you like. Most of the things you could
have typed would be wrong, because they'd be wild guesses.
What made you even consider the possibility that (*hints) or *(hints)
(both of which are equivalent to *hints) could be a reasonable
substitute for &hints?
If &hints is correct, why are you looking for an alternative?
Stop guessing. Don't type the '*' or '&' character into either a C
source file or a Usenet article until you understand what it means.
If you don't already understand what it means, look it up.
I've told you this before.
Bill Cunningham
[...]
> Well there's your problem. In C, the words "address" and "pointer"
> mean nearly the same thing, particularly when referring to values.
> We don't usually talk about an address object or an address type;
> rather we refer to these as a pointer object or a pointer type,
> respecitvely. But an address value (such as the address of an
> object) is a pointer value.
[snip]
>> What could've been typed instead of &hints? Maybe (*hints)? I
>> need to review ponters. Maybe *(hints)?
>
> You could have typed anything you like. Most of the things you could
> have typed would be wrong, because they'd be wild guesses.
>
> What made you even consider the possibility that (*hints) or *(hints)
> (both of which are equivalent to *hints) could be a reasonable
> substitute for &hints?
>
> If &hints is correct, why are you looking for an alternative?
>
> Stop guessing. Don't type the '*' or '&' character into either a C
> source file or a Usenet article until you understand what it means.
> If you don't already understand what it means, look it up.
>
> I've told you this before.
I think this is where I'm getting it. Interating what a pointer points
to. *(ip)+1 is it or (*ip)+1 yields the next value pointed to.
Does that make sense?
Bill
Keith Thompson
[...]
> to. *(ip)+1 is it or (*ip)+1 yields the next value pointed to.
>
> Does that make sense?
No.
First, we weren't talking about pointer arithmetic. I suggest
you don't introduce a new topic until you understand the previous one.
Second, no, neither *(ip)+1 nor (*ip)+1 yields the next value pointed
to. *(ip+1) does, and it's exactly equivalent to ip[1].
My earlier remark about not typing & or * without understanding what
they do applies equally to parentheses. At least twice in this
thread, you've inserted parentheses in seemingly arbitrary and
incorrect places.
Seebs
> "Bill Cunningham" <nos...@nspam.invalid> writes:
> [...]
> First, we weren't talking about pointer arithmetic. I suggest
> you don't introduce a new topic until you understand the previous one.
Just to interject...
"Bill Cunningham" has been posting what purport to be questions about
C for a loooong time. Is trying to get him to understand any concept
actually more rewarding, in terms of signal/noise, than trying to
communicate with Nilges?
My original theory was that at least you could explain things for newbies,
but on further study:
1. His "oh, I get it" responses usually make things LESS clear than they
were before.
2. I have never seen anyone else make these mistakes or be confused
by these issues.
3. Maybe if we all ignore him he'll go do something else.
4. It's not as though there is any reasonable basis for imagining that
he'll ever learn anything; he's actually made substantially negative
progress over the last few years.
Bill Cunningham
"Keith Thompson" <ks...@mib.org> wrote in message
news:ln7hoct...@nuthaus.mib.org...
> "Bill Cunningham" <nos...@nspam.invalid> writes:
> [...]
>> I think this is where I'm getting it. Interating what a pointer
>> points
>> to. *(ip)+1 is it or (*ip)+1 yields the next value pointed to.
>>
>> Does that make sense?
>
> No.
>
> First, we weren't talking about pointer arithmetic. I suggest
> you don't introduce a new topic until you understand the previous one.
>
> Second, no, neither *(ip)+1 nor (*ip)+1 yields the next value pointed
> to. *(ip+1) does, and it's exactly equivalent to ip[1].
>
> My earlier remark about not typing & or * without understanding what
> they do applies equally to parentheses. At least twice in this
> thread, you've inserted parentheses in seemingly arbitrary and
> incorrect places.
Ok we were talking about &hint being a pointer. Then I asked if there
could be another way of passing this hint as a pointer in a different way.
You replied no why do something else when what works works. I tried to say
there might be *this* way to do it and gave two bad examples concerning
pointer arithmetic. That's how I got onto that topic. I guess there's no
"other" way to do it and I should leave it at that rather than confuse
myself more by trying to make things difficult. That's what I'll do. But yes
you recognized what I was speaking about.
I'll just drop this confusing myself and take for granted that how it's
done is how it's done. I think I am my own worst enemy.
Bill
Keith Thompson
> On 2010-04-12, Keith Thompson <ks...@mib.org> wrote:
>> "Bill Cunningham" <nos...@nspam.invalid> writes:
>> [...]
>> First, we weren't talking about pointer arithmetic. I suggest
>> you don't introduce a new topic until you understand the previous one.
>
> Just to interject...
>
> "Bill Cunningham" has been posting what purport to be questions about
> C for a loooong time. Is trying to get him to understand any concept
> actually more rewarding, in terms of signal/noise, than trying to
> communicate with Nilges?
Probably not.
[snip]
Bill Cunningham
myself. I guess I'm just going to have to go on faith and if that's what the
code says that is what it says. Don't try to do another way just how it
says. I want to before I grasp a topic look at another way to do it for
example,
char *string="hello world\n";
Ok how's another way to do it?
char string[]="hello world\n";
I understand this concept so it's easy. Until I grasp a new concept I better
just leave well enough alone do it how it's done.
I hope I'm making sense.
Bill
Keith Thompson
[...]
> done is how it's done. I think I am my own worst enemy.
You might also consider trying to *understand* how it's done.
Bill Cunningham
> You might also consider trying to *understand* how it's done.
memset() takes as its first parameter a void* and that mean to pass any
type since void is the generic type with the & in front of it. And that's
how it's done.
Bill
Keith Thompson
Since you've shown *some* understanding here, I'll reply.
Rather than saying that void is the generic type (it really isn't),
it's better to say that void* is the generic pointer type.
Applying unary & to the name of an object gives you a pointer to that
object, which can be passed as an argument to a function with a
parameter of type void*.
The phrase "and that mean to pass any type since void is the generic
type with the & in front of it" is, to be blunt, a bit incoherent; I
can't tell from it whether you really understand or not, or if not,
what your remaining misconceptions might be.
pete
> Ok we were talking about &hint being a pointer.
> Then I asked if there
> could be another way of passing this hint as a pointer
> in a different way.
> You replied no why do something else when what works works.
> I tried to say there might be *this* way to do it
> and gave two bad examples concerning pointer arithmetic.
/*
** Here's the long way:
*/
struct addrinfo hints;
int main()
{
struct addrinfo *pointer = &hints;
memset(pointer, '\0', sizeof hints);
--
pete
Kenny McCormack
Keith Thompson <ks...@mib.org> pontificated:
...
>I've told you this before.
And it was worth the same then as it is now (nothing).
Do you honestly think anyone gives a crap about anything you say?
(no matter how many times you say it)
--
(This discussion group is about C, ...)
Wrong. It is only OCCASIONALLY a discussion group
about C; mostly, like most "discussion" groups, it is
off-topic Rorsharch revelations of the childhood
traumas of the participants...
Nick Keighley
On 11 Apr, 22:40, Tucker <noth...@nowhere.net> wrote:> > On 11 Apr,
19:00, "Bill Cunningham" <nos...@nspam.invalid> wrote:
> On 04/11/2010 14:05:13:000 Nick Keighley <nick_keighley_nos...@hotmail.com> wrote:
> > > Oops forgot code.
>
> > oops forgot the question
>
> > > #include <stdio.h>
> > > #include <stdlib.h>
> > > #include <string.h>
> > > #include <sys/types.h>
> > > #include <netdb.h>
> > > #include <sys/socket.h>
>
> > > struct addrinfo hints, *servinfo;
> > > int main()
> > > {
> > > int status;
> > > memset(&hints, '\0', sizeof hints);
>
> > memeset() requires a pointer as the first parameter. The & on the
> > front of hints takes hints address hence &hints /is/ a pointer
>
> hints is not a pointer,
where did I say it was?
but &hints is a pointer. However, &hints is not a variable, so you
can't assign to it.
where did I say it was?
Bill Cunningham
"pete" <pfi...@mindspring.com> wrote in message
news:4BC397...@mindspring.com...
> /*
> ** Here's the long way:
> */
> struct addrinfo hints;
>
> int main()
> {
> struct addrinfo *pointer = &hints;
>
> memset(pointer, '\0', sizeof hints);
Ok now that's familiar to me. Pointer points to an assigned address. So
memset(&hints,'\0',sizeof hints); is a shortcut then? I didn't know you
could shortcut this kind of thing.
Bill
Bill Cunningham
> /*
> ** Here's the long way:
> */
> struct addrinfo hints;
>
> int main()
> {
> struct addrinfo *pointer = &hints;
>
> memset(pointer, '\0', sizeof hints);
Yes that helps alot!
Bill