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

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

guidelines for pointer check

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

Contents

  guidelines for pointer check Thiago Adams <thiago.adams@gmail.com> - 2016-12-29 12:53 -0800
    Re: guidelines for pointer check Ian Collins <ian-news@hotmail.com> - 2016-12-30 09:58 +1300
    Re: guidelines for pointer check Keith Thompson <kst-u@mib.org> - 2016-12-29 13:39 -0800
      Re: guidelines for pointer check Thiago Adams <thiago.adams@gmail.com> - 2016-12-29 15:24 -0800
        Re: guidelines for pointer check Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2016-12-29 19:05 -0500
          Re: guidelines for pointer check Thiago Adams <thiago.adams@gmail.com> - 2016-12-30 05:27 -0800
            Re: guidelines for pointer check Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-30 14:35 +0000
            Re: guidelines for pointer check supercat@casperkitty.com - 2016-12-30 10:38 -0800
          Re: guidelines for pointer check Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-02 02:28 -0800
        Re: guidelines for pointer check Keith Thompson <kst-u@mib.org> - 2016-12-29 16:19 -0800
    Re: guidelines for pointer check Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-29 13:58 -0800
    guidelines for pointer check asetofsymbols@gmail.com - 2016-12-30 05:35 -0800
    Re: guidelines for pointer check raltbos@xs4all.nl (Richard Bos) - 2017-01-01 10:47 +0000
    Re: guidelines for pointer check Noob <root@127.0.0.1> - 2017-01-02 14:19 +0100
      Re: guidelines for pointer check David Brown <david.brown@hesbynett.no> - 2017-01-02 14:28 +0100
        Re: guidelines for pointer check Noob <root@127.0.0.1> - 2017-01-02 17:35 +0100
          Re: Using == operator Noob <root@127.0.0.1> - 2017-01-02 19:03 +0100
            Re: Using == operator David Brown <david.brown@hesbynett.no> - 2017-01-02 23:41 +0100
              Re: Using == operator Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-02 14:54 -0800
                Re: Using == operator Keith Thompson <kst-u@mib.org> - 2017-01-02 15:57 -0800
                  Re: Using == operator Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2017-01-03 16:31 -0500
                    Re: Using == operator Keith Thompson <kst-u@mib.org> - 2017-01-03 14:06 -0800
                      Re: Using == operator Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-03 14:44 -0800
                        Re: Using == operator Keith Thompson <kst-u@mib.org> - 2017-01-03 15:05 -0800
                          Re: Using == operator Jorgen Grahn <grahn+nntp@snipabacken.se> - 2017-01-04 16:42 +0000
                            Re: Using == operator Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-15 11:46 -0800
                        Re: Using == operator Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2017-01-03 21:22 -0700
                      Re: Using == operator supercat@casperkitty.com - 2017-01-03 15:23 -0800
                        Re: Using == operator Keith Thompson <kst-u@mib.org> - 2017-01-03 15:30 -0800
                          Re: Using == operator supercat@casperkitty.com - 2017-01-03 16:02 -0800
                            Re: Using == operator Keith Thompson <kst-u@mib.org> - 2017-01-03 16:30 -0800
                              Re: Using == operator Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-15 11:26 -0800
                        Re: Using == operator raltbos@xs4all.nl (Richard Bos) - 2017-01-04 09:55 +0000
                          Re: Using == operator Jorgen Grahn <grahn+nntp@snipabacken.se> - 2017-01-04 16:49 +0000
                            Re: Using == operator raltbos@xs4all.nl (Richard Bos) - 2017-01-10 01:28 +0000
                              Re: Using == operator Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2017-01-09 19:12 -0700
                              Re: Using == operator Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-15 09:12 -0800
                            Re: Using == operator Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-15 09:54 -0800
                Re: Using == operator raltbos@xs4all.nl (Richard Bos) - 2017-01-03 21:08 +0000
                  Re: Using == operator Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-15 06:44 -0800
    Re: guidelines for pointer check Anand Hariharan <mailto.anand.hariharan@gmail.com> - 2017-01-04 08:54 -0800
      Re: guidelines for pointer check Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-14 00:51 -0800

