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

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

Issues with setting variables to true or false: how does the compiler understands it

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

Contents

  Issues with setting variables to true or false: how does the compiler understands it Alla _ <modelling.data@gmail.com> - 2015-10-24 02:17 -0700
    Issues with setting variables to true or false: how does the compiler understands it asetofsymbols@gmail.com - 2015-10-24 03:29 -0700
      Re: Issues with setting variables to true or false: how does the compiler understands it Alla _ <modelling.data@gmail.com> - 2015-10-24 03:38 -0700
    Re: Issues with setting variables to true or false: how does the compiler understands it Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-24 04:30 -0700
      Re: Issues with setting variables to true or false: how does the compiler understands it gazelle@shell.xmission.com (Kenny McCormack) - 2015-10-24 12:04 +0000
    Issues with setting variables to true or false: how does the compiler understands it asetofsymbols@gmail.com - 2015-10-24 04:59 -0700
      Re: Issues with setting variables to true or false: how does the compiler understands it Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-24 14:28 +0100
        Re: Issues with setting variables to true or false: how does the compiler understands it asetofsymbols@gmail.com - 2015-10-24 07:26 -0700
          Re: Issues with setting variables to true or false: how does the compiler understands it Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-24 17:06 +0100
    Re: Issues with setting variables to true or false: how does the compiler understands it James Kuyper <jameskuyper@verizon.net> - 2015-10-24 11:56 -0400
      Re: Issues with setting variables to true or false: how does the compiler understands it Keith Thompson <kst-u@mib.org> - 2015-10-24 12:02 -0700
        Re: Issues with setting variables to true or false: how does the compiler understands it supercat@casperkitty.com - 2015-10-24 15:45 -0700
          Re: Issues with setting variables to true or false: how does the compiler understands it Keith Thompson <kst-u@mib.org> - 2015-10-24 16:28 -0700
            Re: Issues with setting variables to true or false: how does the compiler understands it Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-24 16:44 -0700
              Re: Issues with setting variables to true or false: how does the compiler understands it supercat@casperkitty.com - 2015-10-24 19:34 -0700
            Re: Issues with setting variables to true or false: how does the compiler understands it supercat@casperkitty.com - 2015-10-24 19:30 -0700
              Re: Issues with setting variables to true or false: how does the compiler understands it Keith Thompson <kst-u@mib.org> - 2015-10-24 20:33 -0700
            Re: Issues with setting variables to true or false: how does the compiler understands it Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-28 11:16 -0700
              Re: Issues with setting variables to true or false: how does the compiler understands it Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-10-28 15:12 -0400
                Re: Issues with setting variables to true or false: how does the compiler understands it Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-29 12:18 +0000
                  Re: Issues with setting variables to true or false: how does the compiler understands it raltbos@xs4all.nl (Richard Bos) - 2015-10-29 21:51 +0000
                    Re: Issues with setting variables to true or false: how does the compiler understands it Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-30 08:38 -0700
                Re: Issues with setting variables to true or false: how does the compiler understands it Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-30 05:34 -0700
              Re: Issues with setting variables to true or false: how does the compiler understands it Keith Thompson <kst-u@mib.org> - 2015-10-28 14:08 -0700
                Re: Issues with setting variables to true or false: how does the compiler understands it Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-30 06:14 -0700
              Re: Issues with setting variables to true or false: how does the compiler understands it glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-28 21:50 +0000
                Re: Issues with setting variables to true or false: how does the compiler understands it supercat@casperkitty.com - 2015-10-28 15:08 -0700
                  Re: Issues with setting variables to true or false: how does the compiler understands it glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-28 22:47 +0000
                    Re: Issues with setting variables to true or false: how does the compiler understands it Robert Wessel <robertwessel2@yahoo.com> - 2015-10-28 18:35 -0500
                      Re: Issues with setting variables to true or false: how does the compiler understands it supercat@casperkitty.com - 2015-10-28 18:12 -0700
                      Re: Issues with setting variables to true or false: how does the compiler understands it glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-29 01:35 +0000
                        Re: Issues with setting variables to true or false: how does the compiler understands it Robert Wessel <robertwessel2@yahoo.com> - 2015-10-28 21:12 -0500
                          Re: Issues with setting variables to true or false: how does the compiler understands it supercat@casperkitty.com - 2015-10-28 19:52 -0700
                    Re: Issues with setting variables to true or false: how does the compiler understands it supercat@casperkitty.com - 2015-10-28 18:01 -0700
                Re: Issues with setting variables to true or false: how does the compiler understands it Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-30 03:47 -0700
    Re: Issues with setting variables to true or false: how does the compiler understands it Barry Schwarz <schwarzb@dqel.com> - 2015-10-24 09:54 -0700
    Re: Issues with setting variables to true or false: how does the compiler understands it Keith Thompson <kst-u@mib.org> - 2015-10-24 12:13 -0700
    Re: Issues with setting variables to true or false: how does the compiler understands it Richard Heathfield <rjh@cpax.org.uk> - 2015-10-24 21:50 +0100
    Re: Issues with setting variables to true or false: how does the compiler understands it Alla _ <modelling.data@gmail.com> - 2015-10-25 04:04 -0700
      Re: Issues with setting variables to true or false: how does the compiler understands it Barry Schwarz <schwarzb@dqel.com> - 2015-10-25 08:32 -0700
        Re: Issues with setting variables to true or false: how does the compiler understands it Richard Heathfield <rjh@cpax.org.uk> - 2015-10-25 18:19 +0000
        Re: Issues with setting variables to true or false: how does the compiler understands it Alla _ <modelling.data@gmail.com> - 2015-10-25 11:30 -0700
          Re: Issues with setting variables to true or false: how does the compiler understands it Richard Heathfield <rjh@cpax.org.uk> - 2015-10-25 18:56 +0000
            Re: Issues with setting variables to true or false: how does the compiler understands it Alla _ <modelling.data@gmail.com> - 2015-10-25 20:59 -0700
              Re: Issues with setting variables to true or false: how does the compiler understands it Anand Hariharan <mailto.anand.hariharan@gmail.com> - 2015-10-25 21:49 -0700
                Re: Issues with setting variables to true or false: how does the compiler understands it Richard Heathfield <rjh@cpax.org.uk> - 2015-10-26 08:10 +0000
                  Re: Issues with setting variables to true or false: how does the compiler understands it Anand Hariharan <mailto.anand.hariharan@gmail.com> - 2015-10-26 16:05 -0700
                    Re: Issues with setting variables to true or false: how does the compiler understands it Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-27 00:34 +0000
                      Re: Issues with setting variables to true or false: how does the compiler understands it Keith Thompson <kst-u@mib.org> - 2015-10-27 09:04 -0700
                        Re: Issues with setting variables to true or false: how does the compiler understands it Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-27 21:24 +0000
                    Re: Issues with setting variables to true or false: how does the compiler understands it Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-26 18:16 -0700
                    Re: Issues with setting variables to true or false: how does the compiler understands it Richard Heathfield <rjh@cpax.org.uk> - 2015-10-27 02:33 +0000
                      Re: Issues with setting variables to true or false: how does the compiler understands it Keith Thompson <kst-u@mib.org> - 2015-10-27 09:08 -0700
            Re: Issues with setting variables to true or false: how does the compiler understands it Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-26 11:22 +0000
              Re: Issues with setting variables to true or false: how does the compiler understands it Richard Heathfield <rjh@cpax.org.uk> - 2015-10-26 11:35 +0000
                Re: Issues with setting variables to true or false: how does the compiler understands it Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-26 17:00 +0000
                  Re: Issues with setting variables to true or false: how does the compiler understands it Richard Heathfield <rjh@cpax.org.uk> - 2015-10-26 17:59 +0000
            Re: Issues with setting variables to true or false: how does the compiler understands it Keith Thompson <kst-u@mib.org> - 2015-10-26 07:55 -0700
              Re: Issues with setting variables to true or false: how does the compiler understands it Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-26 17:06 +0000
              Re: Issues with setting variables to true or false: how does the compiler understands it supercat@casperkitty.com - 2015-10-26 10:56 -0700
              Re: Issues with setting variables to true or false: how does the compiler understands it glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-26 20:14 +0000
                Re: Issues with setting variables to true or false: how does the compiler understands it Keith Thompson <kst-u@mib.org> - 2015-10-26 17:09 -0700
            Re: Issues with setting variables to true or false: how does the compiler understands it Bartc <bc@freeuk.com> - 2015-10-26 23:39 +0000
              Re: Issues with setting variables to true or false: how does the compiler understands it Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-27 12:31 +0000
                Re: Issues with setting variables to true or false: how does the compiler understands it Richard Heathfield <rjh@cpax.org.uk> - 2015-10-27 12:45 +0000
                  Re: Issues with setting variables to true or false: how does the compiler understands it Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-27 13:24 +0000
                    Re: Issues with setting variables to true or false: how does the compiler understands it Richard Heathfield <rjh@cpax.org.uk> - 2015-10-27 13:41 +0000
                      Re: Issues with setting variables to true or false: how does the compiler understands it Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-27 19:43 +0000
                      Re: Issues with setting variables to true or false: how does the compiler understands it Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-27 19:47 +0000
                Re: Issues with setting variables to true or false: how does the compiler understands it Bartc <bc@freeuk.com> - 2015-10-27 13:20 +0000
                  Re: Issues with setting variables to true or false: how does the compiler understands it Richard Heathfield <rjh@cpax.org.uk> - 2015-10-27 13:28 +0000
                  Re: Issues with setting variables to true or false: how does the compiler understands it Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-27 13:54 +0000
                    Re: Issues with setting variables to true or false: how does the compiler understands it supercat@casperkitty.com - 2015-10-27 07:51 -0700
                      Re: Issues with setting variables to true or false: how does the compiler understands it Bartc <bc@freeuk.com> - 2015-10-27 16:46 +0000
                        Re: Issues with setting variables to true or false: how does the compiler understands it supercat@casperkitty.com - 2015-10-27 10:52 -0700
                          Re: Issues with setting variables to true or false: how does the compiler understands it Bartc <bc@freeuk.com> - 2015-10-27 18:51 +0000
                            Re: Issues with setting variables to true or false: how does the compiler understands it supercat@casperkitty.com - 2015-10-27 12:17 -0700
                              Re: Issues with setting variables to true or false: how does the compiler understands it Bartc <bc@freeuk.com> - 2015-10-27 19:34 +0000
                                Re: Issues with setting variables to true or false: how does the compiler understands it supercat@casperkitty.com - 2015-10-27 13:10 -0700
                                  Re: Issues with setting variables to true or false: how does the compiler understands it Keith Thompson <kst-u@mib.org> - 2015-10-27 13:41 -0700
                                  Re: Issues with setting variables to true or false: how does the compiler understands it Bartc <bc@freeuk.com> - 2015-10-27 23:11 +0000
                                    Re: Issues with setting variables to true or false: how does the compiler understands it Keith Thompson <kst-u@mib.org> - 2015-10-27 19:02 -0700
                                      Re: Issues with setting variables to true or false: how does the compiler understands it gazelle@shell.xmission.com (Kenny McCormack) - 2015-10-28 07:09 +0000
                                    Re: Issues with setting variables to true or false: how does the compiler understands it Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-28 11:27 +0000
                      Re: Issues with setting variables to true or false: how does the compiler understands it Keith Thompson <kst-u@mib.org> - 2015-10-27 12:27 -0700
                        Re: Issues with setting variables to true or false: how does the compiler understands it supercat@casperkitty.com - 2015-10-27 13:18 -0700

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

