Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #42825 > unrolled thread

dereferencing problem

Back to article view | Back to comp.lang.c

Contents

  dereferencing problem "Bill Cunningham" <nospam@nspam.invalid> - 2014-04-12 18:13 -0400
    Re: dereferencing problem "Bill Cunningham" <nospam@nspam.invalid> - 2014-04-12 18:36 -0400
      Re: dereferencing problem "Bill Cunningham" <nospam@nspam.invalid> - 2014-04-12 18:56 -0400
        Re: dereferencing problem glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-12 23:16 +0000
          Re: dereferencing problem "Bill Cunningham" <nospam@nspam.invalid> - 2014-04-12 19:52 -0400
          Re: dereferencing problem "Bill Cunningham" <nospam@nspam.invalid> - 2014-04-12 19:57 -0400
            Re: dereferencing problem Barry Schwarz <schwarzb@dqel.com> - 2014-04-13 01:00 -0700
          Re: dereferencing problem Les Cargill <lcargill99@comcast.com> - 2014-04-14 01:10 -0500
            Re: dereferencing problem glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-14 06:50 +0000
              Re: dereferencing problem Les Cargill <lcargill99@comcast.com> - 2014-04-14 07:42 -0500
              Re: dereferencing problem "Charles Richmond" <numerist@aquaporin4.com> - 2014-04-14 14:36 -0500
                Re: dereferencing problem glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-14 20:10 +0000
      Re: dereferencing problem Barry Schwarz <schwarzb@dqel.com> - 2014-04-12 16:50 -0700
        Re: dereferencing problem "Bill Cunningham" <nospam@nspam.invalid> - 2014-04-12 20:12 -0400
          Re: dereferencing problem "Bill Cunningham" <nospam@nspam.invalid> - 2014-04-12 20:30 -0400
            Re: dereferencing problem Richard Damon <Richard@Damon-Family.org> - 2014-04-12 20:39 -0400
              Re: dereferencing problem "Bill Cunningham" <nospam@nspam.invalid> - 2014-04-12 21:01 -0400
                Re: dereferencing problem Ian Collins <ian-news@hotmail.com> - 2014-04-13 13:02 +1200
            Re: dereferencing problem Ian Collins <ian-news@hotmail.com> - 2014-04-13 12:53 +1200
            Re: dereferencing problem "Bill Cunningham" <nospam@nspam.invalid> - 2014-04-12 20:58 -0400
              Re: dereferencing problem Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2014-04-12 21:04 -0400
            Re: dereferencing problem Barry Schwarz <schwarzb@dqel.com> - 2014-04-13 01:13 -0700
              Re: dereferencing problem "Bill Cunningham" <nospam@nspam.invalid> - 2014-04-13 12:54 -0400
                Re: dereferencing problem Barry Schwarz <schwarzb@dqel.com> - 2014-04-13 14:14 -0700
          Re: dereferencing problem Barry Schwarz <schwarzb@dqel.com> - 2014-04-13 01:12 -0700
            Re: dereferencing problem "Bill Cunningham" <nospam@nspam.invalid> - 2014-04-13 12:57 -0400
              Re: dereferencing problem Barry Schwarz <schwarzb@dqel.com> - 2014-04-13 14:22 -0700
              Re: dereferencing problem glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-13 22:18 +0000
      Re: dereferencing problem Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2014-04-12 21:02 -0400
        Re: dereferencing problem Ian Collins <ian-news@hotmail.com> - 2014-04-13 13:03 +1200
          Re: dereferencing problem Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2014-04-12 21:07 -0400
        Re: dereferencing problem glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2014-04-13 01:18 +0000
          Re: dereferencing problem Ian Collins <ian-news@hotmail.com> - 2014-04-13 13:19 +1200
        Re: dereferencing problem "Bill Cunningham" <nospam@nspam.invalid> - 2014-04-12 21:25 -0400
          Re: dereferencing problem Ian Collins <ian-news@hotmail.com> - 2014-04-13 13:30 +1200
          Re: dereferencing problem Barry Schwarz <schwarzb@dqel.com> - 2014-04-13 01:18 -0700
            Re: dereferencing problem "Bill Cunningham" <nospam@nspam.invalid> - 2014-04-13 12:50 -0400
              Re: dereferencing problem Barry Schwarz <schwarzb@dqel.com> - 2014-04-13 14:24 -0700
                Re: dereferencing problem "Osmium" <r124c4u102@comcast.net> - 2014-04-13 18:48 -0500
                Re: dereferencing problem "Bill Cunningham" <nospam@nspam.invalid> - 2014-04-14 14:46 -0400
                  Re: dereferencing problem "Bill Cunningham" <nospam@nspam.invalid> - 2014-04-14 15:58 -0400
                    Re: dereferencing problem "Bill Cunningham" <nospam@nspam.invalid> - 2014-04-14 16:08 -0400
          Re: dereferencing problem Herbert Rosenau <os2guy@pc-rosenau.de> - 2014-05-03 14:19 +0200
            Re: dereferencing problem "Bill Cunningaham" <nospam@nspam.invalid> - 2014-05-03 11:29 -0400
              Re: dereferencing problem "Bill Cunningaham" <nospam@nspam.invalid> - 2014-05-03 11:42 -0400
            Re: dereferencing problem Richard <rgrdev_@gmail.com> - 2014-05-03 21:15 +0200
    Re: dereferencing problem Ian Collins <ian-news@hotmail.com> - 2014-04-13 11:15 +1200

