dereferencing problem

[glen herrmannsfeldt]

On Saturday 12 April 2014 18:36, in comp.lang.c, "Bill Cunningham"
(snip)

Here, you define pa as an object that will contain a pointer to a struct
addrinfo structure.
(snip)
/
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

 

[Ian Collins]

If the OP is lucky, it segfaults.

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

 

[Bill Cunningham]

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

 

[Ian Collins]

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.

 

[Barry Schwarz]

(snip, and previously snipped code using pa)



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.

 

[Barry Schwarz]

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.

 

[Barry Schwarz]

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.

 

[Barry Schwarz]

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.

 

[Bill Cunningham]

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.

 

[Bill Cunningham]

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.

 

[Bill Cunningham]

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

 

[Barry Schwarz]

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

Your final comment suggests you don't

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.

 

[Barry Schwarz]

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.

 

[Barry Schwarz]

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

 

[glen herrmannsfeldt]

Barry Schwarz wrote:
(snip)

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

 

[Osmium]

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.

 

[Les Cargill]

(snip, and previously snipped code using pa)



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.

 

[glen herrmannsfeldt]

(snip, I wrote)

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

 

[Les Cargill]

(snip, I wrote)


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.

 

[Bill Cunningham]

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.