#74208

Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:

> On Wed, 2015-10-28, Eric Sosman wrote:
> > On 10/28/2015 2:16 PM, Tim Rentsch wrote:

> >> know.  For example, compare
> >>
> >>     if(p && *p != 0) ...
> >>
> >>     if(p != NULL && *p != 0) ...
> >
> >      Why not
> >
> > 	if (p && *p) ...
> >
> > ?  If your objection to `== NULL' is that it tells you nothing
> > new, why does that same objection not also apply to `!= 0'?

> If his mind works like mine: a zero pointer is always a special case,
> associated with negative things like "invalid", "error", "false", "not
> found" and "the end".  For int, char and so on, it depends entirely on
> what they represent: sometimes 0 is special, sometimes it's not.

Even more to the point, sometimes 0 is special because it's the mid
point between negative and positive numbers, or the point at which the
function to be applied has no roots, in which case *p!=0 is the correct
usage; while sometimes it's special because it's, well, not non-zero,
not a valid customer number, booleanly false - and in that case, *p is
the right choice.

Richard

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

#74319

raltbos@xs4all.nl (Richard Bos) writes:

> Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
>
>> On Wed, 2015-10-28, Eric Sosman wrote:
>>> On 10/28/2015 2:16 PM, Tim Rentsch wrote:
>>>
>>>> know.  For example, compare
>>>>
>>>>     if(p && *p != 0) ...
>>>>
>>>>     if(p != NULL && *p != 0) ...
>>>
>>>      Why not
>>>
>>> 	if (p && *p) ...
>>>
>>> ?  If your objection to `== NULL' is that it tells you nothing
>>> new, why does that same objection not also apply to `!= 0'?
>>
>> If his mind works like mine:  a zero pointer is always a special case,
>> associated with negative things like "invalid", "error", "false", "not
>> found" and "the end".  For int, char and so on, it depends entirely on
>> what they represent:  sometimes   0 is special, sometimes it's not.
>
> Even more to the point, sometimes 0 is special because it's the mid
> point between negative and positive numbers, or the point at which the
> function to be applied has no roots, in which case *p!=0 is the correct
> usage;  while sometimes it's special because it's, well, not non-zero,
> not a valid customer number, booleanly false - and in that case, *p is
> the right choice.

