Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Alternatives to modifying loop var in the loop.

Reply
Thread Tools

Alternatives to modifying loop var in the loop.

 
 
Aleksandar Kuktin
Guest
Posts: n/a
 
      01-03-2014
On Fri, 03 Jan 2014 09:34:03 -0500, James Kuyper wrote:

> On 01/03/2014 07:52 AM, Aleksandar Kuktin wrote:
>> On Thu, 02 Jan 2014 13:43:02 -0800, Keith Thompson wrote:
>>
>>> http://www.velocityreviews.com/forums/(E-Mail Removed) (Joe keane) writes:
>>>> In article <l9r6i6$ku8$(E-Mail Removed)>,
>>>> Nick Bowler <(E-Mail Removed)> wrote:
>>>>> That particular warning is not enabled by default so you can simply,
>>>>> well, not enable it. I guess that's sort of like turning it off.
>>>>
>>>> How about this:
>>>>
>>>> const char foo[6] = "abcdef";
>>>
>>> What about it? What are you asking? (gcc 4.7.2 at least doesn't warn
>>> about it with "-Wall -Wextra".)

>>
>> No NULL terminator. String six chars long is stored in a buffer six
>> chars long.

>
> True - which might or might not be a problem, depending upon whether or
> not the author intended that to be the case. Keith was probably well
> aware of that - the question is, what was Joe's point in bringing that
> up?


Apologies - I'm too trigger happy for my own good.

I thought this is part of the str* discussion in the other part of the
thread. And, in that context, I assumed Joe was asking bringing up
something along the lines strlcpy vs. non-terminated string but, again, I
confused the discussion in which this series of posts appears.
 
Reply With Quote
 
 
 
 
Keith Thompson
Guest
Posts: n/a
 
      01-03-2014
Aleksandar Kuktin <(E-Mail Removed)> writes:
> On Thu, 02 Jan 2014 13:43:02 -0800, Keith Thompson wrote:
>> (E-Mail Removed) (Joe keane) writes:
>>> In article <l9r6i6$ku8$(E-Mail Removed)>,
>>> Nick Bowler <(E-Mail Removed)> wrote:
>>>>That particular warning is not enabled by default so you can simply,
>>>>well, not enable it. I guess that's sort of like turning it off.
>>>
>>> How about this:
>>>
>>> const char foo[6] = "abcdef";

>>
>> What about it? What are you asking? (gcc 4.7.2 at least doesn't warn
>> about it with "-Wall -Wextra".)

>
> No NULL terminator. String six chars long is stored in a buffer six chars
> long.


Yes, I know. BTW, NULL is (a macro that expands to) a null *pointer*
constant; it shouldn't be used to refer to the null character.

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <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"
 
Reply With Quote
 
 
 
 
Aleksandar Kuktin
Guest
Posts: n/a
 
      01-03-2014
On Fri, 03 Jan 2014 09:12:27 -0800, Keith Thompson wrote:

> Yes, I know. BTW, NULL is (a macro that expands to) a null *pointer*
> constant; it shouldn't be used to refer to the null character.


Sorry for the noise. Confused the discussion.
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      01-03-2014
James Kuyper <(E-Mail Removed)> writes:
> On 01/02/2014 07:37 PM, (E-Mail Removed) wrote:
>> On Thursday, January 2, 2014 5:34:49 PM UTC, James Kuyper wrote:
>>> I only get one warning, about the use of = in a context where == might
>>> have been meant - what's the other warning?

>>
>> The second warning is about
>>
>> while (xxx);
>>
>> Single semicolon after the while condition without intervening white
>> space is quite possibly a mistake. This one is most likely
>> intentional:
>>
>> while (xxx)
>> ;

>
> Odd - I've used that construct occasionally, and I always wrote it the
> first way, which seems more natural to me. My compiler doesn't warn
> about that issue with the settings I use.
>
>> I'm currently using Clang for everything; there is a list of about 40
>> warnings that can be turned on/off, and there are maybe five that we
>> have disabled because they warn about things that are indeed not
>> justified. If I have to change
>>
>> while (*d++=*s++);
>>
>> to
>>
>> while ((*d++ = *s++) != 0)

>
> How do you decide when to stop adding !=0? All of the following mean the
> same thing:
>
> while (a)
> while (a!=0)
> while ((a!=0) !=0)
> etc.
>
> My policy is to stop adding !=0 before the first time.