Page 1 of 3  [1] 2 3  Next page →

#100463 — guidelines for pointer check

Do you have some style guideline for pointer checking?

This is a kind of poll:


   //Style 1
   if (pVariable) { /*...*/ }

   //Style 2
   if (pVariable != NULL)  { /*...*/ }

   //Style 3
   if (pVariable != 0) { /*...*/ }

Do you dislike one of them?
Do you use only one of them?
Do you use more than one?
Other?

[toc] | [next] | [standalone]

#100469

On 12/30/16 09:53 AM, Thiago Adams wrote:
>
> Do you have some style guideline for pointer checking?
>
> This is a kind of poll:
>
>
>     //Style 1
>     if (pVariable) { /*...*/ }
>
>     //Style 2
>     if (pVariable != NULL)  { /*...*/ }
>
>     //Style 3
>     if (pVariable != 0) { /*...*/ }
>
> Do you dislike one of them?

The second somewhat and the third a lot!  gcc agrees with me on the third.

> Do you use only one of them?

Yes, the first.

> Do you use more than one?

No.

> Other?

If C had C++'s nullptr....

-- 
Ian

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

#100501

Thiago Adams <thiago.adams@gmail.com> writes:
> Do you have some style guideline for pointer checking?
>
> This is a kind of poll:
>
>
>    //Style 1
>    if (pVariable) { /*...*/ }
>
>    //Style 2
>    if (pVariable != NULL)  { /*...*/ }
>
>    //Style 3
>    if (pVariable != 0) { /*...*/ }
>
> Do you dislike one of them?
> Do you use only one of them?
> Do you use more than one?
> Other?

I prefer `if (pVariable != NULL)`.

As Stefan Ram points out, NULL requires #including a standard header,
but in a program of any complexity one of the several standard headers
that define NULL will almost certainly already be #included -- and if
not, adding `#include <stddef.h.` is easy enough.

The other styles are of course perfectly valid, and those who prefer
them are not wrong.  I prefer NULL over 0 or the implicit comparison
of Style 1 because it's more explicit and isn't likely to introduce
any potential problems.  There might be some risk that pVariable
isn't really of pointer type, and that `if (pVariable != NULL)`
still compiles because NULL is defined as 0.  Similarly, I'd compare
a char value to '\0', a floating-point value to 0.0, and I wouldn't
compare boolean value (whether _Bool or not) to anything.

I'm not entirely consistent about prefering explicit code.  For example
I don't cast the result of malloc(), preferring the implicit conversion
of void* to the appropriate target type -- partly because the cast can
cause actual problems.

My preferences are almost certainly influenced by other languages I've
used.

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

#100566

On Thursday, December 29, 2016 at 7:39:09 PM UTC-2, Keith Thompson wrote:
[...]
> There might be some risk that pVariable
> isn't really of pointer type, and that `if (pVariable != NULL)`
> still compiles because NULL is defined as 0.  Similarly, I'd compare
> a char value to '\0', a floating-point value to 0.0, and I wouldn't
> compare boolean value (whether _Bool or not) to anything.
> 

Visual C libraries define NULL as 

#ifndef NULL
    #ifdef __cplusplus
        #define NULL 0
    #else
        #define NULL ((void *)0)
    #endif
#endif

If NULL was defined as ((void *)0) in C++ then this error could occurs.

int **pp = NULL; //invalid conversion


I use 'if (pointer != NULL) ...' and I am considering to write a check for this style in my static code analyser just to keep source code homogeneous.
If null was defined as 0 it would be more difficult to detect if it is 0 or macro NULL. Actually I think it's not too hard to annotated on token the macro they are expanded from. And then annotate on the primary-expression the macro name as well and then later on the analyser  ask if 0 was expanded from NULL. 
Maybe this would be useful for false and true.
int i = false; 

Sometimes I am lazy and I write if (pointer).