Page 1 of 3  [1] 2 3  Next page →

#42825 — dereferencing problem

    My compiler is complaining about line 7 I am pretty sure and is saying 
something about dereferencing. The only dereference I intend in my code is 
being passed to the freeaddrinfo(). Beause it wants a struct addrinfo *. Now 
I am intending to declare a pointer to pointer in that line 7. This compiled 
the other day when I was working on something very similar. I know these 
aren't standard functions but dereferencing is standard C. What am I doing 
wrong. I forgot to save the compiler warnings to stderr but someone good 
enough can probably see what the problem is.

Whew.

Bill

[toc] | [next] | [standalone]

#42826

Bill Cunningham wrote:
[...]

Oh Duh. I need to post code. Long day.

#include <stdio.h>
#include <sys/socket.h>

int main()
{
    struct addrinfo *pa;
    struct addrinfo **pp;
    int v;

    pa->ai_family = AF_INET;
    pa->ai_socktype = SOCK_DGRAM;
    pa->ai_protocol = 0;
    pa->ai_next = NULL;
    v = getaddrinfo(NULL, "80", pa, pp);
    if (v == -1)
 fprintf(stderr, "%s\n", gai_strerror(v));
    else {
 fprintf(stderr, "%s\n", gai_strerror(v));
    }
    freeaddrinfo(*pp);
    return 0;
}

[toc] | [prev] | [next] | [standalone]

#42828

Stefan Ram wrote:
> "Bill Cunningham" <nospam@nspam.invalid> writes:
>> struct addrinfo *pa;
> ...
>> pa->ai_family = AF_INET;
>
>  »pa«, in »pa->ai_family«, is assumed to point to writeable
>  memory, but »pa« was not initialized. »pa->« means »(*pa).«,
>  thus, dereferencing.

    Ok. You say pa is uninitialized. Hum. All I know is the rest of the 
elements pointed to work. Well ai_family element is full. I assigned it 
properly or at least the way I meant to. I am glad to see the problem wasn't 
with the freeddrinfo function. I did intend a dereference.
I meant initialization with the line...

struct addrinfo *pa;

A pointer to a struct addrinfo type. Is my syntax wrong?

Bill

[toc] | [prev] | [next] | [standalone]

#42831

Bill Cunningham <nospam@nspam.invalid> wrote:

(snip, and previously snipped code using pa)

> struct addrinfo *pa;
 
> A pointer to a struct addrinfo type. Is my syntax wrong?

Syntax is right. That declares pa as a pointer, but doesn't
point it to anything.

One way is to have a struct addrinfo, and use &.

struct addrinfo a;
struct addrinfo *pa=&a;
(or assign it on another line)

Since addrinfo is small, that is probably the best way,
but some will malloc() it.

struct addrinfo *pa;
pa=malloc(sizeof(*pa));

then you should remember to free() it later. 

I think pp should also point to something before the call, or
be & of something, but you didn't (yet) ask about that.

-- glen

[toc] | [prev] | [next] | [standalone]

#42834