My policy (not to imply that there's anything wrong with yours)
is to use an explicit comparison when the value being tested is not
"boolean", i.e., when it carries information beyond "zero is false,
non-zero is true". For example, I don't use a pointer value directly
as a condition; I'd write "if (ptr != NULL)" rather than "if (ptr)".

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <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"
 
Reply With Quote
 
Ben Bacarisse
Guest
Posts: n/a
 
      01-03-2014
James Kuyper <(E-Mail Removed)> writes:

> On 01/02/2014 07:37 PM, (E-Mail Removed) wrote:
>> [...] If I have to change
>>
>> while (*d++=*s++);
>>
>> to
>>
>> while ((*d++ = *s++) != 0)

>
> How do you decide when to stop adding !=0?


He stops there, because that form (apparently) silences a warning. The
explanation was in the immediately following text that got snipped: "If
I have to change ... to ... /to avoid warnings that's fine with me/.".

--
Ben.
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      01-03-2014
On 01/03/2014 03:18 PM, Ben Bacarisse wrote:
> James Kuyper <(E-Mail Removed)> writes:
>
>> On 01/02/2014 07:37 PM, (E-Mail Removed) wrote:
>>> [...] If I have to change
>>>
>>> while (*d++=*s++);
>>>
>>> to
>>>
>>> while ((*d++ = *s++) != 0)

>>
>> How do you decide when to stop adding !=0?

>
> He stops there, because that form (apparently) silences a warning. The
> explanation was in the immediately following text that got snipped: "If
> I have to change ... to ... /to avoid warnings that's fine with me/.".


Yes, but he also explaining that he was willing to turn off warnings
that he considered unjustified - implying that he considers this one
justified. I'm don't remember if my compiler has the option to warn
about such things, but if it did, I've turned it off. So my question was
equivalent to asking "why don't your turn that warning off?".
--
James Kuyper
 
Reply With Quote
 
glen herrmannsfeldt
Guest
Posts: n/a
 
      01-03-2014
Aleksandar Kuktin <(E-Mail Removed)> wrote:
> On Thu, 02 Jan 2014 13:43:02 -0800, Keith Thompson wrote:
>> (E-Mail Removed) (Joe keane) writes:


(snip)
>>> How about this:


>>> const char foo[6] = "abcdef";


(snip)
> No NULL terminator. String six chars long is stored in a
> buffer six chars long.


No, not a string but six characters are stored there.

It is short for:

const char foo[6]={'a', 'b', 'c', 'd', 'e', 'f',};

which has many uses. (Among others, note that sizeof gives
the right size in both cases, but not if you add the null.)

If you really want the string, leave off the 6, the compiler will
count them for you, including the null. Compilers count better
than people do.

-- glen
 
Reply With Quote
 
glen herrmannsfeldt
Guest
Posts: n/a
 
      01-04-2014
(E-Mail Removed) wrote:

(snip)
> One of the warnings is for "result of assignment cannot be
> used as controlling expression of an if, for, or while statement".
> If you write "if (a = b)... " it is obviously not clear whether
> you meant it or meant to use "==". Several ways to tell the
> compiler "I meant it". One is to write "if ((a = b))...", another
> is "if ((a = b) != 0)...". The first one looks daft to me,
> so I use the second.


The wording doesn't sound like warning wording. "Cannot"
should be used for violations of the standard language.
Maybe "should not" or "preferably not" would be better.

> The second warning is to avoid code like


> for (i = 0; i < n; ++i);
> a [i] = 0;


> or


> if (x > 0);
> ++x;


> which both most likely do _not_ do what the programmer intended.


I usually put at least one space. I suppose some might use {}.

Since the above loop has no other effect than to set i equal to n,
unless n is negative, I wouldn't be against the warning.

If the loop has more useful side effects, though, I would rather
not have a warning.

I don't remember ever having made that mistake.

> And there are really two criteria for deciding which warnings
> to enable: (1) How likely is it if I get the warning that it
> is actually a bug in my code, and (2) how much of a pain is it
> to write code that avoids the warning when it is not justified.
> In the string copy loop, the change is quite trivial.


It is always cost vs. benefit. Reading warnings takes time,
and so has a cost. The cost, multiplied by its probability
should be balanced against the benefit, that is, the cost
and probability of missing the bug.

-- glen
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
The node.js Community is Quietly Changing the Face of Open Source Rodrick Brown Python 2 04-17-2013 04:47 PM
Re: The node.js Community is Quietly Changing the Face of Open Source Sven Python 0 04-16-2013 04:41 PM
Re: The node.js Community is Quietly Changing the Face of Open Source Ned Batchelder Python 0 04-16-2013 04:25 PM
Is there a difference between the use of the word montage vscollage Danny D. Digital Photography 8 04-15-2013 02:24 PM
Windows 8 - so bad it's hastening the death of the PC? ~misfit~ NZ Computing 18 04-15-2013 04:15 AM



Advertisments