And of course  check for  if (x = value) ..  that I found too dangerous. "too clever".

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

#100579

On Thursday December 29 2016 18:54, in comp.lang.c, "Stefan Ram"
<ram@zedat.fu-berlin.de> wrote:

> Thiago Adams <thiago.adams@gmail.com> writes:
>>And of course  check for  if (x = value) ..  that I found too
>>dangerous. "too clever".
> 
>   It's not »too clever«, it's C.
> 
>   To me, C is the »while(*q++=*p++)-language«,
>   the »if(p&&*p)-language«.
> 
>   It's ok, if one does like this terseness.
>   Then one can use Pascal or BASIC. But one
>   should not write Pascal or BASIC /in C/.
[snip]
>   If someone has any problems with »if( p )« or
>   »if( f = fopen( a, b ))«, would you want him
>   in you project?
[snip]

Bravo!!!

I concur.

-- 
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request

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

#100653

On Thursday, December 29, 2016 at 10:05:59 PM UTC-2, Lew Pitcher wrote:
> On Thursday December 29 2016 18:54, in comp.lang.c, "Stefan Ram"
>  wrote:
> 
> > Thiago Adams  writes:
> >>And of course  check for  if (x = value) ..  that I found too
> >>dangerous. "too clever".
> > 
> >   It's not »too clever«, it's C.
> > 
> >   To me, C is the »while(*q++=*p++)-language«,
> >   the »if(p&&*p)-language«.
> > 
> >   It's ok, if one does like this terseness.
> >   Then one can use Pascal or BASIC. But one
> >   should not write Pascal or BASIC /in C/.
> [snip]
> >   If someone has any problems with »if( p )« or
> >   »if( f = fopen( a, b ))«, would you want him
> >   in you project?
> [snip]


This case:

if (a = value)

It's hard to see the programmer intention. 
So using this style you get ambiguity for free.

In this case:

if( f = fopen( a, b ))

it's not difficult, but I prefer:

f = fopen( a, b );
if(f != NULL)
{
}
because it maps direct to what documentation says:
"On error, returns a null pointer"

The last one it's not ambiguous because it's easy to see that we are working with pointers.

while(*q++=*p++)

But, I need to see the rest of the code to say if I would use this style.

