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

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

setting pointers to NULL and testing question.

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

Contents

  setting pointers to NULL and testing question. G G <gdotone@gmail.com> - 2016-06-12 16:21 -0700
    Re: setting pointers to NULL and testing question. Richard Heathfield <rjh@cpax.org.uk> - 2016-06-13 00:50 +0100
      Re: setting pointers to NULL and testing question. G G <gdotone@gmail.com> - 2016-06-12 17:03 -0700
      Re: setting pointers to NULL and testing question. Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-06-12 20:25 -0600
        Re: setting pointers to NULL and testing question. James Kuyper <jameskuyper@verizon.net> - 2016-06-12 22:57 -0400
          Re: setting pointers to NULL and testing question. Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-06-13 10:03 -0600
            Re: setting pointers to NULL and testing question. Tim Rentsch <txr@alumni.caltech.edu> - 2016-06-15 14:43 -0700
        Re: setting pointers to NULL and testing question. supercat@casperkitty.com - 2016-06-13 08:06 -0700
          Re: setting pointers to NULL and testing question. Richard Damon <Richard@Damon-Family.org> - 2016-06-16 08:27 -0400
            Re: setting pointers to NULL and testing question. supercat@casperkitty.com - 2016-06-16 06:27 -0700
              Re: setting pointers to NULL and testing question. supercat@casperkitty.com - 2016-06-16 07:31 -0700
              Re: setting pointers to NULL and testing question. Richard Damon <Richard@Damon-Family.org> - 2016-06-18 13:39 -0400
                Re: setting pointers to NULL and testing question. supercat@casperkitty.com - 2016-06-18 11:37 -0700
                  Re: setting pointers to NULL and testing question. Richard Damon <Richard@Damon-Family.org> - 2016-06-18 17:17 -0400
                    Re: setting pointers to NULL and testing question. supercat@casperkitty.com - 2016-06-18 17:22 -0700
        Re: setting pointers to NULL and testing question. James Kuyper <jameskuyper@verizon.net> - 2016-06-13 14:10 -0400
          Re: setting pointers to NULL and testing question. Keith Thompson <kst-u@mib.org> - 2016-06-13 11:28 -0700
          Re: setting pointers to NULL and testing question. Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-06-13 12:31 -0600
      Re: setting pointers to NULL and testing question. Keith Thompson <kst-u@mib.org> - 2016-06-12 19:38 -0700
        Re: setting pointers to NULL and testing question. Richard Heathfield <rjh@cpax.org.uk> - 2016-06-13 07:35 +0100
      Re: setting pointers to NULL and testing question. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-13 11:40 +0100
        Re: setting pointers to NULL and testing question. BartC <bc@freeuk.com> - 2016-06-13 11:56 +0100
          Re: setting pointers to NULL and testing question. Martin Shobe <mashobe9@gmail.com> - 2016-06-13 06:22 -0500
            Re: setting pointers to NULL and testing question. BartC <bc@freeuk.com> - 2016-06-13 12:39 +0100
              Re: setting pointers to NULL and testing question. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-13 15:22 +0100
                Re: setting pointers to NULL and testing question. BartC <bc@freeuk.com> - 2016-06-13 17:34 +0100
                  Re: setting pointers to NULL and testing question. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-13 19:31 +0100
                    Re: setting pointers to NULL and testing question. BartC <bc@freeuk.com> - 2016-06-13 20:17 +0100
                      Re: setting pointers to NULL and testing question. Keith Thompson <kst-u@mib.org> - 2016-06-13 12:47 -0700
                        Re: setting pointers to NULL and testing question. Tim Rentsch <txr@alumni.caltech.edu> - 2016-06-15 16:44 -0700
                          Re: setting pointers to NULL and testing question. Keith Thompson <kst-u@mib.org> - 2016-06-15 17:20 -0700
        Re: setting pointers to NULL and testing question. Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-13 04:01 -0700
          Re: setting pointers to NULL and testing question. Tim Rentsch <txr@alumni.caltech.edu> - 2016-06-16 12:57 -0700
        Re: setting pointers to NULL and testing question. Richard Heathfield <rjh@cpax.org.uk> - 2016-06-13 12:18 +0100
          Re: setting pointers to NULL and testing question. David Brown <david.brown@hesbynett.no> - 2016-06-13 14:01 +0200
            Re: setting pointers to NULL and testing question. Richard Heathfield <rjh@cpax.org.uk> - 2016-06-13 14:15 +0100
              Re: setting pointers to NULL and testing question. David Brown <david.brown@hesbynett.no> - 2016-06-13 15:37 +0200
                Re: setting pointers to NULL and testing question. Richard Heathfield <rjh@cpax.org.uk> - 2016-06-13 14:48 +0100
          Re: setting pointers to NULL and testing question. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-13 15:43 +0100
    Re: setting pointers to NULL and testing question. Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-12 17:54 -0700
    Re: setting pointers to NULL and testing question. John Bode <jfbode1029@gmail.com> - 2016-06-14 08:36 -0700
      Re: setting pointers to NULL and testing question. Richard Heathfield <rjh@cpax.org.uk> - 2016-06-14 16:41 +0100
      Re: setting pointers to NULL and testing question. Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-14 09:01 -0700
      Re: setting pointers to NULL and testing question. "James R. Kuyper" <jameskuyper@verizon.net> - 2016-06-14 13:25 -0400
        Re: setting pointers to NULL and testing question. supercat@casperkitty.com - 2016-06-14 10:48 -0700
          Re: setting pointers to NULL and testing question. Ian Collins <ian-news@hotmail.com> - 2016-06-15 08:24 +1200
            Re: setting pointers to NULL and testing question. "James R. Kuyper" <jameskuyper@verizon.net> - 2016-06-14 16:57 -0400
              Re: setting pointers to NULL and testing question. supercat@casperkitty.com - 2016-06-14 14:29 -0700
                Re: setting pointers to NULL and testing question. BartC <bc@freeuk.com> - 2016-06-14 22:41 +0100
                  Re: setting pointers to NULL and testing question. supercat@casperkitty.com - 2016-06-14 15:16 -0700
                    Re: setting pointers to NULL and testing question. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-15 00:25 +0100
                      Re: setting pointers to NULL and testing question. Keith Thompson <kst-u@mib.org> - 2016-06-14 16:58 -0700
                      Re: setting pointers to NULL and testing question. David Brown <david.brown@hesbynett.no> - 2016-06-15 09:28 +0200
                        Re: setting pointers to NULL and testing question. Keith Thompson <kst-u@mib.org> - 2016-06-15 09:57 -0700
                Re: setting pointers to NULL and testing question. David Brown <david.brown@hesbynett.no> - 2016-06-15 09:23 +0200
                  Re: setting pointers to NULL and testing question. Richard Heathfield <rjh@cpax.org.uk> - 2016-06-15 08:35 +0100
                    Re: setting pointers to NULL and testing question. Richard Heathfield <rjh@cpax.org.uk> - 2016-06-15 08:37 +0100
                    Re: setting pointers to NULL and testing question. David Brown <david.brown@hesbynett.no> - 2016-06-15 10:42 +0200
                      Re: setting pointers to NULL and testing question. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-15 13:28 +0100
                  Re: setting pointers to NULL and testing question. supercat@casperkitty.com - 2016-06-15 11:41 -0700
                  Re: setting pointers to NULL and testing question. raltbos@xs4all.nl (Richard Bos) - 2016-06-15 19:43 +0000
                    Re: setting pointers to NULL and testing question. supercat@casperkitty.com - 2016-06-15 13:09 -0700
                    Re: setting pointers to NULL and testing question. David Brown <david.brown@hesbynett.no> - 2016-06-15 22:31 +0200
                    Re: setting pointers to NULL and testing question. Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-15 17:11 -0400
                      Re: setting pointers to NULL and testing question. raltbos@xs4all.nl (Richard Bos) - 2016-06-18 20:44 +0000
                        Re: setting pointers to NULL and testing question. Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-18 17:20 -0400
          Re: setting pointers to NULL and testing question. Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-14 23:22 -0700
            Re: setting pointers to NULL and testing question. Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-15 13:23 +0100
        Re: setting pointers to NULL and testing question. John Bode <jfbode1029@gmail.com> - 2016-06-20 13:36 -0700
      Re: setting pointers to NULL and testing question. Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-14 14:59 -0400
        Re: setting pointers to NULL and testing question. "James R. Kuyper" <jameskuyper@verizon.net> - 2016-06-14 15:17 -0400
        Re: setting pointers to NULL and testing question. Richard Heathfield <rjh@cpax.org.uk> - 2016-06-14 20:25 +0100
        Re: setting pointers to NULL and testing question. Tim Rentsch <txr@alumni.caltech.edu> - 2016-06-15 19:48 -0700
          Re: setting pointers to NULL and testing question. Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-15 23:25 -0400
            Re: setting pointers to NULL and testing question. James Kuyper <jameskuyper@verizon.net> - 2016-06-16 12:11 -0400
              Re: setting pointers to NULL and testing question. supercat@casperkitty.com - 2016-06-16 09:25 -0700
              Re: setting pointers to NULL and testing question. Tim Rentsch <txr@alumni.caltech.edu> - 2016-06-16 21:46 -0700
                Re: setting pointers to NULL and testing question. Gareth Owen <gwowen@gmail.com> - 2016-06-17 06:13 +0100
                  Re: setting pointers to NULL and testing question. Robert Wessel <robertwessel2@yahoo.com> - 2016-06-17 02:03 -0500
                    Re: setting pointers to NULL and testing question. Martin Shobe <mashobe9@gmail.com> - 2016-06-17 07:07 -0500
                  Re: setting pointers to NULL and testing question. supercat@casperkitty.com - 2016-06-17 03:18 -0700
                  Re: setting pointers to NULL and testing question. James Kuyper <jameskuyper@verizon.net> - 2016-06-17 09:16 -0400
                    Re: setting pointers to NULL and testing question. Tim Rentsch <txr@alumni.caltech.edu> - 2016-06-21 11:03 -0700
                  Re: setting pointers to NULL and testing question. Tim Rentsch <txr@alumni.caltech.edu> - 2016-06-21 10:58 -0700
                Re: setting pointers to NULL and testing question. Keith Thompson <kst-u@mib.org> - 2016-06-21 11:28 -0700
            Re: setting pointers to NULL and testing question. Tim Rentsch <txr@alumni.caltech.edu> - 2016-06-16 21:39 -0700

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

