Learned something new today - thoughts?

[James Lee]

Hi,

char **ipaddress;

ipaddress = malloc(N * sizeof(char*));

for (i=0; ;i++) {
ipaddress = fxn_that_returns_pointer_to_char;
}

Here, I learned that I don't have to specify N. I can simply do:

ipaddress = malloc(sizeof(char*));

And everything works fine. I guess you just give it the first address
of pointer-to-char and that's all you need to do? I've always thought
that you have to specify how many pointer-to-chars as a lot of
examples do. Any drawback to not specifying N? In my case, I don't
know what N is. FYI, fxn_that_returns_pointer_to_char takes care of
allocating memory for chars.

Thanks!

-j.

 

[Martijn]

char **ipaddress;

ipaddress = malloc(N * sizeof(char*));

for (i=0; ;i++) {
ipaddress = fxn_that_returns_pointer_to_char;
}

Here, I learned that I don't have to specify N. I can simply do:

That is an infinate loop (so no matter what N is, you will most likely get a
SEGFAULT at some point)...

ipaddress = malloc(sizeof(char*));

And everything works fine. I guess you just give it the first address
of pointer-to-char and that's all you need to do? I've always thought
that you have to specify how many pointer-to-chars as a lot of
examples do. Any drawback to not specifying N? In my case, I don't
know what N is. FYI, fxn_that_returns_pointer_to_char takes care of
allocating memory for chars.

But in the case of omitting N nothing takes care of allocating memory for
the char* (at least for more than one). So although it might work in some
cases, it is likely not to work in others, because you will be writing to
memory that's "not yours". Possibly, if you did another malloc, writing to
ipaddress, where i is greater than 0 could, will overwrite data in the
newly allocated block.

 

[Andreas Kahari]

Hi,

char **ipaddress;

ipaddress = malloc(N * sizeof(char*));

for (i=0; ;i++) {

I suppose you left out the loop condition by mistake. It ought
to say "i < N".

ipaddress = fxn_that_returns_pointer_to_char;
}

Here, I learned that I don't have to specify N. I can simply do:

ipaddress = malloc(sizeof(char*));

That gives you enough space to store one pointer to char in
ipaddress[0], but you're not allowed to use ipaddress[n], for n
not equal to 0, in any way whatsoever.

It might work on your machine right now, and tomorrow, but it's
sure not a good thing to go outside the allocated space. Bad
indeed.

 

[Mike Wahler]

Hi,

char **ipaddress;

ipaddress = malloc(N * sizeof(char*));

You should check for success/failure here.

for (i=0; ;i++) {
ipaddress = fxn_that_returns_pointer_to_char;
}

You have an infinite loop (no termination condition
specified). This will eventually blow up. You have no way to
stop the loop, so it will eventually write outside
your array (when 'i' becomes equal to 'N'). Undefined behavior.

Here, I learned that I don't have to specify N.

No, you did not learn that. How you came to that
conclusion is beyond me.

I can simply do:

ipaddress = malloc(sizeof(char*));

That allocates storage for a single pointer.
ipaddress[0] is the only element in your array.

And everything

seems like it

works fine. I guess you just give it the first address
of pointer-to-char and that's all you need to do?

No. If you want to store an object, memory must
be provided. malloc(sizeof(char*)) only gives
enough memory for a *single* pointer.

I've always thought
that you have to specify how many pointer-to-chars as a lot of
examples do.

Yes, if you want to allocate memory for 'N' objects,
you must multiply N by the object's type's size for
the argument to 'malloc()' (except in case of allocating
type 'char' objects, because sizeof(char) is one by
definition.)

char *p = malloc(1000); /* room for 1000 characters */
int *pi = malloc(1000 * sizeof *pi); /* room for 1000 integers */

Any drawback to not specifying N?

Yes, undefined behavior.

In my case, I don't
know what N is.

Then who does? You can supply any nonnegative
integral value. This might be from within your
code, or perhaps from the user.

FYI, fxn_that_returns_pointer_to_char takes care of
allocating memory for chars.

But you've only allocated enough memory for a single
pointer to point to your multiple pointers to chars.

BTW if 'fxn...' allocates the storage, who deallocates it?
This is important.

A pointer is an object, just like any other type,
and must have storage allotted for it.

Do not use a compiler's behavior to determine language
correctness.

What C text(s) are you reading?

-Mike

 

[Mark Gordon]

On 25 Sep 2003 14:59:09 -0700

Hi,

char **ipaddress;

ipaddress = malloc(N * sizeof(char*));

ipaddress = malloc(N * sizeof *ipaddress);
would be better as it means you don't have to change it if the type of
ipaddress is changed.

for (i=0; ;i++) {
ipaddress = fxn_that_returns_pointer_to_char;
}

Here, I learned that I don't have to specify N. I can simply do:

ipaddress = malloc(sizeof(char*));

And everything works fine. I guess you just give it the first address
of pointer-to-char and that's all you need to do? I've always thought
that you have to specify how many pointer-to-chars as a lot of
examples do. Any drawback to not specifying N? In my case, I don't
know what N is. FYI, fxn_that_returns_pointer_to_char takes care of
allocating memory for chars.

The downside of specifying less memory than you require is that you
might be trampling over anything such as data used in maintaining the
heap or other data you own. It could also cause you computer to burst in
to explode with enough force to destroy all buildings withing 30000km.