---
(I can't see Stefan Ram original messages on google and e-mail. I see only when someones use Stefan Ram messages)

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

#100661

Thiago Adams <thiago.adams@gmail.com> writes:
<snip>
> (I can't see Stefan Ram original messages on google and e-mail. I see
> only when someones use Stefan Ram messages)

He sets X-No-Archive: Yes and Archive: no which Google groups respects.
The "and e-mail" part I don't understand.

-- 
Ben.

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

#100691

On Friday, December 30, 2016 at 7:27:57 AM UTC-6, Thiago Adams wrote:
> This case:
> 
> if (a = value)
> 
> It's hard to see the programmer intention. 
> So using this style you get ambiguity for free.

If I need to assign something and test whether the result is truthy, I
prefer to use !! as though it were an operator which yields 1 when given
something truthy and 0 otherwise.  In a construct like

    if ((flagsOfInterest & currentFlags) != 0)

I consider the 0 to be a "fake constant".  The purpose of the code isn't
to test whether the numerical value of the intersection of bits in
flagsOfInterest and currentFlags is zero, but rather whether any bits
that are set in one are also set in the other.  Changing the 0 to any
other constant would fundamentally alter the meaning of the code, and
in most cases where one would want to deal with bits whose normal state
was set rather than cleared, one would need to change the code to something
like:

    if ((flagsOfInterest & (expectedFlags ^ currentFlags)) != 0)

rather than 

    if ((flagsOfInterest & expectedFlags) != expectedFlags)

so the phony constant 0 would still be needed even if the condition to be
tested changed.

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

#100860

Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:

> On Thursday December 29 2016 18:54, in comp.lang.c, "Stefan Ram"
> <ram@zedat.fu-berlin.de> wrote:
>
>> Thiago Adams <thiago.adams@gmail.com> writes:
>>> And of course  check for  if (x = value) ..  that I found too
>>> dangerous.  "too clever".
>>
>>   It's not >>too clever<<, it's C.
>>
>>   To me, C is the >>while(*q++=*p++)-language<<,
>>   the >>if(p&&*p)-language<<.
>>
>>   It's ok, if one does like this terseness.
>>   Then one can use Pascal or BASIC.  But one
>>   should not write Pascal or BASIC /in C/.
>
> [snip]
>
>>   If someone has any problems with >>if( p )<< or
>>   >>if( f = fopen( a, b ))<<, would you want him
>>   in you project?
>
> [snip]
>
> Bravo!!!
>
> I concur.

My sentiments exactly.

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

#100582

ram@zedat.fu-berlin.de (Stefan Ram) writes:
[...]
>   Here is a randomly chosen if clause from Nethack:
>
> if (x >= 0 && y >= 0 && x <= (int)max_x_map && y <= (int)max_y_map &&
>     (IS_ROCK(tmpmap[y][x]) || IS_DOOR(tmpmap[y][x])))

I have no problem with that.  I might group the x and y tests
differently, and I wonder whether the casts are necessary, but
those are trivial points.

More to the point, each of the subexpressions (the operands to && and ||)
is "logically Boolean" -- not necessarily of type _Bool, but
something whose value is logically either false or true, with no
meaningful distinction among different truthy values.

>   When someone can't read even a clause as simple as
>   »if( p )« or »if( f = fopen( a, b ))«, how could
>   he ever work in a real project like Nethack?

There's a big difference between not being able to read some terse
construct and preferring something a bit more verbose.  Given that p is
a pointer (and hopefully one with a better name), I know exactly what

    if (p)

means, and I don't particularly stumble over it when I see it in code.
Nevertheless, I personally prefer

    if (p != NULL)

Why?  Because in my view `p` by itself is not logically Boolean (it's a
pointer value), but `p != NULL` is.

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

#100519

On Thursday, December 29, 2016 at 8:54:03 PM UTC, Thiago Adams wrote:
> Do you have some style guideline for pointer checking?
> 
> This is a kind of poll:
> 
> 
>    //Style 1
>    if (pVariable) { /*...*/ }
> 
>    //Style 2
>    if (pVariable != NULL)  { /*...*/ }
> 
>    //Style 3
>    if (pVariable != 0) { /*...*/ }
> 
> Do you dislike one of them?
> Do you use only one of them?
> Do you use more than one?
> Other?
>

Jut depends what you are doing

while(node)
{
    printf("%s\n", node->data);
    node = node->next;
}

for(node = head; node != NULL; node = node->next)
{
   printf("%s\n", node->data);
}

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

#100655

I prefer
   if (pVariable != 0) { /*...*/ }

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

#100758

Thiago Adams <thiago.adams@gmail.com> wrote:

>    //Style 1
>    if (pVariable) { /*...*/ }
> 
>    //Style 2
>    if (pVariable != NULL)  { /*...*/ }
> 
>    //Style 3
>    if (pVariable != 0) { /*...*/ }
> 
> Do you dislike one of them?

The last one. Pointers comparing to 0 is a historic wart.

Actually, all of them; Hungarian notation is vile, and type-specifying
HN, which you have here, is gorget-raising.

> Do you use more than one?

Depends, but only a little, on what I want to express. If I want to
express that a null pointer represents a logically negative state (e.g.,
"this option was not specified", or "this object does not exist"), then
I use style 1. This is by far the most common case, for me.
For instance:

  void function(int value, int *optional_object)
  {
    if (optional_object) {
      /* Do something with the object and the value */
    }
   /* Do something with the value */
   }

If it is the fact of the _pointer_ being null, I'll usually use 2, but I
find that this is much rarer. I probably only use it when dealing with
linked lists, trees and such.

Richard

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

#100869

On 29/12/2016 21:53, Thiago Adams wrote:

> Do you have some style guideline for pointer checking?
> 
> This is a kind of poll:
> 
> 
>    //Style 1
>    if (pVariable) { /*...*/ }
> 
>    //Style 2
>    if (pVariable != NULL)  { /*...*/ }
> 
>    //Style 3
>    if (pVariable != 0) { /*...*/ }
> 
> Do you dislike one of them?
> Do you use only one of them?
> Do you use more than one?
> Other?

Slightly different situation, same question:

void foo(int **p)
{
  if (*p == NULL) ...
  if (*p == 0) ...
  if (!*p) ...

which would you use?

In my opinion, the last one is truly awful, because it's not always
easy to spot the '!' between '(' and '*' in all fonts. And some
coding guidelines unhelpfully disallow a space after '('.

Regards.

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

#100870

On 02/01/17 14:19, Noob wrote:
> On 29/12/2016 21:53, Thiago Adams wrote:
> 
>> Do you have some style guideline for pointer checking?
>>
>> This is a kind of poll:
>>
>>
>>    //Style 1
>>    if (pVariable) { /*...*/ }
>>
>>    //Style 2
>>    if (pVariable != NULL)  { /*...*/ }
>>
>>    //Style 3
>>    if (pVariable != 0) { /*...*/ }
>>
>> Do you dislike one of them?
>> Do you use only one of them?
>> Do you use more than one?
>> Other?
> 
> Slightly different situation, same question:
> 
> void foo(int **p)
> {
>   if (*p == NULL) ...
>   if (*p == 0) ...
>   if (!*p) ...
> 
> which would you use?
> 
> In my opinion, the last one is truly awful, because it's not always
> easy to spot the '!' between '(' and '*' in all fonts. And some
> coding guidelines unhelpfully disallow a space after '('.
> 
> Regards.
> 

I would not use any of them as they stand - at first glance, they look
like mistakes.  I would want more context, proper names, and maybe even
typedef's depending on the situation - and then the "best" arrangement
would depend on the details.

Other possibilities that you have missed include:

	int * q = *p;	// Using better names, of course...
	if (q = NULL) ...

	if (p[0] == NULL) ...

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

#100881

On 02/01/2017 14:28, David Brown wrote:
> On 02/01/17 14:19, Noob wrote:
>> On 29/12/2016 21:53, Thiago Adams wrote:
>>
>>> Do you have some style guideline for pointer checking?
>>>
>>> This is a kind of poll:
>>>
>>>
>>>    //Style 1
>>>    if (pVariable) { /*...*/ }
>>>
>>>    //Style 2
>>>    if (pVariable != NULL)  { /*...*/ }
>>>
>>>    //Style 3
>>>    if (pVariable != 0) { /*...*/ }
>>>
>>> Do you dislike one of them?
>>> Do you use only one of them?
>>> Do you use more than one?
>>> Other?
>>
>> Slightly different situation, same question:
>>
>> void foo(int **p)
>> {
>>   if (*p == NULL) ...
>>   if (*p == 0) ...
>>   if (!*p) ...
>>
>> which would you use?
>>
>> In my opinion, the last one is truly awful, because it's not always
>> easy to spot the '!' between '(' and '*' in all fonts. And some
>> coding guidelines unhelpfully disallow a space after '('.
>>
>> Regards.
>>
> 
> I would not use any of them as they stand - at first glance, they look
> like mistakes.  I would want more context, proper names, and maybe even
> typedef's depending on the situation - and then the "best" arrangement
> would depend on the details.
> 
> Other possibilities that you have missed include:
> 
> 	int * q = *p;	// Using better names, of course...
> 	if (q = NULL) ...
             ^^^
Fail ;-)

Here's the /actual/ situation I had in mind:

void aux_read(void *chip, u8 **buf, int len, int *pos)
{
	*pos += len;

	if (*buf == NULL) {
		/* skip over "len" bytes */
		cmdfunc(chip, CMD_RNDOUT, *pos, -1);
	} else {
		read_buf(chip, *buf, len);
		*buf += len;
	}
}

Regards.

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

#100885 — Re: Using == operator

On 02/01/2017 18:13, Stefan Ram wrote:
> Noob <root@127.0.0.1> writes:
>>> 	if (q = NULL) ...
>>             ^^^
>> Fail ;-)
> 
>   And we also should not forget another possibility
>   of how the friends of »==« might fail!
> 
>   Can you spot the (potential) error in the following
>   program?
> 
> #include <ctype.h>
> #include <stdio.h>
> #include <stdbool.h>
> 
> int main( void )
> { if( isprint( 20 )== true )

isprint() returns zero/nonzero.
'true' might be a different nonzero.

  if (isprint(x) != 0) ...
  if (isprint(x)) ...

In my opinion, pointers are not booleans, and should be compared
to a pointer.

  if (p == NULL) ...
  if (q != NULL) ...

Regards.

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

#100918 — Re: Using == operator

On 02/01/17 19:03, Noob wrote:
> On 02/01/2017 18:13, Stefan Ram wrote:
>> Noob <root@127.0.0.1> writes:
>>>> 	if (q = NULL) ...
>>>             ^^^
>>> Fail ;-)
>>
>>   And we also should not forget another possibility
>>   of how the friends of »==« might fail!
>>
>>   Can you spot the (potential) error in the following
>>   program?
>>
>> #include <ctype.h>
>> #include <stdio.h>
>> #include <stdbool.h>
>>
>> int main( void )
>> { if( isprint( 20 )== true )
>
> isprint() returns zero/nonzero.
> 'true' might be a different nonzero.
>
>   if (isprint(x) != 0) ...
>   if (isprint(x)) ...
>
> In my opinion, pointers are not booleans, and should be compared
> to a pointer.
>
>   if (p == NULL) ...
>   if (q != NULL) ...
>

Pointers are not booleans - but "if" treats its "argument" exactly as 
though it were converted to a boolean.  If you consider the conversion 
of something to boolean as meaning converting to true/false or 
valid/invalid, then I don't think it is unreasonable to write "if (p)" - 
you are simply asking if p is "valid".

(That would also avoid my typo.)

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

#100921 — Re: Using == operator

On Monday, January 2, 2017 at 10:41:57 PM UTC, David Brown wrote:
> On 02/01/17 19:03, Noob wrote:
> > On 02/01/2017 18:13, Stefan Ram wrote:
> >> Noob <root@127.0.0.1> writes:
> >>>> 	if (q = NULL) ...
> >>>             ^^^
> >>> Fail ;-)
> >>
> >>   And we also should not forget another possibility
> >>   of how the friends of »==« might fail!
> >>
> >>   Can you spot the (potential) error in the following
> >>   program?
> >>
> >> #include <ctype.h>
> >> #include <stdio.h>
> >> #include <stdbool.h>
> >>
> >> int main( void )
> >> { if( isprint( 20 )== true )
> >
> > isprint() returns zero/nonzero.
> > 'true' might be a different nonzero.
> >
> >   if (isprint(x) != 0) ...
> >   if (isprint(x)) ...
> >
> > In my opinion, pointers are not booleans, and should be compared
> > to a pointer.
> >
> >   if (p == NULL) ...
> >   if (q != NULL) ...
> >
> 
> Pointers are not booleans - but "if" treats its "argument" exactly as 
> though it were converted to a boolean.  If you consider the conversion 
> of something to boolean as meaning converting to true/false or 
> valid/invalid, then I don't think it is unreasonable to write "if (p)" - 
> you are simply asking if p is "valid".
> 
Also
            if(node->next)

reads like English.

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

#100933 — Re: Using == operator

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
[...]
> Also
>             if(node->next)
>
> reads like English.

Does it?  C has the convention that using a value as a condition
implicitly compares that value to zero.  English has no such convention.

For example, suppose I have a bag that may or may not contain any
apples.  In C, you can say either "if (apple_count != 0)" or
"if (apple_count)".  In English, "If the number of apples in the
bag then ..."  doesn't make sense.

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web