#89002

Richard Heathfield <rjh@cpax.org.uk> writes:
<snip>
> So let's just pretend that we have a pointer whose initial value we
> are not yet in a position to decide. Set It To NULL!
>
> int *p = NULL;
>
> Later in the code, we can test for this.
>
> if(some_condition)
> {
>   p = some_function_yielding_a_pointer(args);
> }

Or, in modern C, you can introduce the pointer when you can give it the
value you want.  All the logic is then in one place.

  int *p = some_condition ? some_function_yielding_a_pointer(args) : NULL;

(The "you" is of course generic because I know you need to write old C.)

<snip>
-- 
Ben.

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

#89003

On 13/06/2016 11:40, Ben Bacarisse wrote:
> Richard Heathfield <rjh@cpax.org.uk> writes:
> <snip>
>> So let's just pretend that we have a pointer whose initial value we
>> are not yet in a position to decide. Set It To NULL!
>>
>> int *p = NULL;
>>
>> Later in the code, we can test for this.
>>
>> if(some_condition)
>> {
>>   p = some_function_yielding_a_pointer(args);
>> }
>
> Or, in modern C, you can introduce the pointer when you can give it the
> value you want.  All the logic is then in one place.
>
>   int *p = some_condition ? some_function_yielding_a_pointer(args) : NULL;

