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 2 of 3 — ← Prev page 1 [2] 3  Next page →

#42847

On Saturday 12 April 2014 20:58, in comp.lang.c, "Bill Cunningham"
<nospam@nspam.invalid> wrote:

> 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;

See my previous reply.

Short version: you never put a pointer value into pa, so it doesn't point at
anything. 

-- 
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request

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

#42861

On Sat, 12 Apr 2014 20:30:58 -0400, "Bill Cunningham"
<nospam@nspam.invalid> 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:

Are you saying you cannot understand the documentation for the
compiler system you use?  Your final comment suggests you don't
consider it worthwhile even to try.

-- 
Remove del for email

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

#42880

Barry Schwarz wrote:

> Are you saying you cannot understand the documentation for the
> compiler system you use?

No. Not the last time I looked anyway. And that's been awhile.

 Your final comment suggests you don't
> consider it worthwhile even to try.

I post all my source code in one column.

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

#42884

On Sun, 13 Apr 2014 12:54:15 -0400, "Bill Cunningham"
<nospam@nspam.invalid> wrote:

>Barry Schwarz wrote:
>
>> Are you saying you cannot understand the documentation for the
>> compiler system you use?
>
>No. Not the last time I looked anyway. And that's been awhile.
>
> Your final comment suggests you don't
>> consider it worthwhile even to try.
>
>I post all my source code in one column.

The only C statement that can fit in one column is the null statement
consisting of a single semicolon.  While I recall you coding null
statements in the past, it was usually be accident and incorrect.
However you did not code any in this thread so this is just one more
assertion that is obviously false.

-- 
Remove del for email

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

#42860

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

>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.

Yes smarter ass, I'm definitely not as good as some of the others
here.  That's why when I ask for help I try not to make assumptions
about the problem.  

These messages tell us that your original assertion that the error
occurred on line 7 was wrong.  They also tell us that your assertion
that you only had one dereference was also wrong.

Several people responded telling you that pa had never been assigned a
value.  They were correct but these error messages tell us that the
compiler did not detect this error.  It was complaining about the fact
that while addrinfo was indeed known to be a struct type you had never
provided a complete definition for that type.  So by taking the lazy
way out, you led people down the wrong path.

-- 
Remove del for email

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

#42881

Barry Schwarz wrote:
> On Sat, 12 Apr 2014 20:12:08 -0400, "Bill Cunningham"
> <nospam@nspam.invalid> wrote:
>
>> 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.
>
> Yes smarter ass, I'm definitely not as good as some of the others
> here.  That's why when I ask for help I try not to make assumptions
> about the problem.
>
> These messages tell us that your original assertion that the error
> occurred on line 7 was wrong.  They also tell us that your assertion
> that you only had one dereference was also wrong.
>
> Several people responded telling you that pa had never been assigned a
> value.  They were correct but these error messages tell us that the
> compiler did not detect this error.  It was complaining about the fact
> that while addrinfo was indeed known to be a struct type you had never
> provided a complete definition for that type.  So by taking the lazy
> way out, you led people down the wrong path.

No I didn't. They were right. They were smarter than the compiler. Don't try 
to make me look like I'm trying to deceive people. I was having some 
problems with C In  practical use with BSD sockets.

Bill

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

#42885

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

>Barry Schwarz wrote:
>> On Sat, 12 Apr 2014 20:12:08 -0400, "Bill Cunningham"
>> <nospam@nspam.invalid> wrote:
>>
>>> 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.
>>
>> Yes smarter ass, I'm definitely not as good as some of the others
>> here.  That's why when I ask for help I try not to make assumptions
>> about the problem.
>>
>> These messages tell us that your original assertion that the error
>> occurred on line 7 was wrong.  They also tell us that your assertion
>> that you only had one dereference was also wrong.
>>
>> Several people responded telling you that pa had never been assigned a
>> value.  They were correct but these error messages tell us that the
>> compiler did not detect this error.  It was complaining about the fact
>> that while addrinfo was indeed known to be a struct type you had never
>> provided a complete definition for that type.  So by taking the lazy
>> way out, you led people down the wrong path.
>
>No I didn't. They were right. They were smarter than the compiler. Don't try 
>to make me look like I'm trying to deceive people. I was having some 
>problems with C In  practical use with BSD sockets.

