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

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

trying a linked list

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

Contents

  trying a linked list "Bill Cunningham" <nospam@nspam.invalid> - 2016-05-07 17:06 -0400
    Re: trying a linked list "Bill Cunningham" <nospam@nspam.invalid> - 2016-05-07 17:32 -0400
      Re: trying a linked list Rosario19 <Ros@invalid.invalid> - 2016-05-07 23:44 +0200
      Re: trying a linked list "martin.ambuhl" <mambuhl@earthlink.net> - 2016-05-07 19:49 -0400
        Re: trying a linked list Richard Heathfield <rjh@cpax.org.uk> - 2016-05-08 07:46 +0100
    Re: trying a linked list Keith Thompson <kst-u@mib.org> - 2016-05-07 14:35 -0700
      Re: trying a linked list "Bill Cunningham" <nospam@nspam.invalid> - 2016-05-07 17:53 -0400
        Re: trying a linked list Keith Thompson <kst-u@mib.org> - 2016-05-07 15:01 -0700
          Re: trying a linked list "Bill Cunningham" <nospam@nspam.invalid> - 2016-05-07 19:18 -0400
            Re: trying a linked list Jerry Stuckle <jstucklex@attglobal.net> - 2016-05-07 19:28 -0400
            Re: trying a linked list Keith Thompson <kst-u@mib.org> - 2016-05-07 16:40 -0700
            Re: trying a linked list Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-05-07 17:15 -0700
              Re: trying a linked list "Bill Cunningham" <nospam@nspam.invalid> - 2016-05-07 20:25 -0400
                Re: trying a linked list Keith Thompson <kst-u@mib.org> - 2016-05-07 20:10 -0700
                  Re: trying a linked list Richard Heathfield <rjh@cpax.org.uk> - 2016-05-08 07:53 +0100
                    Re: trying a linked list Keith Thompson <kst-u@mib.org> - 2016-05-08 14:19 -0700
                  Re: trying a linked list Manfred <mx2927@gmail.com> - 2016-05-08 18:45 +0200
                    Re: trying a linked list "Bill Cunningham" <nospam@nspam.invalid> - 2016-05-08 17:21 -0400
                  Re: trying a linked list "Bill Cunningham" <nospam@nspam.invalid> - 2016-05-08 14:38 -0400
                    Re: trying a linked list Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-05-08 20:08 +0100
                      Re: trying a linked list Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-05-08 20:26 +0100
                        Re: trying a linked list "Bill Cunningham" <nospam@nspam.invalid> - 2016-05-08 17:22 -0400
                      Re: trying a linked list "Bill Cunningham" <nospam@nspam.invalid> - 2016-05-08 15:28 -0400
                        Re: trying a linked list Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-05-08 20:36 +0100
                          Re: trying a linked list "Bill Cunningham" <nospam@nspam.invalid> - 2016-05-08 17:17 -0400
                            Re: trying a linked list Keith Thompson <kst-u@mib.org> - 2016-05-08 14:56 -0700
                              Re: trying a linked list "Bill Cunningham" <nospam@nspam.invalid> - 2016-05-08 18:17 -0400
                                Re: trying a linked list Keith Thompson <kst-u@mib.org> - 2016-05-08 19:31 -0700
                                  Re: trying a linked list "Bill Cunningham" <nospam@nspam.invalid> - 2016-05-09 14:59 -0400
                            Re: trying a linked list Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-05-08 23:22 +0100
                              Re: trying a linked list "Bill Cunningham" <nospam@nspam.invalid> - 2016-05-09 14:46 -0400
                        Re: trying a linked list Keith Thompson <kst-u@mib.org> - 2016-05-08 14:32 -0700
                          Re: trying a linked list "Bill Cunningham" <nospam@nspam.invalid> - 2016-05-08 18:05 -0400
                    Re: trying a linked list Keith Thompson <kst-u@mib.org> - 2016-05-08 14:26 -0700
                      Re: trying a linked list "Bill Cunningham" <nospam@nspam.invalid> - 2016-05-09 13:50 -0400
                        Re: trying a linked list "Bill Cunningham" <nospam@nspam.invalid> - 2016-05-09 14:08 -0400
                        Re: trying a linked list Keith Thompson <kst-u@mib.org> - 2016-05-09 11:38 -0700
                          Re: trying a linked list "Bill Cunningham" <nospam@nspam.invalid> - 2016-05-09 14:50 -0400
                            Re: trying a linked list "Bill Cunningham" <nospam@nspam.invalid> - 2016-05-09 14:51 -0400
                              Re: trying a linked list Keith Thompson <kst-u@mib.org> - 2016-05-09 13:51 -0700
                              Re: trying a linked list Ken Brody <kenbrody@spamcop.net> - 2016-05-09 17:53 -0400
                            Re: trying a linked list Keith Thompson <kst-u@mib.org> - 2016-05-09 13:47 -0700
                              Re: trying a linked list "Osmium" <r124c4u102@comcast.net> - 2016-05-09 15:58 -0500
                              Re: trying a linked list "Bill Cunningham" <nospam@nspam.invalid> - 2016-05-09 17:13 -0400
                                Re: trying a linked list Keith Thompson <kst-u@mib.org> - 2016-05-09 14:35 -0700
                                  Re: trying a linked list "Bill Cunningham" <nospam@nspam.invalid> - 2016-05-09 17:40 -0400
                                  Re: trying a linked list "Bill Cunningham" <nospam@nspam.invalid> - 2016-05-09 17:41 -0400
                                    Re: trying a linked list Keith Thompson <kst-u@mib.org> - 2016-05-09 15:10 -0700
                                      Re: trying a linked list "Bill Cunningham" <nospam@nspam.invalid> - 2016-05-09 22:02 -0400
                                        Re: trying a linked list Keith Thompson <kst-u@mib.org> - 2016-05-09 21:17 -0700
                                      Re: trying a linked list "Bill Cunningham" <nospam@nspam.invalid> - 2016-05-09 22:31 -0400
              Re: trying a linked list "Bill Cunningham" <nospam@nspam.invalid> - 2016-05-07 20:30 -0400
              Re: trying a linked list Keith Thompson <kst-u@mib.org> - 2016-05-07 20:06 -0700
              Re: trying a linked list Richard Heathfield <rjh@cpax.org.uk> - 2016-05-08 07:50 +0100
                Re: trying a linked list BartC <bc@freeuk.com> - 2016-05-08 10:33 +0100
                  Re: trying a linked list Richard Heathfield <rjh@cpax.org.uk> - 2016-05-08 10:39 +0100
                    Re: trying a linked list BartC <bc@freeuk.com> - 2016-05-08 11:14 +0100
                      Re: trying a linked list Richard Heathfield <rjh@cpax.org.uk> - 2016-05-08 13:34 +0100
                        Re: trying a linked list BartC <bc@freeuk.com> - 2016-05-08 14:39 +0100
                          Re: trying a linked list Richard Heathfield <rjh@cpax.org.uk> - 2016-05-08 14:51 +0100
                        Re: trying a linked list Siri Cruise <chine.bleu@yahoo.com> - 2016-05-08 07:30 -0700
                Re: trying a linked list Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-05-08 10:36 +0100
                  Re: trying a linked list Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-05-08 02:49 -0700
                    Re: trying a linked list Keith Thompson <kst-u@mib.org> - 2016-05-08 14:17 -0700
                      Re: trying a linked list Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-05-08 14:36 -0700
                        Re: trying a linked list Keith Thompson <kst-u@mib.org> - 2016-05-08 14:57 -0700
                          Re: trying a linked list Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-05-09 13:28 -0700

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