This won't work in the example above because it's inside the braces of 
the if statement. 'p' will be discard as soon as '}' is encountered.

It's necessary to search for the pair of matching {,} that enclose the 
smallest scope that includes all connected uses of a particular p, and 
put a declaration at the first assignment to that p.

(Note this process may yield distinct 'p' instances that are not 
dependent. Best to rename them then to avoid confusion.)

-- 
Bartc

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

#89008

On 6/13/2016 5:56 AM, BartC wrote:
> On 13/06/2016 11:40, Ben Bacarisse wrote:
>> Richard Heathfield <rjh@cpax.org.uk> writes:
>> <snip>
>>> So let's just pretend that we have a pointer whose initial value we
>>> are not yet in a position to decide. Set It To NULL!
>>>
>>> int *p = NULL;
>>>
>>> Later in the code, we can test for this.
>>>
>>> if(some_condition)
>>> {
>>>   p = some_function_yielding_a_pointer(args);
>>> }
>>
>> Or, in modern C, you can introduce the pointer when you can give it the
>> value you want.  All the logic is then in one place.
>>
>>   int *p = some_condition ? some_function_yielding_a_pointer(args) :
>> NULL;
>
> This won't work in the example above because it's inside the braces of
> the if statement. 'p' will be discard as soon as '}' is encountered.

What if statement? Ben's construct moves the condition inside the 
expression.

Martin Shobe

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

#89010

On 13/06/2016 12:22, Martin Shobe wrote:
> On 6/13/2016 5:56 AM, BartC wrote:
>> On 13/06/2016 11:40, Ben Bacarisse wrote:
>>> Richard Heathfield <rjh@cpax.org.uk> writes:

>>>> int *p = NULL;

>>>> if(some_condition)
>>>> {
>>>>   p = some_function_yielding_a_pointer(args);
>>>> }

>>>   int *p = some_condition ? some_function_yielding_a_pointer(args) :
>>> NULL;
>>
>> This won't work in the example above because it's inside the braces of
>> the if statement. 'p' will be discard as soon as '}' is encountered.
>
> What if statement? Ben's construct moves the condition inside the
> expression.

Oh, in that case Richard Heathfield's reply makes my point better.

