Learned something new today - thoughts?

Discussion in 'C Programming' started by James Lee, Sep 25, 2003.

  1. James Lee

    James Lee Guest

    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.
     
    James Lee, Sep 25, 2003
    #1
    1. Advertising

  2. James Lee

    Martijn Guest

    James Lee wrote:
    > 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.

    --
    Martijn
    http://www.sereneconcepts.nl
     
    Martijn, Sep 25, 2003
    #2
    1. Advertising

  3. In article <>, James Lee wrote:
    > 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.


    --
    Andreas Kähäri
     
    Andreas Kahari, Sep 25, 2003
    #3
  4. James Lee

    Mike Wahler Guest

    "James Lee" <> wrote in message
    news:...
    > 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
     
    Mike Wahler, Sep 25, 2003
    #4
  5. James Lee

    Mark Gordon Guest

    On 25 Sep 2003 14:59:09 -0700
    (James Lee) wrote:

    > 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.
    --
    Mark Gordon
    Paid to be a Geek & a Senior Software Developer
    Although my email address says spamtrap, it is real and I read it.
     
    Mark Gordon, Sep 25, 2003
    #5
  6. James Lee

    Micah Cowan Guest

    (James Lee) writes:

    > 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
     
    Micah Cowan, Sep 26, 2003
    #6
  7. James Lee

    James Lee Guest

    (James Lee) wrote in message news:<>...
    > 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.
     
    James Lee, Sep 26, 2003
    #7
  8. James Lee

    Mike Wahler Guest

    "James Lee" <> wrote in message
    news:...
    > (James Lee) wrote in message

    news:<>...
    > > 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
     
    Mike Wahler, Sep 26, 2003
    #8
  9. James Lee

    Lew Pitcher Guest

    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.
     
    Lew Pitcher, Sep 27, 2003
    #9
  10. James Lee

    Martijn Guest

    Lew Pitcher wrote:
    > 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.

    --
    Martijn
    http://www.sereneconcepts.nl
     
    Martijn, Sep 27, 2003
    #10
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. bebop o'saurus
    Replies:
    15
    Views:
    1,807
    Raymond Lee
    Nov 13, 2004
  2. S Austin
    Replies:
    1
    Views:
    344
    Victor Bazarov
    Jan 29, 2004
  3. Stephen Thorne
    Replies:
    1
    Views:
    307
    Jack Diederich
    Aug 30, 2004
  4. Dave Benjamin

    Type inference, lessons learned from Vyper

    Dave Benjamin, Feb 3, 2005, in forum: Python
    Replies:
    0
    Views:
    314
    Dave Benjamin
    Feb 3, 2005
  5. peter

    How I learned Tkinter

    peter, Apr 23, 2006, in forum: Python
    Replies:
    2
    Views:
    299
    Ken Dere
    Apr 24, 2006
Loading...

Share This Page