glen herrmannsfeldt wrote:
> Bill Cunningham <nospam@nspam.invalid> wrote:
>
> (snip, and previously snipped code using pa)
>
>> struct addrinfo *pa;
>
>> A pointer to a struct addrinfo type. Is my syntax wrong?
>
> Syntax is right. That declares pa as a pointer, but doesn't
> point it to anything.
>
> One way is to have a struct addrinfo, and use &.
>
> struct addrinfo a;
> struct addrinfo *pa=&a;
> (or assign it on another line)
>
> Since addrinfo is small, that is probably the best way,
> but some will malloc() it.
>
> struct addrinfo *pa;
> pa=malloc(sizeof(*pa));
>
> then you should remember to free() it later.
>
> I think pp should also point to something before the call, or
> be & of something, but you didn't (yet) ask about that.

    So that's why they're using that ampersand in the function calls that 
require pointers. I thought it was because they just weren't wanting to use 
pointers and they declare something like this...
struct addrinfo sa;
Which is an instance of that type and not a pointer. In the code I've been 
reading getaddrinfo's third paramter is calling for a pointer. So I just 
passed it pa. My understanding is somewhat off.

Bill

[toc] | [prev] | [next] | [standalone]

#42835

glen herrmannsfeldt wrote:
> Bill Cunningham <nospam@nspam.invalid> wrote:
>
> (snip, and previously snipped code using pa)
>
>> struct addrinfo *pa;
>
>> A pointer to a struct addrinfo type. Is my syntax wrong?
>
> Syntax is right. That declares pa as a pointer, but doesn't
> point it to anything.
>
> One way is to have a struct addrinfo, and use &.
>
> struct addrinfo a;
> struct addrinfo *pa=&a;
> (or assign it on another line)
>
> Since addrinfo is small, that is probably the best way,
> but some will malloc() it.
>
> struct addrinfo *pa;
> pa=malloc(sizeof(*pa));
>
> then you should remember to free() it later.
[snip]

Or use memset! Like memset (pa,0,sizeof (struct addrinfo)); Since it takes a 
pointer. Or maybe I should use memset(&pa,0,sizeof(struct addrinfo));
Which would I use and why?

Bill

[toc] | [prev] | [next] | [standalone]

#42859

On Sat, 12 Apr 2014 19:57:20 -0400, "Bill Cunningham"
<nospam@nspam.invalid> wrote:

>glen herrmannsfeldt wrote:
>> Bill Cunningham <nospam@nspam.invalid> wrote:
>>
>> (snip, and previously snipped code using pa)
>>
>>> struct addrinfo *pa;
>>
>>> A pointer to a struct addrinfo type. Is my syntax wrong?
>>
>> Syntax is right. That declares pa as a pointer, but doesn't
>> point it to anything.
>>
>> One way is to have a struct addrinfo, and use &.
>>
>> struct addrinfo a;
>> struct addrinfo *pa=&a;
>> (or assign it on another line)
>>
>> Since addrinfo is small, that is probably the best way,
>> but some will malloc() it.
>>
>> struct addrinfo *pa;
>> pa=malloc(sizeof(*pa));
>>
>> then you should remember to free() it later.
>[snip]
>
>Or use memset! Like memset (pa,0,sizeof (struct addrinfo)); Since it takes a 
>pointer. Or maybe I should use memset(&pa,0,sizeof(struct addrinfo));
>Which would I use and why?

What on earth makes you think that memset is a suitable substitute for
free?    Or that the two are even related?

Your second example causes a memory leak if the structure is
dynamically allocated instead of defined.  It also causes undefined
behavior whenever the size of the structure is greater than the size
of the pointer.

-- 
Remove del for email

[toc] | [prev] | [next] | [standalone]

#42893

glen herrmannsfeldt wrote:
> Bill Cunningham <nospam@nspam.invalid> wrote:
>
> (snip, and previously snipped code using pa)
>
>> struct addrinfo *pa;
>
>> A pointer to a struct addrinfo type. Is my syntax wrong?
>
> Syntax is right. That declares pa as a pointer, but doesn't
> point it to anything.
>
> One way is to have a struct addrinfo, and use &.
>
> struct addrinfo a;
> struct addrinfo *pa=&a;
> (or assign it on another line)
>
> Since addrinfo is small, that is probably the best way,
> but some will malloc() it.
>

Or declare it static. We're in main ( not that it really
matters ) .

> struct addrinfo *pa;
> pa=malloc(sizeof(*pa));
>
> then you should remember to free() it later.
>
> I think pp should also point to something before the call,

I think so too.

> or
> be & of something, but you didn't (yet) ask about that.
>
> -- glen
>
>
>

-- 
Les Cargill

[toc] | [prev] | [next] | [standalone]

#42894

Les Cargill <lcargill99@comcast.com> wrote:

(snip, I wrote)
>> Syntax is right. That declares pa as a pointer, but doesn't
>> point it to anything.