You don't really want to worry about the addition of an outer block 
later on limiting the scope of the variable, so that references to it 
outside the block instead resolve to a more global version.

-- 
Bartc

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

#89019

BartC <bc@freeuk.com> writes:

> On 13/06/2016 12:22, Martin Shobe wrote:
>> On 6/13/2016 5:56 AM, BartC wrote:
>>> On 13/06/2016 11:40, Ben Bacarisse wrote:
>>>> Richard Heathfield <rjh@cpax.org.uk> writes:
>
>>>>> int *p = NULL;
>
>>>>> if(some_condition)
>>>>> {
>>>>>   p = some_function_yielding_a_pointer(args);
>>>>> }
>
>>>>   int *p = some_condition ? some_function_yielding_a_pointer(args) :
>>>> NULL;
>>>
>>> This won't work in the example above because it's inside the braces of
>>> the if statement. 'p' will be discard as soon as '}' is encountered.
>>
>> What if statement? Ben's construct moves the condition inside the
>> expression.
>
> Oh, in that case Richard Heathfield's reply makes my point better.

Richard's point seems to be that more complicated examples exist.

> You don't really want to worry about the addition of an outer block
> later on limiting the scope of the variable, so that references to it
> outside the block instead resolve to a more global version.

I don't follow this but does not seem to be what Richard said.

-- 
Ben.

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

#89023

On 13/06/2016 15:22, Ben Bacarisse wrote:
> BartC <bc@freeuk.com> writes:

>> Oh, in that case Richard Heathfield's reply makes my point better.
>
> Richard's point seems to be that more complicated examples exist.
>
>> You don't really want to worry about the addition of an outer block
>> later on limiting the scope of the variable, so that references to it
>> outside the block instead resolve to a more global version.
>
> I don't follow this but does not seem to be what Richard said.