Both of these comments pretty much match my sentiments.  My
thanks to you guys for jumping in.

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

#74279

Eric Sosman <esosman@comcast-dot-net.invalid> writes:

> On 10/28/2015 2:16 PM, Tim Rentsch wrote:
>> [...] In most cases I would
>> not include an explicit comparison for pointers (either to NULL
>> or to 0) because it doesn't tell me anything I don't already
>> know.  For example, compare
>>
>>     if(p && *p != 0) ...
>>
>>     if(p != NULL && *p != 0) ...
>
>     Why not
>
>     if (p && *p) ...
>
> ?  If your objection to `== NULL' is that it tells you nothing
> new, why does that same objection not also apply to `!= 0'?
> If you reply that `p' is a pointer but `*p' is not, I ask
> why a "zero" pointer should be treated differently from any
> other kind of zero.  (I also observe that from the fragment
> shown we cannot prove that `*p' is not a pointer!)

Actually this is a rather subtle question.  With NULL we know
that what is being compared is (most probably) a pointer.  The
test != 0 doesn't do that, since the two forms are semantically
equivalent (and work with pointers as well as non-pointers).  If
a != 0 comparison tells us anything it tells us something about
what the author was thinking.  Assuming for the moment the code
has a single author, what are some possibilities (ie, for what
an explicit != 0 could tell us)?

We might infer that *p is not of type _Bool or some other integer
type but being used like a _Bool.  It would be unusual, I think,
to have an explicit != 0 when what is being tested is a _Bool.
If what is being tested is not of type _Bool but is being used
like a _Bool, normally I would expect not to see an explicit
comparison.

Stepping back a bit, for pointers the value 0 (or NULL) is always
a distinguished, isolated value.  A null pointer is somehow
fundamentally different from a non-null pointer.  The semantics
of some C constructs, notably if()'s and while()'s, etc, was
chosen (in part) to dovetail with this aspect of pointer values.
Personally I think that was a good design decision.  Turning to
the case of integer values, some uses (but not all!) of integer
values parallel the behavior of pointer values in that a value of
zero is in "bin" and all non-zero values are in another "bin".
In short, in some uses zero is special, and others it isn't.  If
there is no explicit != 0, we might infer that what is being
compared falls into the first category (ie, in the author's
thoughts), and conversely for != 0 being present and the second
category.  So the presence, or absence, of != 0 could tell us
something about how the author thinks about what's going on.

It goes without saying that such inferences might not actually
hold in reality.  There is nothing stopping someone from putting
in, or taking out, != 0 comparisons foolishly, capriciously,
randomly, indiscriminately, or even maliciously.  In those cases
what we (sometimes) learn is that the author's thought processes
are rather different from our own.


>> [...]
>> I agree that doing an explicit comparision (eg, "!= NULL") can
>> sometimes be an aid to helping code be easier to read and
>> understand.  But I think it is wrong to conclude that therefore
>> there should be a rule for doing so always.
>
>     Fine.  The most important rule about rules is that rules
> should sometimes be broken.  We make rules to be our servants,
> not to be our masters.  Others may make rules to master us, but
> they'll be the first against the wall when the Revolution comes.

Hmmm.  I think there is a larger conversation to be had here, but
maybe it's better to save that for another day.

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

#74104

Tim Rentsch <txr@alumni.caltech.edu> writes:

[big snip]

>> supercat@casperkitty.com writes:
>>> On Saturday, October 24, 2015 at 6:29:17 PM UTC-5, Keith Thompson wrote:
[...]
>>>> I disagree;  there's nothing coincidental about it.  `if (ptr)` and
>>>> `if (ptr != NULL)` are semantically identical.  The latter expresses
>>>> my intent more clearly.
>>>
>>> Different people parse things differently;  I consider both to be idiomatic
>>> and don't have any problem with either, though I never use the NULL macro
>>
>> I also consider both to be idiomatic.  I simply prefer the more explicit
>> form, for reasons I've explained.
>
> It was reading this very last phrase that prompted me to go back
> and look at the earlier comments more closely.  On doing that I
> didn't come away with very much.  What you're saying strikes me
> as mostly just circular - you prefer the explicit form because it
> makes the pointerness more explicit.  As an explanation that
> isn't very satisfying.  Can you say it another way?  What I think
> you mean is that putting in the "!= NULL" part conveys more
> information, with the unstated assumption that the extra information
> is (in these cases) always valuable.  Does this comment capture,
> or at least largely capture, what you're trying to express?  If
> it doesn't, can you say more about what that is?

Yes, that's pretty much what I was trying to say.

> Assuming that my rephrasing above is more or less on the money,
> I would like to offer another viewpoint.  In most cases I would
> not include an explicit comparison for pointers (either to NULL
> or to 0) because it doesn't tell me anything I don't already
> know.  For example, compare
>
>    if(p && *p != 0) ...
>
>    if(p != NULL && *p != 0) ...
>
> I don't need the "!= NULL", because it's obvious that the
> variable p is a pointer.  Furthermore I would argue that
> routinely using "!= NULL" (or "== NULL") everywhere is actually
> harmful, because using it everywhere will lessen the impact in
> those places where it really is important to emphasize the
> pointerness.  If we use "!= NULL" to convey the information that
> the thing being compared is a pointer -- which usually isn't very
> much information -- we give up the possibility of using "!= NULL"
> to convey other information that the writer might want to
> express, and which can be a lot more significant.
>
> I agree that doing an explicit comparision (eg, "!= NULL") can
> sometimes be an aid to helping code be easier to read and
> understand.  But I think it is wrong to conclude that therefore
> there should be a rule for doing so always.

Yes, that's another viewpoint, and I don't have any concrete
arguments that it's invalid.

To expand on my own viewpoint, consider a non-C language (Pascal and
Ada are examples) in which only values of type Boolean (or bool,
or whatever the language calls it) can be used as conditions.
If you want to test whether a pointer is null or not, or whether
an integer is zero or not, you have to do an explicit comparison
or it won't compile.

When I'm programming in such a language, I don't miss the ability
to write terse conditions like `if (p)` at all.  And when I'm
programming in C, I don't find that ability particularly tempting
or useful.

You suggest writing the "!= NULL" in some cases when it's "a lot
more significant", and omitting it when it isn't.  Personally,
I find it easier and clearer just to use it consistently.

And if I see some code with the "!= NULL" being written out in some
cases but not in others, it likely won't occur to me that the ones
where it's written explicitly are more significant, so the choice of
whether to write "!= NULL" or not doesn't convey any real information
to me.

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

#74286

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

> Tim Rentsch <txr@alumni.caltech.edu> writes:
>
> [bigger snip]
>
> To expand on my own viewpoint, consider a non-C language (Pascal and
> Ada are examples) in which only values of type Boolean (or bool,
> or whatever the language calls it) can be used as conditions.
> If you want to test whether a pointer is null or not, or whether
> an integer is zero or not, you have to do an explicit comparison
> or it won't compile.
>
> When I'm programming in such a language, I don't miss the ability
> to write terse conditions like `if (p)` at all.  And when I'm
> programming in C, I don't find that ability particularly tempting
> or useful.
>
> You suggest writing the "!= NULL" in some cases when it's "a lot
> more significant", and omitting it when it isn't.  Personally,
> I find it easier and clearer just to use it consistently.

Yes, I think I understand what your view is.  I still don't
really understand why you have that view, but having noted
my lack of understanding I will just say thank you for the
comments and leave it there for now.

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

#74108

Tim Rentsch <txr@alumni.caltech.edu> wrote:
> Keith Thompson <kst-u@mib.org> writes:
 
(snip)

>> No, if I write `if (ptr != NULL)`, I'm testing whether ptr is unequal to
>> the null pointer.  If it's equal to NULL, it's because that's the most
>> recent value I stored in it.  I might also be *interested* in knowing
>> whether it's valid, but I have no way of testing that, so I don't
>> bother.

I suspect the OP is using valid in a different way than you are.

In CS theory, for example in a linked list or tree, each node
either points to a valid next node or it doesn't. 

Yes it would sometimes be nice to have a test for an invalid,
non-NULL pointer, but C doesn't supply that test.

Then there is the case where a pointer is valid, but isn't supposed
to be. I am sure I am not the only one to accidentally have a circular
lined list when it wasn't supposed to be circular. 

>> [snip partially replicated portion (appears below)]

(snip)

>> If I were designing a language from scratch, rather than having some
>> special operator to test whether a pointer is null, I'd just define
>> equality for pointers and a constant whose value is a null pointer --
>> and not permit pointer values to be used directly as conditions.  I've
>> used several languages that work that way.  If you happen to prefer the
>> way C does it, that's fine;  I'm merely expressing my preference.
 
> [here starts the second message]
> Keith Thompson <kst-u@mib.org> writes:
 
(snip, someone previously wrote)

>>>> I disagree;  there's nothing coincidental about it.  `if (ptr)` and
>>>> `if (ptr != NULL)` are semantically identical.  The latter expresses
>>>> my intent more clearly.

(and Keith wrote)

>> I also consider both to be idiomatic.  I simply prefer the more explicit
>> form, for reasons I've explained.
 
> It was reading this very last phrase that prompted me to go back
> and look at the earlier comments more closely.  On doing that I
> didn't come away with very much.  What you're saying strikes me
> as mostly just circular - you prefer the explicit form because it
> makes the pointerness more explicit.  As an explanation that
> isn't very satisfying.  Can you say it another way?  What I think
> you mean is that putting in the "!= NULL" part conveys more
> information, with the unstated assumption that the extra information
> is (in these cases) always valuable.  Does this comment capture,
> or at least largely capture, what you're trying to express?  If
> it doesn't, can you say more about what that is?

I think I agree with Tim, and not Keith on this one. 

It might be that I read:

   if(p) ...

as if p points to something then ..., and as I noted above this is
more in the CS sense than the C sense, I am not confused by it.

I might even suggest that I like this more than the test on integer
values. 

For comparison purposes, note that Java requires the explicit test.

As I understand it, the reason for Java requiring the test wasn't
to avoid this problem, but instead to avoid:

    if(x=y) ...

which, when x and y aren't boolean, isn't valid Java. 

So, they throw out if(p) to keep people from doing if(q=p) accidentally.

> Assuming that my rephrasing above is more or less on the money,
> I would like to offer another viewpoint.  In most cases I would
> not include an explicit comparison for pointers (either to NULL
> or to 0) because it doesn't tell me anything I don't already
> know.  For example, compare
 
>   if(p && *p != 0) ...
 
>   if(p != NULL && *p != 0) ...

and note that you did not consider the case:

    if(p && *p) ...

(where *p may or may not be a pointer).
 
> I don't need the "!= NULL", because it's obvious that the
> variable p is a pointer.  Furthermore I would argue that
> routinely using "!= NULL" (or "== NULL") everywhere is actually
> harmful, because using it everywhere will lessen the impact in
> those places where it really is important to emphasize the
> pointerness.  If we use "!= NULL" to convey the information that
> the thing being compared is a pointer -- which usually isn't very
> much information -- we give up the possibility of using "!= NULL"
> to convey other information that the writer might want to
> express, and which can be a lot more significant.

I agree with this one, though I find it isn't hard to get used
to the !=null in Java.

But I think I would give up the integer case before giving 
up the pointer case. For one, there are, in programs using pointers,
more tests of pointers to NULL than integers to 0. (Not counting 
the values of comparison operators.)
 
> I agree that doing an explicit comparision (eg, "!= NULL") can
> sometimes be an aid to helping code be easier to read and
> understand.  But I think it is wrong to conclude that therefore
> there should be a rule for doing so always.

I am now wondering about the possibility (which Java didn't take)

of allowing if(p) while disallowing if(q=p), but allowing if((q=p)!=NULL) 

That does complicate the defintion of expression in strange ways,
but might satisfy the "when it really is important to emphasize
the pointerness" case.

Also, C doesn't have anything like the Java instanceof operator.

-------------------------

For another comparison, note that PL/I uses = for both assignment
and comparison, and while assignments don't have value it does allow
multiple assignment in the form:

   x, y, z = 0;

(and with no operator like the C comma operator)


-- glen

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

#74111

On Wednesday, October 28, 2015 at 4:50:46 PM UTC-5, glen herrmannsfeldt wrote:
> But I think I would give up the integer case before giving 
> up the pointer case. For one, there are, in programs using pointers,
> more tests of pointers to NULL than integers to 0. (Not counting 
> the values of comparison operators.)

Sometimes integer types are used to represent combinations of bits, and
having any bits set is a more meaningful concept than comparison to the
value which doesn't have any.

> I am now wondering about the possibility (which Java didn't take)
> 
> of allowing if(p) while disallowing if(q=p), but allowing if((q=p)!=NULL) 
> 
> That does complicate the defintion of expression in strange ways,
> but might satisfy the "when it really is important to emphasize
> the pointerness" case.

IMHO, good languages should have lots of such cases.  For example, few
compilers will warn about "long1 = int1+int2;" since the conversion from
"int" to "long" is "lossless", but if I were designing the language I would
regard the result of arithmetic expressions as being a type which is
implicitly convertible to an integer of the same type, but cannot be
converted to a larger type--implicitly *or* explicitly--without having first
been converted to its own type (e.g. "long1 = (int)(int1+int2);".

It should not be hard to say that the assignment operator yields a result
whose type is not usable in most contexts requiring a conditional expression
though I'd allow the "!" operator there.  I use !! a lot and consider it as
an idiomatic way of saying that something isn't a Boolean but I wish to test
it in the usual fashion.

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

#74113

supercat@casperkitty.com wrote:

(I wrote)

>> But I think I would give up the integer case before giving 
>> up the pointer case. For one, there are, in programs using pointers,
>> more tests of pointers to NULL than integers to 0. (Not counting 
>> the values of comparison operators.)
 
> Sometimes integer types are used to represent combinations of bits, and
> having any bits set is a more meaningful concept than comparison to the
> value which doesn't have any.

One that hasn't come up very often, possibly with twos complement
machines being popular, is that negative zero has bit patterns
with not all bits zero, and should compare equal to zero.

(snip, I also wrote)
>> I am now wondering about the possibility (which Java didn't take)
 
>> of allowing if(p) while disallowing if(q=p), but allowing if((q=p)!=NULL) 
 
>> That does complicate the defintion of expression in strange ways,
>> but might satisfy the "when it really is important to emphasize
>> the pointerness" case.
 
> IMHO, good languages should have lots of such cases.  For example, few
> compilers will warn about "long1 = int1+int2;" since the conversion from
> "int" to "long" is "lossless", but if I were designing the language I would
> regard the result of arithmetic expressions as being a type which is
> implicitly convertible to an integer of the same type, but cannot be
> converted to a larger type--implicitly *or* explicitly--without having first
> been converted to its own type (e.g. "long1 = (int)(int1+int2);".

Java requires a cast on narrowing conversions, but not widening,
which I believe is about right. 
 
> It should not be hard to say that the assignment operator yields a result
> whose type is not usable in most contexts requiring a conditional expression
> though I'd allow the "!" operator there.  I use !! a lot and consider it as
> an idiomatic way of saying that something isn't a Boolean but I wish to test
> it in the usual fashion.

-- glen

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

#74117

On Wed, 28 Oct 2015 22:47:10 +0000 (UTC), glen herrmannsfeldt
<gah@ugcs.caltech.edu> wrote:
> 
>> IMHO, good languages should have lots of such cases.  For example, few
>> compilers will warn about "long1 = int1+int2;" since the conversion from
>> "int" to "long" is "lossless", but if I were designing the language I would
>> regard the result of arithmetic expressions as being a type which is
>> implicitly convertible to an integer of the same type, but cannot be
>> converted to a larger type--implicitly *or* explicitly--without having first
>> been converted to its own type (e.g. "long1 = (int)(int1+int2);".
>
>Java requires a cast on narrowing conversions, but not widening,
>which I believe is about right. 


I agree.  Although simply forbidding the (uncasted) mixing of signed
and unsigned (and float*) arithmetic has a lot going for it (but
narrowing conversion should still be explicit).  OTOH, in C we don't
generally know what conversions are widening or not, it's specific to
the implementation.


*I waffle on complex - is complex just a wider version of a float, or
a different class?

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

#74129

On Wednesday, October 28, 2015 at 6:34:38 PM UTC-5, robert...@yahoo.com wrote:
> I agree.  Although simply forbidding the (uncasted) mixing of signed
> and unsigned (and float*) arithmetic has a lot going for it (but
> narrowing conversion should still be explicit).  OTOH, in C we don't
> generally know what conversions are widening or not, it's specific to
> the implementation.

I think the real cause of the difficulty is a failure of languages to
recognize that there are two usage cases for unsigned types.  Using a
four-digit and 8-digit decimal types for convenience of discussion, consider
the following two questions:

   Last month the gas meter read 9931.  Now it reads 1013.  The previous
   year-to-date total usage was 00125432; what should the new total be?

   Last month a local group had 9931 people.  Now it has only 1013.  The
   national organization had 00125432 people before this change; how many
   will it have once the change is applied?

In both cases, it would seem that a long value should be adjusted with the
difference of two short values, but do you notice a key difference in
meaning?

For unsigned values whose usage follows the first pattern (algebraic rings)
there should be no permissible implicit conversions to types of other sizes,
though most operators should be able to combine a number type with a ring
type yielding a ring-type result (e.g. adding a signed value to the meter
should make it run forward or backward mod 10000).  For those whose usage
follows the second pattern, computations should be performed using the next
larger signed type.

If one were to recognize separate types for the two usages, I think it would
be pretty clearer what a lot of the rules should be than when having types
which straddle the fence between the two meanings.

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

#74132

Robert Wessel <robertwessel2@yahoo.com> wrote:

(snip, I wrote)
>>Java requires a cast on narrowing conversions, but not widening,
>>which I believe is about right. 
 
> I agree.  Although simply forbidding the (uncasted) mixing of signed
> and unsigned (and float*) arithmetic has a lot going for it (but
> narrowing conversion should still be explicit).  OTOH, in C we don't
> generally know what conversions are widening or not, it's specific to
> the implementation.

Java fixes the bit width of each type, so that doesn't happen.

On the other hand, the change in width with C compilers could be
surprising. One might expect something is not narrowing, and then
it turns out that it is on a different system.

Consider size_t to int, for example. 
  
> *I waffle on complex - is complex just a wider version of a float, or
> a different class?

Also, Java considers int to float widening, and float to int as
narrowing.

-- glen

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

#74134

On Thu, 29 Oct 2015 01:35:23 +0000 (UTC), glen herrmannsfeldt
<gah@ugcs.caltech.edu> wrote:

>Robert Wessel <robertwessel2@yahoo.com> wrote:
>
>(snip, I wrote)
>>>Java requires a cast on narrowing conversions, but not widening,
>>>which I believe is about right. 
> 
>> I agree.  Although simply forbidding the (uncasted) mixing of signed
>> and unsigned (and float*) arithmetic has a lot going for it (but
>> narrowing conversion should still be explicit).  OTOH, in C we don't
>> generally know what conversions are widening or not, it's specific to
>> the implementation.
>
>Java fixes the bit width of each type, so that doesn't happen.
>
>On the other hand, the change in width with C compilers could be
>surprising. One might expect something is not narrowing, and then
>it turns out that it is on a different system.
>
>Consider size_t to int, for example. 
>  
>> *I waffle on complex - is complex just a wider version of a float, or
>> a different class?
>
>Also, Java considers int to float widening, and float to int as
>narrowing.


A mistake, IMO.  Approximately no information losing conversions
should happen by default.  That being said, I'm not sure that if
integer-to-floating point conversions are allowed, if:

  fp32_a = fp32_b + int32_c;

should be invalid because you'd need to promote both sides of the
addition to double, or because the resulting double would have to be
narrowed for the assignment (although I lean towards the latter).

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

#74135

On Wednesday, October 28, 2015 at 9:12:21 PM UTC-5, robert...@yahoo.com wrote:
> A mistake, IMO.  Approximately no information losing conversions
> should happen by default.  That being said, I'm not sure that if
> integer-to-floating point conversions are allowed, if:
> 
>   fp32_a = fp32_b + int32_c;
> 
> should be invalid because you'd need to promote both sides of the
> addition to double, or because the resulting double would have to be
> narrowed for the assignment (although I lean towards the latter).

IMHO, languages should include distinct kinds of floating-point type for
scenarios where one wants an expression like f1+f2+f3 to be evaluated
strictly according to the rules of IEEE-754 single-precision math, vs
scenarios where one would like to have a perfectly-accurate type were it
not for the cost, but is willing to tolerate something less accurate but
more practical.  In the former situation, no implicit casts should be
allowed at all; in the latter situation, an expression like f1=d1+d2;
shouldn't require a cast, but d1=f1+f2; should [since it's hardly clear
whether the programmer is *expecting* the evluation to be done as single
or double, adding a cast in *either* case would improve the code].

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

#74126

On Wednesday, October 28, 2015 at 5:47:25 PM UTC-5, glen herrmannsfeldt wrote:
> Java requires a cast on narrowing conversions, but not widening,
> which I believe is about right. 

Which would be more likely to yield unexpected behavior if both were legal:

   long1 = int1+int2;
   float1 = float2 * 0.1;

Note that while the second may be slower than multiplying by 0.1f, if the
desire is to compute float2/10.0f, multiplying by 0.1 will be more accurate
than multiplying by 0.1f.

Also, what would you expect the value of Math.Round(123456789); to be?

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

#74264

glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:

> Tim Rentsch <txr@alumni.caltech.edu> wrote:
>> Keith Thompson <kst-u@mib.org> writes:

>> Assuming that my rephrasing above is more or less on the money,
>> I would like to offer another viewpoint.  In most cases I would
>> not include an explicit comparison for pointers (either to NULL
>> or to 0) because it doesn't tell me anything I don't already
>> know.  For example, compare
>>
>>   if(p && *p != 0) ...
>>
>>   if(p != NULL && *p != 0) ...
>
> and note that you did not consider the case:
>
>     if(p && *p) ...
>
> (where *p may or may not be a pointer).

I did consider it.  I just chose not to say anything
about it.

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

#73705

On Sat, 24 Oct 2015 02:17:39 -0700 (PDT), Alla _
<modelling.data@gmail.com> wrote:

<snip>

>I understand everything in the program, except for
>the usage of 'int started' within 'if else' statement.
>
> Here is the comment at the 'if (started)' line:
>
>/**"You'll display a comma only if you've
>already displayed a previous line.**/
>
>I assume the compiler knows that the previous line has been

The compiler does not know and does not care.  

Ignoring preprocessing and the optimization phase some compilers have
that may perform calculations during compile time to improve
performance, the compiler does not evaluate variables and expressions.
The compiler generates code that performs the evaluations and causes
any side effects in accordance with the language standard.  It is only
when your code executes that the value of an expression is computed.

If an expression is to be evaluated only under certain conditions (as
with an if statement), the code generated by the compiler includes the
test for that condition and a method of skipping the evaluation if the
test fails.  It is only during execution that the test is performed
and the expression evaluated or not depending on the result of the
test.

>displayed by receiving the '\n' input from the user, correct?
>Then 'started' should be false, and the program displays a comma.

started is an int.  There is no true or false value.  For this
discussion, the is only zero and non-zero.  A zero value will be
***treated as false*** in certain types of expressions.  One of those
types is a test in an if statement that has no relational operator
(such as == or >).  A non-zero value will be treated as true in this
case.


>Is the following process correct:
>
>- the user types in the first line of data;
>- the user hits ENTER;
>- upon receiving '\n', the program should print 
>out the first line, and then
>- display a comma.

Once again, you should learn to "play computer" and step through the
code manually, keeping track of each variable.  In this case, you are
unconsciously combining multiple steps but in the real world only one
of the steps is executed during any iteration of the while loop.

In the first iteration of the while loop, what is the value of
started?  Given this value, is it at all possible for the small printf
statement to execute during this iteration?  What happens if scanf
returns a value other than 3 during the second iteration?  Does a
comma get printed?

>How does the program know how to do that, if 

Since the program does not do that, your question is based on a false
premise.

>'started' has been initially set to 0, and not yet changed
>when the while loop starts for the fist time? Why the comma
>is not displayed first, if 'if(started)' comes first?

Play computer and see for yourself.  Alternately, get a compiler that
has a debugger that will let you step through the code one statement
at a time so you can see what is happening.  You need to pay much more
attention to details.

<snip>

>My confusion is about the 'started' variable.

Actually, your confusion is more about what an if statement means and
how it can have different effects during program execution.  You are
performing a static analysis will is guaranteed to produce the wrong
result 50% of the time.

>#include <stdio.h>
> int main()
>{
>    float latitude;
>    float longitude;
>    char info[80];
>    int started = 0; /**"We need to begin with "started" set       
>                     to 0, which means false."**/
>
>    puts("data=[");
>
>    while (scanf("%f,%f,%79[^\n]", , , ) == 3) 
>   {
>          if (started)
>              printf(",\n"); /**"You'll display a comma only if you've
>                             already displayed a previous line.**/
>          else
>              started = 1; /** "Once the loop has started, you can
>                            set "started" to 1, which is true.**/
>
>          printf("{latitude: %f, longitude: %f, info: '%s'}", , , );
>   }
>
>   puts("\n]");
>
>   return 0;
>}

-- 
Remove del for email

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

#73721

Alla _ <modelling.data@gmail.com> writes:
[...]
> My confusion is about the 'started' variable.
>
> #include <stdio.h>
>  int main()
> {
>     float latitude;
>     float longitude;
>     char info[80];
>     int started = 0; /**"We need to begin with "started" set       
>                      to 0, which means false."**/
>
>     puts("data=[");
>
>     while (scanf("%f,%f,%79[^\n]", , , ) == 3) 
>    {
>           if (started)
>               printf(",\n"); /**"You'll display a comma only if you've
>                              already displayed a previous line.**/
>           else
>               started = 1; /** "Once the loop has started, you can
>                             set "started" to 1, which is true.**/
>
>           printf("{latitude: %f, longitude: %f, info: '%s'}", , , );
>    }
>
>    puts("\n]");
>
>    return 0;
> }

The variable started is simply a flag used to keep track of whether
we're in the first iteration of the loop or not.  Here's a simpler
example, a program that counts from 1 to 5 and prints a different
message depending on whether it's printing the first line or not:

#include <stdio.h>
int main(void) {
    int started = 0;
    for (int i = 1; i <= 5; i ++) {
        printf("i = %d", i);
        if (started) {
            puts(", and we've been here before");
        }
        else {
            puts(", oh, this is new!");
            started = 1;
        }
    }
}

The output is:

i = 1, oh, this is new!
i = 2, and we've been here before
i = 3, and we've been here before
i = 4, and we've been here before
i = 5, and we've been here before

In modern C (post-C99), it's clearer to use a bool rather than an int
(changed lines are marked with comments):

#include <stdio.h>
#include <stdbool.h>        /* Add this line */
int main(void) {
    bool started = false;   /* Change int, 0 to bool, false */
    for (int i = 1; i <= 5; i ++) {
        printf("i = %d", i);
        if (started) {      /* No change here */
            puts(", and we've been here before");
        }
        else {
            puts(", oh, this is new!");
            started = true; /* change 1 to true */
        }
    }
}

JSON requires a commma after each element *except* the last.
The obvious way to do that would be to print a comma at the end of
each line, but omit the comma when you're printing the last line.
But it can be difficult or impossible to know whether the current
line is the last one -- whereas you can easily detect whether you're
on the *first* line by using a flag.  So rather than printing a
comma at the end of each element except the last, the program prints
a comma *before* each element except the first, which achieves the
same effect.

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

#73738

On 24/10/15 10:17, Alla _ wrote:

<snip>

> I understand everything in the program, except for
> the usage of 'int started' within 'if else' statement.
>
>   Here is the comment at the 'if (started)' line:
>
> /**"You'll display a comma only if you've
> already displayed a previous line.**/
>
> I assume the compiler knows that the previous line has been
> displayed by receiving the '\n' input from the user, correct?

No. The compiler doesn't know that the previous line has been displayed 
*at all*. In fact, by the time any lines at all have been displayed, the 
compiler has already done its job, put on its coat, and gone home for 
the day.

Your C compiler turns C source code into executable code. It is your 
computer, not your compiler, that runs the executable code.

> Then 'started' should be false, and the program displays a comma.

No idea. Let's look at the code and see what it says. (Further down.)

> Is the following process correct:
>
> - the user types in the first line of data;
> - the user hits ENTER;
> - upon receiving '\n', the program should print
> out the first line, and then
> - display a comma.

I was under the impression that you wanted to *not* print out a comma 
the first time through. Isn't that the whole point?

> How does the program know how to do that,

The program doesn't know anything how to do anything that you don't know 
how to do, because you're the one instructing it. So, to answer the 
question "how does the program know how to do that", you must first ask 
yourself the question, "how do *I* know how to do that?"

That's a terribly, terribly important point that you seem to be 
overlooking - if you don't understand the program, it isn't yet time for 
you to run that program.

> if
> 'started' has been initially set to 0, and not yet changed
> when the while loop starts for the fist time? Why the comma
> is not displayed first, if 'if(started)' comes first?
>
> Does 'if(started)' here mean 'if started is false',

No. If this confuses you, *always* write it out in full:

if(started != 0)

> or
> does 'if (started)' mean the same as if statement with a NULL pointer,
> where 'if (pointer != NULL)' is the same as 'if (pointer)?

You have been taught a short cut too early, and it is confusing you. So 
drop it! Always use explicit comparisons until they are second nature to 
you. The short cut will wait a year or two.

>
> My confusion is about the 'started' variable.
>
> #include <stdio.h>
>   int main()
> {
>      float latitude;
>      float longitude;
>      char info[80];
>      int started = 0; /**"We need to begin with "started" set
>                       to 0, which means false."**/

Why did you make this decision? Why did you decide that you need to 
begin with started set to 0? And who is "We"?


>
>      puts("data=[");
>
>      while (scanf("%f,%f,%79[^\n]", , , ) == 3)

That's never going to fly. You can't have empty arguments like that.

>     {
>            if (started)
>                printf(",\n"); /**"You'll display a comma only if you've
>                               already displayed a previous line.**/

This is fairly simple, Alla. It's an if statement. If started has the 
value 0, the above printf won't happen. First time through, that's the 
exact situation, so the printf doesn't happen, *only* on the first time 
through. *INSTEAD*, the else happens the first time through. (Every 
other time through the loop, the printf above does happen.)


>            else
>                started = 1; /** "Once the loop has started, you can
>                              set "started" to 1, which is true.**/

This only ever happens once.

>
>            printf("{latitude: %f, longitude: %f, info: '%s'}", , , );

This happens every time.

You might find it clearer to use braces *every* time:

if(started)
{
   printf(",\n");
}
else
{
   started = 1;
}

printf("whatever");

This makes it clearer that the second printf is not conditional on the 
value of 'started'.

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

#73760

Thank you Everyone for your help. 
To be honest, I didn't read articles 
containing profound discussions on JSON,
because this is too early for me. 
Thank you for clearing the topic on
these shortcuts.

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

#73770

On Sun, 25 Oct 2015 04:04:50 -0700 (PDT), Alla _
<modelling.data@gmail.com> wrote:

>Thank you Everyone for your help. 
>To be honest, I didn't read articles 
>containing profound discussions on JSON,
>because this is too early for me. 
>Thank you for clearing the topic on
>these shortcuts.

While the goal of the program was JSON output, your questions did not
address that aspect at all.  Your questions showed a misunderstanding
of some fundamental aspects of programming in C, particularly looping,
if statements, and the difference between events that occur at compile
time versus execution time.

-- 
Remove del for email

[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