They were correct in identifying an error in your code but it was not
the error you were asking about.  Even after you assign a value to
pointer pa, the compiler would still generate the same diagnostics
since the structure is still incomplete.

I never said you were deliberately trying to deceive people.  I said
that by providing incomplete information they were forced to make what
turned out to be false assumptions.  Only you know if providing the
incomplete data was a deliberate ploy on your part or not.

-- 
Remove del for email

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

#42889

Bill Cunningham <nospam@nspam.invalid> wrote:
> Barry Schwarz wrote:

(snip)
>> Yes smarter ass, I'm definitely not as good as some of the others
>> here.  That's why when I ask for help I try not to make assumptions
>> about the problem.

>> These messages tell us that your original assertion that the error
>> occurred on line 7 was wrong.  They also tell us that your assertion
>> that you only had one dereference was also wrong.

>> Several people responded telling you that pa had never been assigned a
>> value.  They were correct but these error messages tell us that the
>> compiler did not detect this error.  It was complaining about the fact
>> that while addrinfo was indeed known to be a struct type you had never
>> provided a complete definition for that type.  So by taking the lazy
>> way out, you led people down the wrong path.
 
> No I didn't. They were right. They were smarter than the compiler. 
> Don't try to make me look like I'm trying to deceive people. 
> I was having some problems with C In  practical use with BSD sockets.

It does help a lot to give the actual messages early. 

Posting no code, or hundreds of lines for us to search through,
could be considered lazy. 

Compilers should be able to detect that a pointer was never
assigned a value before being used, but many don't. The sample
was small enough that it was pretty easy to see.


-- glen

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

#42844

On Saturday 12 April 2014 18:36, in comp.lang.c, "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;

Here, you define pa as an object that will contain a pointer to a struct
addrinfo structure. 


>     struct addrinfo **pp;
>     int v;
> 
>     pa->ai_family = AF_INET;
     /
Here, you try to stuff some data into an object that is accessed through the
pa pointer.

>     pa->ai_socktype = SOCK_DGRAM;
        /
And here

>     pa->ai_protocol = 0;
        /
And here

>     pa->ai_next = NULL;
        /
And here

But, you never actually populate pa with an address. So all of these
attempts to put data into objects pointed to by pa will result in errors,
because pa *doesn't point at anything*.

>     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;
> }
> 
> 


-- 
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request

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

#42846

Lew Pitcher wrote:
> On Saturday 12 April 2014 18:36, in comp.lang.c, "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;
>
> Here, you define pa as an object that will contain a pointer to a struct
> addrinfo structure.

I guess there's always one who falls into the trap....

-- 
Ian Collins

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

#42849

On Saturday 12 April 2014 21:03, in comp.lang.c, "Ian Collins"
<ian-news@hotmail.com> wrote:

> Lew Pitcher wrote:
>> On Saturday 12 April 2014 18:36, in comp.lang.c, "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;
>>
>> Here, you define pa as an object that will contain a pointer to a struct
>> addrinfo structure.
> 
> I guess there's always one who falls into the trap....

... Meh ...

-- 
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request

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

#42850

Lew Pitcher <lew.pitcher@digitalfreehold.ca> wrote:
> On Saturday 12 April 2014 18:36, in comp.lang.c, "Bill Cunningham"

(snip)

>>     struct addrinfo *pa;
 
> Here, you define pa as an object that will contain a pointer to a struct
> addrinfo structure. 

(snip)
>>     pa->ai_family = AF_INET;
>     /
> Here, you try to stuff some data into an object that is 
> accessed through the pa pointer.

(snip)