If you start with this (w,x,y,z are just other bits of code):

  float p;
  void f(void) {
   int p;

   w;
   x;
   p=0;
   y;
   z=p;

change it to this to make it more trendy:

  float p;
  void f(void) {
   w;
   x;
   int p=0;
   y;
   z=p;

but then later a block needs to be inserted:

  float p;
  void f(void) {
   w;
   while (w) {
    x;
    int p=0;
    y;
   }
   z=p;

This will still compile, but the z=p will now refer to the outer 'float 
p'. This is the problem with scattering declarations about all over the 
shop instead of segregating them. You have to keep track and what's what 
and where.

(I've just been converting substantial amounts of code from a language 
that needed to no type annotations, to a statically typed one that needs 
them.

It was convenient to leave the bulk of the existing code alone (and thus 
not spoiling its lines by adding clutter, and keep it easy to compare 
with the original ) and put the type declarations tidily out of the way.

But obviously this is the new fad in C.)

-- 
Bartc

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

#89030

BartC <bc@freeuk.com> writes:

> On 13/06/2016 15:22, Ben Bacarisse wrote:
>> BartC <bc@freeuk.com> writes:
>
>>> Oh, in that case Richard Heathfield's reply makes my point better.
>>
>> Richard's point seems to be that more complicated examples exist.
>>
>>> You don't really want to worry about the addition of an outer block
>>> later on limiting the scope of the variable, so that references to it
>>> outside the block instead resolve to a more global version.
>>
>> I don't follow this but does not seem to be what Richard said.
>
> If you start with this (w,x,y,z are just other bits of code):
>
>  float p;
>  void f(void) {
>   int p;
>
>   w;
>   x;
>   p=0;
>   y;
>   z=p;
>
> change it to this to make it more trendy:
>
>  float p;
>  void f(void) {
>   w;
>   x;
>   int p=0;
>   y;
>   z=p;
>
> but then later a block needs to be inserted:
>
>  float p;
>  void f(void) {
>   w;
>   while (w) {
>    x;
>    int p=0;
>    y;
>   }
>   z=p;
>
> This will still compile, but the z=p will now refer to the outer
> 'float p'. This is the problem with scattering declarations about all
> over the shop instead of segregating them. You have to keep track and
> what's what and where.

The same happens if I put the while loop here:

  float p;
  void f(void) {
   while (...) {
     int p;
     w;
     x;
     p=0;
     y;
   }
   z=p;

Show me almost any piece of code and I'll break it by adding a while
loop to it incorrectly.  I don't think that fact tells us very much
about the value of the features that contribute to such breakages.

(Of course the main problem here is that the code was bad to start with.
Shadowing a file-scope name in a function is not a good idea.)

<snip>
-- 
Ben.

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

#89034

On 13/06/2016 19:31, Ben Bacarisse wrote:
> BartC <bc@freeuk.com> writes:

>> If you start with this (w,x,y,z are just other bits of code):
....
>> but then later a block needs to be inserted:
>>
>>  float p;
>>  void f(void) {
>>   w;
>>   while (w) {
>>    x;
>>    int p=0;
>>    y;
>>   }
>>   z=p;
>>
>> This will still compile, but the z=p will now refer to the outer
>> 'float p'.

> The same happens if I put the while loop here:
>
>   float p;
>   void f(void) {
>    while (...) {
>      int p;
>      w;
>      x;
>      p=0;
>      y;
>    }
>    z=p;
>
> Show me almost any piece of code and I'll break it by adding a while
> loop to it incorrectly.  I don't think that fact tells us very much
> about the value of the features that contribute to such breakages.

I can't separate out mixed declarations and statements, from 
declarations that are at the start of any block (other than a function 
block).

They're both equally as bad IMO.

If declarations are only written at the start of a function, before any 
statements, then it would be impossible for them to end up inside a {,} 
block.

> (Of course the main problem here is that the code was bad to start with.
> Shadowing a file-scope name in a function is not a good idea.)

It might not be but you don't always know you're doing it (if including 
tens of thousands of of lines of headers for example).

The problem can also occur if a function-scope name is omitted or 
misspelled, but there is a greater chance of such errors when 
declarations can be anywhere, and they're harder to spot: you have 'z=p' 
here, and 'int p' a few lines above, but you've omitted to double check 
the number and parity of intervening braces.

-- 
Bartc

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

#89037

BartC <bc@freeuk.com> writes:
[...]
> I can't separate out mixed declarations and statements, from 
> declarations that are at the start of any block (other than a function 
> block).
>
> They're both equally as bad IMO.
[...]

Ah, I wish I had read that before I posted my followup a moment ago.

Now that you've clarified the point, I'll just say I completely
disagree and move on.

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

#89235

Keith Thompson <kst-u@mib.org> writes:

> BartC <bc@freeuk.com> writes:
> [...]
>> I can't separate out mixed declarations and statements, from
>> declarations that are at the start of any block (other than a function
>> block).
>>
>> They're both equally as bad IMO.
>
> [...]
>
> Ah, I wish I had read that before I posted my followup a moment ago.
>
> Now that you've clarified the point, I'll just say I completely
> disagree and move on.

You completely disagree?  Does that mean you think one
is better than the other?  ;)

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

#89242

Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> BartC <bc@freeuk.com> writes:
>> [...]
>>> I can't separate out mixed declarations and statements, from
>>> declarations that are at the start of any block (other than a function
>>> block).
>>>
>>> They're both equally as bad IMO.
>>
>> [...]
>>
>> Ah, I wish I had read that before I posted my followup a moment ago.
>>
>> Now that you've clarified the point, I'll just say I completely
>> disagree and move on.
>
> You completely disagree?  Does that mean you think one
> is better than the other?  ;)

Ok, not *completely*.  They're both about equally bad (i.e., not
particularly bad at all).

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

#89004

On Monday, June 13, 2016 at 11:41:00 AM UTC+1, Ben Bacarisse wrote:
> Richard Heathfield <rjh@cpax.org.uk> writes:
> <snip>
> > So let's just pretend that we have a pointer whose initial value we
> > are not yet in a position to decide. Set It To NULL!
> >
> > int *p = NULL;
> >
> > Later in the code, we can test for this.
> >
> > if(some_condition)
> > {
> >   p = some_function_yielding_a_pointer(args);
> > }
> 
> Or, in modern C, you can introduce the pointer when you can give it the
> value you want.  All the logic is then in one place.
> 
>   int *p = some_condition ? some_function_yielding_a_pointer(args) : NULL;
> 
> (The "you" is of course generic because I know you need to write old C.)
> 
But that's hard to read.
Admittedly it will often be a bit easier to read if the identifiers have real
names and you can see the intention behind the logic. But all the same,
calling a function is such an involved thing that it should almost always
be given its own line.

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

#89330

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:

> On Monday, June 13, 2016 at 11:41:00 AM UTC+1, Ben Bacarisse wrote:
>> Richard Heathfield <rjh@cpax.org.uk> writes:
>> <snip>
>>> So let's just pretend that we have a pointer whose initial value we
>>> are not yet in a position to decide.  Set It To NULL!
>>>
>>> int *p = NULL;
>>>
>>> Later in the code, we can test for this.
>>>
>>> if(some_condition)
>>> {
>>>   p = some_function_yielding_a_pointer(args);
>>> }
>>
>> Or, in modern C, you can introduce the pointer when you can give it the
>> value you want.  All the logic is then in one place.
>>
>>   int *p = some_condition ? some_function_yielding_a_pointer(args) : NULL;
>>
>> (The "you" is of course generic because I know you need to write old C.)
>
> But that's hard to read.

Anyone who finds expressions like this hard to read shouldn't be
programming.

> Admittedly it will often be a bit easier to read if the identifiers have real
> names and you can see the intention behind the logic.  But all the same,
> calling a function is such an involved thing that it should almost always
> be given its own line.

Anyone weak-minded enough to agree with the last statement
shouldn't be programming either.

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

#89007

On 13/06/16 11:40, Ben Bacarisse wrote:
> Richard Heathfield <rjh@cpax.org.uk> writes:
> <snip>
>> So let's just pretend that we have a pointer whose initial value we
>> are not yet in a position to decide. Set It To NULL!
>>
>> int *p = NULL;
>>
>> Later in the code, we can test for this.
>>
>> if(some_condition)
>> {
>>    p = some_function_yielding_a_pointer(args);
>> }
>
> Or, in modern C, you can introduce the pointer when you can give it the
> value you want.  All the logic is then in one place.

True up to a point.

>
>    int *p = some_condition ? some_function_yielding_a_pointer(args) : NULL;

That's fine for the simple example I gave. It's less fine in situations 
such as this:

if(cond2)
{
   /* m lines of other code to create arga */
   p = f1(arga);
   /* n lines of other code using p */
}
else if(cond2)
{
   /* q lines of other code to create argb */
   p = f2(argb);
   /* r lines of other code using p */
}
else
{
   /* p NOT given a value in this part */
}

/*
In this part, if p has been given a value in either the code of the 
first condition or the code of the second, that value is used here.
*/

Since p is common at the end, scoping rules stop us from declaring p 'on 
the fly' within either of the conditions.

Arbitrary example? You bet. And the code probably needs some serious 
refactoring, too. Nevertheless, in the interim a NULL initialisation 
will allow the program to defend itself against producing confusingly 
wrong results (wrong results involving indeterminate values tend to be 
much harder to puzzle out, or even to *spot*, than wrong results 
involving null pointers).

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

#89013

On 13/06/16 13:18, Richard Heathfield wrote:
> On 13/06/16 11:40, Ben Bacarisse wrote:
>> Richard Heathfield <rjh@cpax.org.uk> writes:
>> <snip>
>>> So let's just pretend that we have a pointer whose initial value we
>>> are not yet in a position to decide. Set It To NULL!
>>>
>>> int *p = NULL;
>>>
>>> Later in the code, we can test for this.
>>>
>>> if(some_condition)
>>> {
>>>    p = some_function_yielding_a_pointer(args);
>>> }
>>
>> Or, in modern C, you can introduce the pointer when you can give it the
>> value you want.  All the logic is then in one place.
> 
> True up to a point.
> 
>>
>>    int *p = some_condition ? some_function_yielding_a_pointer(args) :
>> NULL;
> 
> That's fine for the simple example I gave. It's less fine in situations
> such as this:
> 
> if(cond2)
> {
>   /* m lines of other code to create arga */
>   p = f1(arga);
>   /* n lines of other code using p */
> }
> else if(cond2)
> {
>   /* q lines of other code to create argb */
>   p = f2(argb);
>   /* r lines of other code using p */
> }
> else
> {
>   /* p NOT given a value in this part */
> }
> 
> /*
> In this part, if p has been given a value in either the code of the
> first condition or the code of the second, that value is used here.
> */
> 
> Since p is common at the end, scoping rules stop us from declaring p 'on
> the fly' within either of the conditions.
> 
> Arbitrary example? You bet. And the code probably needs some serious
> refactoring, too. Nevertheless, in the interim a NULL initialisation
> will allow the program to defend itself against producing confusingly
> wrong results (wrong results involving indeterminate values tend to be
> much harder to puzzle out, or even to *spot*, than wrong results
> involving null pointers).
> 

The NULL initialisation also "defends" you from using the compiler's
warnings to help spot cases when you forgot to initialise p to a proper
value.  Explicitly setting "p = NULL" inside the final else clause may
make the meaning of the code clearer.

Initialising to a "safe default value" /can/ be a good thing - but it is
certainly not always helpful.

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

#89015

On 13/06/16 13:01, David Brown wrote:
> On 13/06/16 13:18, Richard Heathfield wrote:
>> On 13/06/16 11:40, Ben Bacarisse wrote:
>>> Richard Heathfield <rjh@cpax.org.uk> writes:
>>> <snip>
>>>> So let's just pretend that we have a pointer whose initial value we
>>>> are not yet in a position to decide. Set It To NULL!
>>>>
>>>> int *p = NULL;
>>>>
>>>> Later in the code, we can test for this.
>>>>
>>>> if(some_condition)
>>>> {
>>>>     p = some_function_yielding_a_pointer(args);
>>>> }
>>>
>>> Or, in modern C, you can introduce the pointer when you can give it the
>>> value you want.  All the logic is then in one place.
>>
>> True up to a point.
>>
>>>
>>>     int *p = some_condition ? some_function_yielding_a_pointer(args) :
>>> NULL;
>>
>> That's fine for the simple example I gave. It's less fine in situations
>> such as this:
>>
>> if(cond2)
>> {
>>    /* m lines of other code to create arga */
>>    p = f1(arga);
>>    /* n lines of other code using p */
>> }
>> else if(cond2)
>> {
>>    /* q lines of other code to create argb */
>>    p = f2(argb);
>>    /* r lines of other code using p */
>> }
>> else
>> {
>>    /* p NOT given a value in this part */
>> }
>>
>> /*
>> In this part, if p has been given a value in either the code of the
>> first condition or the code of the second, that value is used here.
>> */
>>
>> Since p is common at the end, scoping rules stop us from declaring p 'on
>> the fly' within either of the conditions.
>>
>> Arbitrary example? You bet. And the code probably needs some serious
>> refactoring, too. Nevertheless, in the interim a NULL initialisation
>> will allow the program to defend itself against producing confusingly
>> wrong results (wrong results involving indeterminate values tend to be
>> much harder to puzzle out, or even to *spot*, than wrong results
>> involving null pointers).
>>
>
> The NULL initialisation also "defends" you from using the compiler's
> warnings to help spot cases when you forgot to initialise p to a proper
> value.

Yes, but I don't mind that. I can find it out very quickly during 
development, if p is a null pointer. I find deterministically erroneous 
output to be a lot easier to analyse than indeterminately erroneous 
output. I know you're saying that you can pick up /some/ cases a lot 
earlier if you let the compiler worry about it, and that's fine - I'm 
not worried about those cases, but cases where it /doesn't/ tell me.

$ cat z.c

extern void foo(int **p, int n);

int bar(void)
{
   int *p;
   foo(&p, 42);
   p[0] = 6; /* is this access well-defined? */
   return p[41]; /* how about this? */
}

$ gcc -c -W -Wall -ansi -pedantic -o z.o z.c
$


> Explicitly setting "p = NULL" inside the final else clause may
> make the meaning of the code clearer.

Yes, it might. Explicitly setting it to NULL at initialisation not only 
makes the code clearer but also adds defence in depth.

> Initialising to a "safe default value" /can/ be a good thing - but it is
> certainly not always helpful.

I'm sure it would be possible to contrive a case where it isn't helpful. 
Making the right choice in a given situation is yet another part of 
being a programmer.

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

#89017

On 13/06/16 15:15, Richard Heathfield wrote:
> On 13/06/16 13:01, David Brown wrote:
>> On 13/06/16 13:18, Richard Heathfield wrote:
<snip>
>>> Arbitrary example? You bet. And the code probably needs some serious
>>> refactoring, too. Nevertheless, in the interim a NULL initialisation
>>> will allow the program to defend itself against producing confusingly
>>> wrong results (wrong results involving indeterminate values tend to be
>>> much harder to puzzle out, or even to *spot*, than wrong results
>>> involving null pointers).
>>>
>>
>> The NULL initialisation also "defends" you from using the compiler's
>> warnings to help spot cases when you forgot to initialise p to a proper
>> value.
> 
> Yes, but I don't mind that. I can find it out very quickly during
> development, if p is a null pointer. I find deterministically erroneous
> output to be a lot easier to analyse than indeterminately erroneous
> output.

I find compile-time errors (using a good compiler, plenty of warnings,
and "make warnings errors" flags) far easier to spot than trial and
error run-time debugging.  (Of course, I agree that deterministic errors
by unexpected NULL's are easier to find than non-deterministic errors by
uninitialised pointers - /if/ the compiler can't find them at compile time.)

> I know you're saying that you can pick up /some/ cases a lot
> earlier if you let the compiler worry about it, and that's fine - I'm
> not worried about those cases, but cases where it /doesn't/ tell me.
> 
> $ cat z.c
> 
> extern void foo(int **p, int n);
> 
> int bar(void)
> {
>   int *p;
>   foo(&p, 42);
>   p[0] = 6; /* is this access well-defined? */
>   return p[41]; /* how about this? */
> }
> 
> $ gcc -c -W -Wall -ansi -pedantic -o z.o z.c
> $
> 

It's quite simple - don't write code like that, unless you know your
function "foo" /does/ set that pointer to a valid value.  Initialising p
to a known invalid value won't make that code correct if "foo" is not
specified or implemented appropriately, nor will it necessarily make it
easier to spot the problem.  It /might/ make some problems, such as foo
failing to set the pointer, easier to find in some cases - but it's not
a big win.

(On most platforms I use, reading from a null pointer works perfectly
well, since there is usually something mapped from address 0 onwards in
memory.  Writing through a null pointer is likely to have no effect, as
it is common to have flash mapped at 0 - but on some targets there are
hardware registers from 0 onwards.)

> 
>> Explicitly setting "p = NULL" inside the final else clause may
>> make the meaning of the code clearer.
> 
> Yes, it might. Explicitly setting it to NULL at initialisation not only
> makes the code clearer but also adds defence in depth.

I disagree, as a general point - but of course there will be examples
where initialising to NULL makes the code cleaner or safer.  This is not
a black-or-white issue.

> 
>> Initialising to a "safe default value" /can/ be a good thing - but it is
>> certainly not always helpful.
> 
> I'm sure it would be possible to contrive a case where it isn't helpful.
> Making the right choice in a given situation is yet another part of
> being a programmer.
> 

On that point, I agree entirely.

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

#89018

On 13/06/16 14:37, David Brown wrote:
> On 13/06/16 15:15, Richard Heathfield wrote:

<snip>

>>
>> $ gcc -c -W -Wall -ansi -pedantic -o z.o z.c
>> $
>>
>
> It's quite simple - don't write code like that,

Yeah, I know. That's the same thing I'd say about your way. :-)

"Doctor, it hurts when..."

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

#89020

Richard Heathfield <rjh@cpax.org.uk> writes:

> On 13/06/16 11:40, Ben Bacarisse wrote:
>> Richard Heathfield <rjh@cpax.org.uk> writes:
>> <snip>
>>> So let's just pretend that we have a pointer whose initial value we
>>> are not yet in a position to decide. Set It To NULL!
>>>
>>> int *p = NULL;
>>>
>>> Later in the code, we can test for this.
>>>
>>> if(some_condition)
>>> {
>>>    p = some_function_yielding_a_pointer(args);
>>> }
>>
>> Or, in modern C, you can introduce the pointer when you can give it the
>> value you want.  All the logic is then in one place.
>
> True up to a point.
>
>>
>>    int *p = some_condition ? some_function_yielding_a_pointer(args) : NULL;
>
> That's fine for the simple example I gave.

Sure.  I was only offering an alternative to what you wrote.

> It's less fine in
> situations such as this:
>
> if(cond2)
> {
>   /* m lines of other code to create arga */
>   p = f1(arga);
>   /* n lines of other code using p */
> }
> else if(cond2)
> {
>   /* q lines of other code to create argb */
>   p = f2(argb);
>   /* r lines of other code using p */
> }
> else
> {
>   /* p NOT given a value in this part */
> }
>
> /*
> In this part, if p has been given a value in either the code of the
> first condition or the code of the second, that value is used here.
> */
>
> Since p is common at the end, scoping rules stop us from declaring p
> 'on the fly' within either of the conditions.
>
> Arbitrary example? You bet.

I'd say it was almost the antithesis of arbitrary!  It seems very much
constrained by a complex set of conditions needed to illustrate your
point.

> And the code probably needs some serious
> refactoring, too. Nevertheless, in the interim a NULL initialisation
> will allow the program to defend itself against producing confusingly
> wrong results (wrong results involving indeterminate values tend to be
> much harder to puzzle out, or even to *spot*, than wrong results
> involving null pointers).

I wasn't arguing against NULL initialisation.  I just prefer not to have
the code that sets a variable's value spread out over the code any more
than it absolutely has to be.

-- 
Ben.

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

#88994

On Monday, June 13, 2016 at 12:21:40 AM UTC+1, G G wrote:
> when should a pointer to set to NULL and test whether
> it is NULL?
>
When it doesn't point to anything, but you don't necessarily know
that before examining it.
Take a linked list. Each node has a "next" pointer which points 
to the next node in the list. Except the last node. So how do we
know it's the last node? The obvious way is to set its next
pointer to NULL.

However it's important to note that, if designing software, you 
don't have to use NULL. We could equally well have a "last"
flag for every node, set for the last one. The last "next"
pointer could then be indeterminate. It doesn't point to anything,
but it doesn't hold null. It just has a random garbage value.

The "last" flag idea isn't very C-ish, but we might want to
use it for some reason or other, e.g. if we want to be able
to terminate the linked list early without breaking it. Another
technique is to have a special "end" or "nil" node, and in fact
this is used quite often, though the reasons are a bit too detailed
to go into here. If you are designing a whole system yourself, 
you're never forced to use a NULL pointer. But it's a very convenient
way of indicating "no data".

   

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

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

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

csiph-web