>> One way is to have a struct addrinfo, and use &.

>> struct addrinfo a;
>> struct addrinfo *pa=&a;
>> (or assign it on another line)

>> Since addrinfo is small, that is probably the best way,
>> but some will malloc() it.

> Or declare it static. We're in main ( not that it really
> matters ) .

Well, they could be different. auto should be allocated on the
stack, though it will stay there the whole time (until main
returns). 

Also, some systems have unusual restrictions on static storage.
Some years ago in an Alpha/OSF1 system with 16GB RAM, I tried 
to allocate and initialize a 100k byte static array. 

That was too big.

I think I just made it smaller, but maybe auto instead.

-- glen

[toc] | [prev] | [next] | [standalone]

#42897

glen herrmannsfeldt wrote:
> Les Cargill <lcargill99@comcast.com> wrote:
>
> (snip, I wrote)
>>> Syntax is right. That declares pa as a pointer, but doesn't
>>> point it to anything.
>
>>> One way is to have a struct addrinfo, and use &.
>
>>> struct addrinfo a;
>>> struct addrinfo *pa=&a;
>>> (or assign it on another line)
>
>>> Since addrinfo is small, that is probably the best way,
>>> but some will malloc() it.
>
>> Or declare it static. We're in main ( not that it really
>> matters ) .
>
> Well, they could be different. auto should be allocated on the
> stack, though it will stay there the whole time (until main
> returns).
>
> Also, some systems have unusual restrictions on static storage.
> Some years ago in an Alpha/OSF1 system with 16GB RAM, I tried
> to allocate and initialize a 100k byte static array.
>
> That was too big.
>

How bizarre. 64kbyte limitation? I thought the Alpha was a 64 bit 
machine - at least true 32 bit.

You'd think toolchains would *encourage* static allocation since it's 
the most conservative way.

> I think I just made it smaller, but maybe auto instead.
>
> -- glen
>

-- 
Les Cargill

[toc] | [prev] | [next] | [standalone]

#42907

"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message 
news:lig0g2$hji$1@speranza.aioe.org...
>
>        [snip...]                       [snip...] 
> [snip...]
>
> Also, some systems have unusual restrictions on static storage.
> Some years ago in an Alpha/OSF1 system with 16GB RAM, I tried
> to allocate and initialize a 100k byte static array.
>

Glen, "some years ago" your Alpha workstation had 16 GB??? Maybe you meant 
16 Meg.

--

numerist at aquaporin4 dot com

[toc] | [prev] | [next] | [standalone]

#42911

Charles Richmond <numerist@aquaporin4.com> wrote:

(snip, I wrote)
>> Also, some systems have unusual restrictions on static storage.
>> Some years ago in an Alpha/OSF1 system with 16GB RAM, I tried
>> to allocate and initialize a 100k byte static array.
 
> Glen, "some years ago" your Alpha workstation had 16 GB??? 
> Maybe you meant 16 Meg.

Alpha is a 64 bit system, and tended to be used where you needed
a lot of RAM.  I didn't (at the time) know all that much about
the machine, but that it did have 16GB.

The machine bought for the project was a four processor Dell (IA32)
that our project manager tried to buy 16GB for, but could only get 4GB.
That was about 2000 or 2001 for a time frame. 

A few years earlier, I had an 8MB 80486 machine that I put
FreeBSD on to use as our network NAT router. At that time, 
people laughed that there was any use for an 8MB machine, but
it made a fine router.  As I remember, I got a new disk for
the machine, and made a 1GB swap partition.  The only time I
have known to have swap space 128 time actual RAM.

Somehow the system that either Alpha, or the particular OS/compiler
implementation, only allowed 64K for static storage. With malloc()
I could get many GB.

-- glen

[toc] | [prev] | [next] | [standalone]

#42833

On Sat, 12 Apr 2014 18:36:02 -0400, "Bill Cunningham"
<nospam@nspam.invalid> wrote:

>Bill Cunningham wrote:
>[...]
>
>Oh Duh. I need to post code. Long day.
>
>#include <stdio.h>
>#include <sys/socket.h>
>
>int main()
>{
>    struct addrinfo *pa;
>    struct addrinfo **pp;
>    int v;
>
>    pa->ai_family = AF_INET;
>    pa->ai_socktype = SOCK_DGRAM;
>    pa->ai_protocol = 0;
>    pa->ai_next = NULL;
>    v = getaddrinfo(NULL, "80", pa, pp);
>    if (v == -1)
> fprintf(stderr, "%s\n", gai_strerror(v));
>    else {
> fprintf(stderr, "%s\n", gai_strerror(v));
>    }
>    freeaddrinfo(*pp);
>    return 0;
>}