If your program does not know who much memory will be required when it
reaches the malloc then you can use realloc later to increase the size
(remembering it might move) later in the program.

 

[Micah Cowan]

Hi,

char **ipaddress;

ipaddress = malloc(N * sizeof(char*));

for (i=0; ;i++) {
ipaddress = fxn_that_returns_pointer_to_char;
}

Here, I learned that I don't have to specify N. I can simply do:

ipaddress = malloc(sizeof(char*));

And everything works fine.

Huh. Only if N is one. Of course, you're actually initializing
infinite char*s, so N is infinity. You're screwed.

-Micah

 

[James Lee]

Hi,

char **ipaddress;

ipaddress = malloc(N * sizeof(char*));

for (i=0; ;i++) {
ipaddress = fxn_that_returns_pointer_to_char;
}

Here, I learned that I don't have to specify N. I can simply do:

ipaddress = malloc(sizeof(char*));

And everything works fine. I guess you just give it the first address
of pointer-to-char and that's all you need to do? I've always thought
that you have to specify how many pointer-to-chars as a lot of
examples do. Any drawback to not specifying N? In my case, I don't
know what N is. FYI, fxn_that_returns_pointer_to_char takes care of
allocating memory for chars.

Thanks!

-j.

Thanks everyone for your response. Man, I didn't think you'll be so
critical of the snippet I posted. Obviously, I was only trying to
get the point across. I do not have infinite loop anywhere and yes I
free everything I allocate (or I try to at least).

I do not know how many sizeof(char*)'s to allocate b/c I never know
how many machines are going to respond to UDP broadcast message that I
am sending out. I'd like to keep a list of ip addresses (non-sorted).
I guess I can keep a linked-list for this but if I were to do it this
way, would realloc be the solution to my problem?

I really appreciate all your opinions/feedback and help. Thanks.

-j.

 

[Mike Wahler]

(e-mail address removed) (James Lee) wrote in message

Hi,

char **ipaddress;

ipaddress = malloc(N * sizeof(char*));

for (i=0; ;i++) {
ipaddress = fxn_that_returns_pointer_to_char;
}

Here, I learned that I don't have to specify N. I can simply do:

ipaddress = malloc(sizeof(char*));

And everything works fine. I guess you just give it the first address
of pointer-to-char and that's all you need to do? I've always thought
that you have to specify how many pointer-to-chars as a lot of
examples do. Any drawback to not specifying N? In my case, I don't
know what N is. FYI, fxn_that_returns_pointer_to_char takes care of
allocating memory for chars.

Thanks!

-j.

Thanks everyone for your response. Man, I didn't think you'll be so
critical of the snippet I posted.

That's what we do here.
Seriously, though, criticism is a good thing.

Obviously, I was only trying to
get the point across.

Not very well, imo.

I do not have infinite loop anywhere

You do in the code you posted. Better to post
'real' code than try to 'describe' with
incomplete fragments. Compilable code is
best, then we can test it.

and yes I
free everything I allocate (or I try to at least).

No need to only 'try'. Just Do It.

I do not know how many sizeof(char*)'s to allocate b/c I never know
how many machines are going to respond to UDP broadcast message that I
am sending out.

You can use 'realloc()' to increase the size of already
allocated storage.

I'd like to keep a list of ip addresses (non-sorted).
I guess I can keep a linked-list for this

Yes, you could.

but if I were to do it this
way, would realloc be the solution to my problem?

It would be one solution, yes.

-Mike

 

[Lew Pitcher]

James Lee wrote:
[snip]

Thanks everyone for your response. Man, I didn't think you'll be so
critical of the snippet I posted. Obviously, I was only trying to
get the point across. I do not have infinite loop anywhere and yes I
free everything I allocate (or I try to at least).

I do not know how many sizeof(char*)'s to allocate b/c I never know
how many machines are going to respond to UDP broadcast message that I
am sending out.

Unfortunately, you're either going to /have/ to know, or you are going to have
to reallocate your allocated memory with each overflow.

One suggestion: since you're sending a UDP broadcast message and gathering
responses, you do have an upper limit to the number of responses. Assuming that
you are'nt using a multicast group, then you are limited to the number of
interfaces on your subnet minus two. You could just allocate /this/ many
entries, and fill the ones you receive.

The other way would be to allocate a block, and when you get to an overflow
condition, realloc() the block larger.

I'd like to keep a list of ip addresses (non-sorted).
I guess I can keep a linked-list for this but if I were to do it this
way, would realloc be the solution to my problem?

I really appreciate all your opinions/feedback and help. Thanks.

-j.

--
Lew Pitcher

Master Codewright and JOAT-in-training
Registered Linux User #112576 (http://counter.li.org/)
Slackware - Because I know what I'm doing.

 

[Martijn]

Unfortunately, you're either going to /have/ to know, or you are
going to have to reallocate your allocated memory with each overflow.
[snipped]

The other way would be to allocate a block, and when you get to an
overflow condition, realloc() the block larger.

This is what I would do - I've always learned to optimize for the most
common results. I think it is save to assume that class C or smaller
networks are most common and thus to be expected - so start with a buffer
size 256 (which is actually two too many) and double this buffer each time
it is overflown, eventually covering B and A networks as well.