> But, you never actually populate pa with an address. So all of these
> attempts to put data into objects pointed to by pa will result in errors,
> because pa *doesn't point at anything*.

If the OP is lucky, it segfaults.

If not, it stores it some place in memory where something else is
supposed to be, causing strange effects sometime later.

Not noticing the missing #include before, this is what I wrote
about previously.

-- glen

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

#42851

glen herrmannsfeldt wrote:
>
> If the OP is lucky, it segfaults.

The OP isn't lucky, he's a troll!

-- 
Ian Collins

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

#42852

Lew Pitcher wrote:

> But, you never actually populate pa with an address. So all of these
> attempts to put data into objects pointed to by pa will result in
> errors, because pa *doesn't point at anything*.
[snip]

Ok so how exactly am I going to correct this? Using memset or malloc ? Or 
using that ampersand? I understand what's wrong, but I need to know how to 
correct it.


Bill

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

#42853

Bill Cunningham wrote:
> Lew Pitcher wrote:
>
>> But, you never actually populate pa with an address. So all of these
>> attempts to put data into objects pointed to by pa will result in
>> errors, because pa *doesn't point at anything*.
> [snip]
>
> Ok so how exactly am I going to correct this? Using memset or malloc ? Or
> using that ampersand? I understand what's wrong, but I need to know how to
> correct it.

Look back at some of your near identical posts and re-read the answers.

-- 
Ian Collins

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

#42862

On Sat, 12 Apr 2014 21:25:52 -0400, "Bill Cunningham"
<nospam@nspam.invalid> wrote:

>Lew Pitcher wrote:
>
>> But, you never actually populate pa with an address. So all of these
>> attempts to put data into objects pointed to by pa will result in
>> errors, because pa *doesn't point at anything*.
>[snip]
>
>Ok so how exactly am I going to correct this? Using memset or malloc ? Or 
>using that ampersand? I understand what's wrong, but I need to know how to 
>correct it.

Even you cannot believe that memset is a suitable replacement for
malloc or the reverse.

-- 
Remove del for email

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

#42879

Barry Schwarz wrote:

> Even you cannot believe that memset is a suitable replacement for
> malloc or the reverse.

    malloc is good. memset was shown in the code so I assume they know best. 
You know I certainly don't. So well...malloc is good.

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

#42886

On Sun, 13 Apr 2014 12:50:42 -0400, "Bill Cunningham"
<nospam@nspam.invalid> wrote:

>Barry Schwarz wrote:
>
>> Even you cannot believe that memset is a suitable replacement for
>> malloc or the reverse.
>
>    malloc is good. memset was shown in the code so I assume they know best. 
>You know I certainly don't. So well...malloc is good.

Nowhere in the code you posted was memset used.  I have no idea why
you introduced it in two different messages as a possible substitute
for either free or malloc

-- 
Remove del for email

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

#42891

"Barry Schwarz" wrote:

> On Sun, 13 Apr 2014 12:50:42 -0400, "Bill Cunningham"
> <nospam@nspam.invalid> wrote:
>
>>Barry Schwarz wrote:
>>
>>> Even you cannot believe that memset is a suitable replacement for
>>> malloc or the reverse.
>>
>>    malloc is good. memset was shown in the code so I assume they know 
>> best.
>>You know I certainly don't. So well...malloc is good.
>
> Nowhere in the code you posted was memset used.  I have no idea why
> you introduced it in two different messages as a possible substitute
> for either free or malloc

Introducing a more or less random word from "the biz" is one of Bill's 
trademarks.
Perhaps you are seeing the handiwork of  a Beautiful Mind?  Only a guy who 
can tell what Napoleon ate at  his last meal by analyzing a single Napoleon 
head hair could figure Bill out. 

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

#42904

Barry Schwarz wrote:

> Nowhere in the code you posted was memset used.  I have no idea why
> you introduced it in two different messages as a possible substitute
> for either free or malloc

http://linux.die.net/man/3/getaddrinfo

Not seeing this or not knowing about it now is lazy. 

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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

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

csiph-web