#87527

On 5/9/2016 2:51 PM, Bill Cunningham wrote:
[...]

Re-inserting the original code, for reference:

==========
#include <stdio.h>

struct node {
     int number;
     struct node *next;
};

int main()
{
     struct node base;
     struct node *sp;
     sp = &base;
     sp->number = 1;
     printf("%d\n", *sp);
     sp->next->number = 2;
     printf("%d\n", *sp);
}
==========

>     I would say I do not know the proper specifier here. To printf. But the
> seg fault is at sp->next->number=2

To what does "sp->next" point?

-- 
Kenneth Brody

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

#87515

"Bill Cunningham" <nospam@nspam.invalid> writes:
> "Keith Thompson" <kst-u@mib.org> wrote in message 
> news:lninynuldz.fsf@kst-u.example.com...
>> "Bill Cunningham" <nospam@nspam.invalid> writes:
>>> "Keith Thompson" <kst-u@mib.org> wrote in message
>>> news:ln60uoxmug.fsf@kst-u.example.com...
>>>> "Bill Cunningham" <nospam@nspam.invalid> writes:
>> [...]
>>>>> {
>>>>>     struct node base;
>>>>>     struct node *sp;
>>>>>     sp = &base;
>>>>>     sp->number = 1;
>>>>>     printf("%d\n", *sp);
>>>>
>>>> This is the same mistake you made before.
>>>>
>>>> "%d" requires an argument of type int.  What is the type of *sp?
>>>> What do you expect this printf call to do?
>>>
>>>     IDK but
>> [...]
>>
>> Then my advice is to stop and don't attempt anything else until you can
>> answer those questions.
>
>     The type is either struct node or struct node * and they're both very 
> different.

Yes, it's either struct node or struct node*.  Which is it?

What is the type of sp?  (You should know, you defined it.)  Given the
type of sp, what is the type of *sp?

>            I tried casting both and it didn't work.

You're trying to add a cast because you're flailing around at random
without understanding what you're doing.  Stop it.  For what I *think*
you're trying to do, you don't need any casts at all.

>                                                     The size of struct node 
> is 16 bytes too I see.

The size of struct node is not particularly relevant.

And you haven't addressed the last question I asked.  You wrote:

     printf("%d\n", *sp);

I asked what you expect that printf() call to do.  Perhaps a better
question is: What exactly are you *trying* to do?  What value are you
trying to print?  (By "what value" I don't mean, for example, 4.  I mean
the value of *what*.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#87518

"Keith Thompson" <kst-u@mib.org> wrote in message 
news:ln4ma7ufet.fsf@kst-u.example.com...
> "Bill Cunningham" <nospam@nspam.invalid> writes:
>> "Keith Thompson" <kst-u@mib.org> wrote in message
>> news:lninynuldz.fsf@kst-u.example.com...
>>> "Bill Cunningham" <nospam@nspam.invalid> writes:
>>>> "Keith Thompson" <kst-u@mib.org> wrote in message
>>>> news:ln60uoxmug.fsf@kst-u.example.com...
>>>>> "Bill Cunningham" <nospam@nspam.invalid> writes:
>>> [...]
>>>>>> {
>>>>>>     struct node base;
>>>>>>     struct node *sp;
>>>>>>     sp = &base;
>>>>>>     sp->number = 1;
>>>>>>     printf("%d\n", *sp);
>>>>>
>>>>> This is the same mistake you made before.
>>>>>
>>>>> "%d" requires an argument of type int.  What is the type of *sp?
>>>>> What do you expect this printf call to do?
>>>>
>>>>     IDK but
>>> [...]
>>>
>>> Then my advice is to stop and don't attempt anything else until you can
>>> answer those questions.
>>
>>     The type is either struct node or struct node * and they're both very
>> different.
>
> Yes, it's either struct node or struct node*.  Which is it?
>
> What is the type of sp?  (You should know, you defined it.)  Given the
> type of sp, what is the type of *sp?
>
>>            I tried casting both and it didn't work.
>
> You're trying to add a cast because you're flailing around at random
> without understanding what you're doing.  Stop it.  For what I *think*
> you're trying to do, you don't need any casts at all.

This is like watching someone try to a fix a series string of Christmas tree 
lights, one spare bulb, and two bad bulbs in the string. 

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

#87521

"Keith Thompson" <kst-u@mib.org> wrote in message 
news:ln4ma7ufet.fsf@kst-u.example.com...
> I asked what you expect that printf() call to do.  Perhaps a better
> question is: What exactly are you *trying* to do?  What value are you
> trying to print?  (By "what value" I don't mean, for example, 4.  I mean
> the value of *what*.)

I think you mean pointer or pointee.

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

#87523

"Bill Cunningham" <nospam@nspam.invalid> writes:
> "Keith Thompson" <kst-u@mib.org> wrote in message 
> news:ln4ma7ufet.fsf@kst-u.example.com...
>> I asked what you expect that printf() call to do.  Perhaps a better
>> question is: What exactly are you *trying* to do?  What value are you
>> trying to print?  (By "what value" I don't mean, for example, 4.  I mean
>> the value of *what*.)
>
> I think you mean pointer or pointee.

You're trying to print the value of *something*.  What is that thing
whose value you're trying to print?  (Your current code tries to print
the value of *sp, but you can't do that.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#87524

"Keith Thompson" <kst-u@mib.org> wrote in message 
news:lnr3daud78.fsf@kst-u.example.com...
> "Bill Cunningham" <nospam@nspam.invalid> writes:
>> "Keith Thompson" <kst-u@mib.org> wrote in message
>> news:ln4ma7ufet.fsf@kst-u.example.com...
>>> I asked what you expect that printf() call to do.  Perhaps a better
>>> question is: What exactly are you *trying* to do?  What value are you
>>> trying to print?  (By "what value" I don't mean, for example, 4.  I mean
>>> the value of *what*.)
>>
>> I think you mean pointer or pointee.
>
> You're trying to print the value of *something*.  What is that thing
> whose value you're trying to print?  (Your current code tries to print
> the value of *sp, but you can't do that.)

    Well malloc is testing non-null. I can print the address of sp. I don't 
think that's what I want. I'll work on it. Has to do with printf.

Bill

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

#87525

"Keith Thompson" <kst-u@mib.org> wrote in message 
news:lnr3daud78.fsf@kst-u.example.com...
> "Bill Cunningham" <nospam@nspam.invalid> writes:
>> "Keith Thompson" <kst-u@mib.org> wrote in message
>> news:ln4ma7ufet.fsf@kst-u.example.com...

    There's no specifier for struct node.

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

#87529

"Bill Cunningham" <nospam@nspam.invalid> writes:
> "Keith Thompson" <kst-u@mib.org> wrote in message 
> news:lnr3daud78.fsf@kst-u.example.com...
>> "Bill Cunningham" <nospam@nspam.invalid> writes:
>>> "Keith Thompson" <kst-u@mib.org> wrote in message
>>> news:ln4ma7ufet.fsf@kst-u.example.com...
>
>     There's no specifier for struct node.

Correct, but not even close to answering any of my questions.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#87539

"Keith Thompson" <kst-u@mib.org> wrote in message 
news:lnmvnyubkz.fsf@kst-u.example.com...
> "Bill Cunningham" <nospam@nspam.invalid> writes:
>> "Keith Thompson" <kst-u@mib.org> wrote in message
>> news:lnr3daud78.fsf@kst-u.example.com...
>>> "Bill Cunningham" <nospam@nspam.invalid> writes:
>>>> "Keith Thompson" <kst-u@mib.org> wrote in message
>>>> news:ln4ma7ufet.fsf@kst-u.example.com...
>>
>>     There's no specifier for struct node.
>
> Correct, but not even close to answering any of my questions.

    Ok I got it. Here's the new code and it does what it is supposed to I 
believe this is correct.

#include <stdio.h>

struct node {
    int number;
};

int main()
{
    struct node base;
    struct node *ps = &base;
    ps->number = 1;
    printf("%d\n", ps->number);
    ps->number = 2;
    printf("%d\n", ps->number);
    ps->number = 3;
    printf("%d\n", ps->number);
}

But I didn't get all the way to 4. Just to three.

Bill

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

#87546

"Bill Cunningham" <nospam@nspam.invalid> writes:
> "Keith Thompson" <kst-u@mib.org> wrote in message 
> news:lnmvnyubkz.fsf@kst-u.example.com...
>> "Bill Cunningham" <nospam@nspam.invalid> writes:
>>> "Keith Thompson" <kst-u@mib.org> wrote in message
>>> news:lnr3daud78.fsf@kst-u.example.com...
>>>> "Bill Cunningham" <nospam@nspam.invalid> writes:
>>>>> "Keith Thompson" <kst-u@mib.org> wrote in message
>>>>> news:ln4ma7ufet.fsf@kst-u.example.com...
>>>
>>>     There's no specifier for struct node.
>>
>> Correct, but not even close to answering any of my questions.
>
>     Ok I got it. Here's the new code and it does what it is supposed to I 
> believe this is correct.
>
> #include <stdio.h>
>
> struct node {
>     int number;
> };
>
> int main()
> {
>     struct node base;
>     struct node *ps = &base;
>     ps->number = 1;
>     printf("%d\n", ps->number);
>     ps->number = 2;
>     printf("%d\n", ps->number);
>     ps->number = 3;
>     printf("%d\n", ps->number);
> }
>
> But I didn't get all the way to 4. Just to three.

Ok, I guess that's a start.  (Extending that to 4 is trivial.)

But that's not a linked list, since you removed the "next" member of
"struct node".  And you never answered my questions; your revised code
is correct, but I can't tell what it indicates about your understanding.

BTW, if your goal were to print 4 lines of output, (1, 2, 3, 4), you
could have just written:

    puts("1\n2\n3\n4");

Of course that would be silly -- but it shows that you need to be
clearer about what you're trying to do.  Something like "Construct a
linked list with 4 nodes, then traverse the list and print the `number`
element of each node."

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#87540

"Keith Thompson" <kst-u@mib.org> wrote in message 
news:lnmvnyubkz.fsf@kst-u.example.com...
> "Bill Cunningham" <nospam@nspam.invalid> writes:
>> "Keith Thompson" <kst-u@mib.org> wrote in message
>> news:lnr3daud78.fsf@kst-u.example.com...
>>> "Bill Cunningham" <nospam@nspam.invalid> writes:
>>>> "Keith Thompson" <kst-u@mib.org> wrote in message
>>>> news:ln4ma7ufet.fsf@kst-u.example.com...

    I have to say embarrassingly enough, I have some concepts here I will 
have to work out. This code didn't even need to involve pointers. I could 
have used "base.number" but well it printed the numbers. What I am seeing of 
linked lists they aren't /printing/ anything like I wanted to. There has to 
be a root pointer, and a pointer that traverses. I have a lot to learn.

Thanks to all.

Bill

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

#87384

"Malcolm McLean" <malcolm.mclean5@btinternet.com> wrote in message 
news:500b3147-def9-4831-8fa2-e13fddc23666@googlegroups.com...
> On Sunday, May 8, 2016 at 12:19:04 AM UTC+1, Bill Cunningham wrote:
>> "Keith Thompson" <kst-u@mib.org> wrote in message
>> news:lnd1oxzfvu.fsf@kst-u.example.com...
>> > "Bill Cunningham" <nospam@nspam.invalid> writes:
>> >> "Keith Thompson" <kst-u@mib.org> wrote in message
>> >> news:lnh9e9zh3s.fsf@kst-u.example.com...
>> >>> "Bill Cunningham" <nospam@nspam.invalid> writes:
>> >>> [...]
>> >>>>     struct node *sp;
>> >>>>     sp = &base;
>> >>>>     sp->number = 1;
>> >>>>     printf("%d\n", *sp);
>> >>>
>> >>> Is *sp of type int?
>> >>
>> >>     No it's of type struct node. But should int be cast there? Because
>> >> maybe
>> >> of the %d format specifier in printf? But, then again, number is of 
>> >> type
>> >> int. Maybe it *is* what should go there.
>> >
>> > The statement is wrong as it is.  I can't guess how you should change 
>> > it
>> > without knowing what you want it to do.
>> >
>> > What do you want that statement to do?
>> >
>> > (Casting *sp to int would be legal, but the result would be at best
>> > questionably meaningful.)
>>
>>     This is a jist of what I am trying to accomplish. I am at my Mom's
>> tonight and tomorrow night so I won't have a compiler. I will tomorrow
>> during the day need to work on the code.
>>
>>     Anyway print
>> 1
>> 2
>> 3
>> 4
>>
>> I an thinking,
>>
>> sp->next->number=2
>> sp->next->next->number=3
>> sp->next->next->next->number=4
>>
>> But I guess I have to use malloc here to clear the memory. Well
>> memset might work but I don't want to start messing with the C
>> method of the linked list algorithm. Not that good.
>>
> memset your structures to 0 immediately after allocating them
> with malloc.
> That will prevent any dangling pointers.
>
> Now
>
> if(sp->next)
>  sp->next->number = 2;
> else
> {
>   /* sp->next not set up to point to an element - you need to
>      look at the program to see why this is */
> }
>
> if(sp->next && sp->next->next)
>  sp->next->next->number = 3
> else
> {
>   /* same problem */
> }
>
> if(sp->next & sp->next->next && sp->next->next->next)
>  sp->next->next->next->number = 4;
> else
> {
>   /* same problem */
> }
>
> after about three the next->next->next method starts becoming unwieldy,
> so you'll need to think about how to extend to longer lists.

    All that stuff above just throws me to the four winds. After being 
successful at this maybe doubly linked lists. In the unwieldy form.

    These linked lists remind me of file systems and removing a sector or 
block and fragmentation.

Bill

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

#87385

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
[...]
> memset your structures to 0 immediately after allocating them
> with malloc. 
> That will prevent any dangling pointers.

It's better to assign the value NULL to the "next" member.  Apart from
the (mostly theoretical) portability issue, it's better to be explicit.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#87388

On 08/05/16 01:15, Malcolm McLean wrote:

<snip>

> memset your structures to 0 immediately after allocating them
> with malloc.

Malcolm, I never do that. Why should he?

> That will prevent any dangling pointers.

No, it won't. It will, at best, delay them, and is an added and 
unnecessary expense. Why not just set the members of the structure to 
the values they are supposed to have?

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#87391

On 08/05/2016 07:50, Richard Heathfield wrote:
> On 08/05/16 01:15, Malcolm McLean wrote:
>
> <snip>
>
>> memset your structures to 0 immediately after allocating them
>> with malloc.
>
> Malcolm, I never do that. Why should he?
>
>> That will prevent any dangling pointers.
>
> No, it won't. It will, at best, delay them, and is an added and
> unnecessary expense. Why not just set the members of the structure to
> the values they are supposed to have?
>

Because zero is likely to be most common default value for struct 
elements. Simpler then to set everything to zero before starting to fill 
them in.

It also convenient to to assume everything starts at zero, unless 
performance reasons stop you clearing everything. There must be a reason 
why writing {0} to initialise an array or struct fills the unspecified 
elements with 0 too.

With pointers, then if they are not initialised, a start value of NULL 
is better than one that by chance, already points at some data.

-- 
Bartc

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

#87393

On 08/05/16 10:33, BartC wrote:
> On 08/05/2016 07:50, Richard Heathfield wrote:
>> On 08/05/16 01:15, Malcolm McLean wrote:
>>
>> <snip>
>>
>>> memset your structures to 0 immediately after allocating them
>>> with malloc.
>>
>> Malcolm, I never do that. Why should he?
>>
>>> That will prevent any dangling pointers.
>>
>> No, it won't. It will, at best, delay them, and is an added and
>> unnecessary expense. Why not just set the members of the structure to
>> the values they are supposed to have?
>>
>
> Because zero is likely to be most common default value for struct
> elements. Simpler then to set everything to zero before starting to fill
> them in.

struct quux
{
   char *this;
   void *that;
   size_t other;
};

Which is simpler?

new = malloc(sizeof new);
if(new != NULL)
{
   new->this = foo;
   new->that = bar;
   new->other = baz;
}

or

new = malloc(sizeof new);
if(new != NULL)
{
   memset(new, 0, sizeof *new);
   new->this = foo;
   new->that = bar;
   new->other = baz;
}

If the structure is large and complicated and you're not going to be 
filling it all in at once, that's a good reason to set the pointers to 
NULL. I don't think there's any justification for memsetting them to 
all-bits-clear, though.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#87396

On 08/05/2016 10:39, Richard Heathfield wrote:
> On 08/05/16 10:33, BartC wrote:

>> Because zero is likely to be most common default value for struct
>> elements. Simpler then to set everything to zero before starting to fill
>> them in.
>
> struct quux
> {
>   char *this;
>   void *that;
>   size_t other;
> };
>
> Which is simpler?
>
> new = malloc(sizeof new);
> if(new != NULL)
> {
>   new->this = foo;
>   new->that = bar;
>   new->other = baz;
> }
>
> or
>
> new = malloc(sizeof new);
> if(new != NULL)
> {
>   memset(new, 0, sizeof *new);
>   new->this = foo;
>   new->that = bar;
>   new->other = baz;
> }

It would look more like this:

  new = mallocz(sizeof new);   // notice the z
  new->this = foo;
  new->that = bar;
  new->other = baz;

Here mallocz(), being a wrapper, can also take care of error-checking.

Possibly, if I knew three out of the three elements were going to be 
initialised, I'd use your first example.

What happens however is that later on, quux is changed to:

  struct quux
  {
    char *this;
    void *that;
    size_t other;
    int andanother;
  };

If quux's are allocated at several code-sites, and 'andanother' is only 
used in an obscure part of the program, or is a temporary measure, then 
using mallocz() involves less maintenance and there is less chance of an 
uninitialised  element, or one containing garbage or misleading data, is 
going to make it into the program.

> If the structure is large and complicated and you're not going to be
> filling it all in at once, that's a good reason to set the pointers to
> NULL. I don't think there's any justification for memsetting them to
> all-bits-clear, though.

I would take my chances and assume all-bits-clear is the same as NULL. 
My structs can have dozens of elements, and it is handy to assume 
everything is zero and only initialise those elements that will start 
off with non-zero values.

-- 
Bartc

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

#87400

On 08/05/16 11:14, BartC wrote:
> On 08/05/2016 10:39, Richard Heathfield wrote:
>> On 08/05/16 10:33, BartC wrote:
>
>>> Because zero is likely to be most common default value for struct
>>> elements. Simpler then to set everything to zero before starting to fill
>>> them in.
>>
>> struct quux
>> {
>>   char *this;
>>   void *that;
>>   size_t other;
>> };
>>
>> Which is simpler?
>>
>> new = malloc(sizeof new);
>> if(new != NULL)
>> {
>>   new->this = foo;
>>   new->that = bar;
>>   new->other = baz;
>> }
>>
>> or
>>
>> new = malloc(sizeof new);
>> if(new != NULL)
>> {
>>   memset(new, 0, sizeof *new);
>>   new->this = foo;
>>   new->that = bar;
>>   new->other = baz;
>> }
>
> It would look more like this:
>
>   new = mallocz(sizeof new);   // notice the z

Notice the error you introduced. You no longer have sufficient memory 
for the items you wish to store.

>   new->this = foo;
>   new->that = bar;
>   new->other = baz;
>
> Here mallocz(), being a wrapper, can also take care of error-checking.

Not properly, because all it can really do is abort. That isn't 
error-checking. That's suicide. And it didn't even detect the error 
(which was "incorrect storage size specified").

> Possibly, if I knew three out of the three elements were going to be
> initialised, I'd use your first example.
>
> What happens however is that later on, quux is changed to:
>
>   struct quux
>   {
>     char *this;
>     void *that;
>     size_t other;
>     int andanother;
>   };
>
> If quux's are allocated at several code-sites

then you fix it so that it's only allocated at one. There's more to 
programming than typing.

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#87401

On 08/05/2016 13:34, Richard Heathfield wrote:
> On 08/05/16 11:14, BartC wrote:
>> On 08/05/2016 10:39, Richard Heathfield wrote:

>>> struct quux
>>> {
>>>   char *this;
>>>   void *that;
>>>   size_t other;
>>> };
>>>
>>> Which is simpler?
>>>
>>> new = malloc(sizeof new);
>>> if(new != NULL)
>>> {
>>>   new->this = foo;
>>>   new->that = bar;
>>>   new->other = baz;
>>> }
>>>
>>> or
>>>
>>> new = malloc(sizeof new);
>>> if(new != NULL)
>>> {
>>>   memset(new, 0, sizeof *new);
>>>   new->this = foo;
>>>   new->that = bar;
>>>   new->other = baz;
>>> }
>>
>> It would look more like this:
>>
>>   new = mallocz(sizeof new);   // notice the z
>
> Notice the error you introduced. You no longer have sufficient memory
> for the items you wish to store.

>>   new->this = foo;
>>   new->that = bar;
>>   new->other = baz;
>>
>> Here mallocz(), being a wrapper, can also take care of error-checking.
>
> Not properly, because all it can really do is abort. That isn't
> error-checking. That's suicide.

It can do more than abort, depending on how sophisticated an 'exception' 
handling system you wish to emulate. (I can do this when a C program is 
implementing another language. Then memory errors can generate exception 
events that the implemented language can choose to trap.)

What I don't want is hundreds of instances of malloc 
return-value-checking code cluttering up source which has no idea how to 
deal tidily with the situation anyway.

 > And it didn't even detect the error
> (which was "incorrect storage size specified").

You mean using 'sizeof new' instead of 'sizeof *new'? That was copied 
from your code. I wouldn't use that idiom, but instead 'sizeof (quux)', 
where quux is a typedef.

>> Possibly, if I knew three out of the three elements were going to be
>> initialised, I'd use your first example.
>>
>> What happens however is that later on, quux is changed to:
>>
>>   struct quux
>>   {
>>     char *this;
>>     void *that;
>>     size_t other;
>>     int andanother;
>>   };
>>
>> If quux's are allocated at several code-sites
>
> then you fix it so that it's only allocated at one. There's more to
> programming than typing.

If you're exporting quux from a library which expects the caller to 
allocate memory for it, it's a bit much to expect it to keep on top of 
which elements have been added, removed or have changed type since last 
time it was compiled.

The library would have to provide an allocator too. (And a deallocator; 
it happens in my code that a library might use a different version of 
the C runtime, so malloc and free must belong to the same library.)

The largest struct I've come across had several hundred elements, and 
had a size of some 20KB per instance. Fortunately I wasn't expected to 
allocate or initialise it. But you can see how such a struct, presumably 
with various tables (to do with jpeg decoding in this case), benefits 
from being cleared to a known state of all-zeros before you do anything 
else.


-- 
Bartc

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

#87402

On 08/05/16 14:39, BartC wrote:
> On 08/05/2016 13:34, Richard Heathfield wrote:
> > And it didn't even detect the error
>> (which was "incorrect storage size specified").
>
> You mean using 'sizeof new' instead of 'sizeof *new'? That was copied
> from your code.


Ha! So it was. I'm obviously too tired for this, so I'll shut up for a bit.


-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

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

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

csiph-web