It only took two tries for you to post the code.  How many before you
post the actual error message?

-- 
Remove del for email

[toc] | [prev] | [next] | [standalone]

#42837

Barry Schwarz wrote:

> It only took two tries for you to post the code.  How many before you
> post the actual error message?

All right smart ass. As I explained in my first post it would've been proper 
I admit to have posted what you want. But I forgot and didn't think it was 
necessary. But since you asked here it is. Sorry I forgot. It happens.

p.c: In function 'main':
p.c:10:7: error: dereferencing pointer to incomplete type
p.c:11:7: error: dereferencing pointer to incomplete type
p.c:12:7: error: dereferencing pointer to incomplete type
p.c:13:7: error: dereferencing pointer to incomplete type

If that tells you something your better than me. If you need this then 
you're not as good as some.

Bill

[toc] | [prev] | [next] | [standalone]

#42839

Stefan Ram wrote:
> "Bill Cunningham" <nospam@nspam.invalid> writes:
>> p.c: In function 'main':
>> p.c:10:7: error: dereferencing pointer to incomplete type
>> p.c:11:7: error: dereferencing pointer to incomplete type
>> p.c:12:7: error: dereferencing pointer to incomplete type
>> p.c:13:7: error: dereferencing pointer to incomplete type
>
>  This might suggest to
>
> #include <netdb.h>

    Are those first numbers line numbers? Why is 7 memntioned in every line. 
I thought 7 was a line number. :shrug:

Bill

[toc] | [prev] | [next] | [standalone]

#42840

On 4/12/14, 8:30 PM, Bill Cunningham wrote:
> Stefan Ram wrote:
>> "Bill Cunningham" <nospam@nspam.invalid> writes:
>>> p.c: In function 'main':
>>> p.c:10:7: error: dereferencing pointer to incomplete type
>>> p.c:11:7: error: dereferencing pointer to incomplete type
>>> p.c:12:7: error: dereferencing pointer to incomplete type
>>> p.c:13:7: error: dereferencing pointer to incomplete type
>>
>>  This might suggest to
>>
>> #include <netdb.h>
> 
>     Are those first numbers line numbers? Why is 7 memntioned in every line. 
> I thought 7 was a line number. :shrug:
> 
> Bill
> 
> 

That is file: p.c
line number 10 (11, 12, 13)
column 7

Which indicates that it doesn't have a definition for the type that pa
is pointing to, i.e. addrinfo.

[toc] | [prev] | [next] | [standalone]

#42843

Richard Damon wrote:

> Which indicates that it doesn't have a definition for the type that pa
> is pointing to, i.e. addrinfo.

Ok I checked and addrinfo is defined in netdb.h for some reason. I thought 
that header was just for get* functions from files in the /etc directory 
like protocols and service and so on. But the man page included it so I 
should have. What does column mean? Thanks much.

Bill

[toc] | [prev] | [next] | [standalone]

#42845

Bill Cunningham wrote:
> What does column mean? Thanks much.

Do you have access to a dictionary?

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#42841

Bill Cunningham wrote:
> Stefan Ram wrote:
>> "Bill Cunningham" <nospam@nspam.invalid> writes:
>>> p.c: In function 'main':
>>> p.c:10:7: error: dereferencing pointer to incomplete type
>>> p.c:11:7: error: dereferencing pointer to incomplete type
>>> p.c:12:7: error: dereferencing pointer to incomplete type
>>> p.c:13:7: error: dereferencing pointer to incomplete type
>>
>>   This might suggest to
>>
>> #include <netdb.h>
>
>      Are those first numbers line numbers? Why is 7 memntioned in every line.
> I thought 7 was a line number. :shrug:

After, what at decade or more, you still haven't worked this out?

There be trolls...
-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#42842

Bill Cunningham wrote:
> Stefan Ram wrote:
>> "Bill Cunningham" <nospam@nspam.invalid> writes:
>>  This might suggest to
>>
>> #include <netdb.h>
[snip]

Ok I included that header and the code compiled but when it was run it seg 
faulted. I compiled with debugging code the debugger said line 11 and that 
was the line previously mentioned supra that is:

pa->ai_family=AF_INET;

Bill

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.c

csiph-web