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

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

the loop control

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

Contents

  the loop control jgk@panix.com (Joe keane) - 2011-10-29 21:38 +0000
    Re: the loop control Ian Collins <ian-news@hotmail.com> - 2011-10-30 10:48 +1300
    Re: the loop control Kaz Kylheku <kaz@kylheku.com> - 2011-10-29 22:10 +0000
      Re: the loop control jgk@panix.com (Joe keane) - 2011-10-31 15:21 +0000
        Re: the loop control James Kuyper <jameskuyper@verizon.net> - 2011-10-31 11:35 -0400
          Re: the loop control jgharston <jgh@arcade.demon.co.uk> - 2011-10-31 10:27 -0700
            Re: the loop control Seebs <usenet-nospam@seebs.net> - 2011-10-31 18:36 +0000
            Re: the loop control Robert Wessel <robertwessel2@yahoo.com> - 2011-10-31 13:49 -0500
            Re: the loop control Sjouke Burry <s@b> - 2011-10-31 18:49 +0000
            Re: the loop control James Kuyper <jameskuyper@verizon.net> - 2011-10-31 15:07 -0400
            Re: the loop control Keith Thompson <kst-u@mib.org> - 2011-10-31 13:56 -0700
        Re: the loop control Seebs <usenet-nospam@seebs.net> - 2011-10-31 17:18 +0000
          Re: the loop control Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-01 04:35 -0700
            Re: the loop control Seebs <usenet-nospam@seebs.net> - 2011-11-01 21:44 +0000
              Re: the loop control Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-11-02 01:16 -0700
        Re: the loop control Kaz Kylheku <kaz@kylheku.com> - 2011-10-31 19:23 +0000
          Re: the loop control jgk@panix.com (Joe keane) - 2011-11-02 04:47 +0000
        Re: the loop control Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-10-31 23:07 +0200
          Re: the loop control Ike Naar <ike@sverige.freeshell.org> - 2011-11-01 00:11 +0000
            Re: the loop control James Kuyper <jameskuyper@verizon.net> - 2011-10-31 22:01 -0400
              Re: the loop control Kaz Kylheku <kaz@kylheku.com> - 2011-11-01 02:51 +0000
                Re: the loop control James Kuyper <jameskuyper@verizon.net> - 2011-11-01 07:23 -0400
              Re: the loop control Ike Naar <ike@iceland.freeshell.org> - 2011-11-01 09:51 +0000
                Re: the loop control pete <pfiland@mindspring.com> - 2011-11-01 05:34 -0500
                Re: the loop control James Kuyper <jameskuyper@verizon.net> - 2011-11-01 07:30 -0400
                Re: the loop control James Kuyper <jameskuyper@verizon.net> - 2011-11-01 07:35 -0400
              Re: the loop control Hans Vlems <hvlems@freenet.de> - 2011-11-11 00:38 -0800
          Re: the loop control jgk@panix.com (Joe keane) - 2011-11-02 03:36 +0000
            Re: the loop control Ian Collins <ian-news@hotmail.com> - 2011-11-02 17:09 +1300
              Re: the loop control Keith Thompson <kst-u@mib.org> - 2011-11-02 03:56 -0700
        Re: the loop control Jorgen Grahn <grahn+nntp@snipabacken.se> - 2011-10-31 21:38 +0000
    Re: the loop control Acid Washed China Blue Jeans <chine.bleu@yahoo.com> - 2011-10-29 19:31 -0700
    Re: the loop control Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-10-29 23:11 -0600
    Re: the loop control "Philip Lantz" <prl@canterey.us> - 2011-10-29 22:47 -0700
      Re: the loop control jgk@panix.com (Joe keane) - 2011-10-31 16:36 +0000
        Re: the loop control Kaz Kylheku <kaz@kylheku.com> - 2011-10-31 19:30 +0000
          Re: the loop control blp@cs.stanford.edu (Ben Pfaff) - 2011-10-31 12:38 -0700
            Re: the loop control James Kuyper <jameskuyper@verizon.net> - 2011-10-31 15:51 -0400
              Re: the loop control blp@cs.stanford.edu (Ben Pfaff) - 2011-10-31 13:06 -0700
              Re: the loop control Keith Thompson <kst-u@mib.org> - 2011-10-31 14:17 -0700
                Re: the loop control Seebs <usenet-nospam@seebs.net> - 2011-11-01 21:44 +0000
              Re: the loop control Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-10-31 23:30 +0200
          Re: the loop control jgk@panix.com (Joe keane) - 2011-11-03 21:29 +0000
            Re: the loop control James Kuyper <jameskuyper@verizon.net> - 2011-11-03 18:00 -0400
            Re: the loop control Kaz Kylheku <kaz@kylheku.com> - 2011-11-04 00:43 +0000
              Re: the loop control jgk@panix.com (Joe keane) - 2011-11-11 02:24 +0000
        Re: the loop control Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-10-31 23:20 +0200
        Re: the loop control pete <pfiland@mindspring.com> - 2011-10-31 18:01 -0500
          Re: the loop control Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-11-02 01:20 +0200
    Re: the loop control 88888 Dihedral <dihedral88888@googlemail.com> - 2011-11-02 01:25 -0700

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

#12424

On 2011-11-01, James Kuyper <jameskuyper@verizon.net> wrote:
> On 10/31/2011 08:11 PM, Ike Naar wrote:
>> On 2011-10-31, Phil Carmody <thefatphil_demunged@yahoo.co.uk> wrote:
>> If a local variable is needed to maintain an unmodified copy of the original,
>> one might as well leave the original parameter unmodified,
>> and use a local variable as the entity-to-be-modified.
>> This is (arguably) cleaner, because the meaning of the parameter
>> does not change during the process.
>
> That depends entirely upon how you interpret the meaning of the
> parameter. Like any variable, if it's value varies, it's meaning must be
> something that can be said to remain unchanged despite the fact that the
> value has changed.
>
> The meaning of 'count' and 'point' do not change anywhere within the
> following code:
>
> 	void zero_array(
> 	    int *point,
> 	    int count
> 	){
> 	    while(count-- > 0)
> 	        *point = 0;

*point++ = 0;

> 	}
>
> At the start of the function, and at the end of each pass through the
> loop, 'count' contains the number of elements that still need to be
> zeroed, and if that count is non-zero, then 'point' points at the first
> of the elements that still need to be zeroed.

I.e. it's an iterative rewrite of the tail recursion:

 void zero_array(int *point, int count)
 {
   if (count > 0) {
     *point = 0;
     zero_array(point + 1, count - 1);
   }
 }

This local modification of arguments lets us write certain cases
of obvious recursion iteratively. Just assign the different values to the
parameters and loop.

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

#12436

On 10/31/2011 10:51 PM, Kaz Kylheku wrote:
> On 2011-11-01, James Kuyper <jameskuyper@verizon.net> wrote:
...
>> 	        *point = 0;
> 
> *point++ = 0;

Aaagh! My dogs urgently needed walking, so I didn't spend enough time
proofreading.
-- 
James Kuyper

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

#12432

On 2011-11-01, James Kuyper <jameskuyper@verizon.net> wrote:
> On 10/31/2011 08:11 PM, Ike Naar wrote:
>> On 2011-10-31, Phil Carmody <thefatphil_demunged@yahoo.co.uk> wrote:
>>> Needing to use something more than once, where use modifies that
>>> thing, clearly requires you to maintain an unmodified copy of the
>>> original.
>> 
>> If a local variable is needed to maintain an unmodified copy of the original,
>> one might as well leave the original parameter unmodified,
>> and use a local variable as the entity-to-be-modified.
>> This is (arguably) cleaner, because the meaning of the parameter
>> does not change during the process.
>
> That depends entirely upon how you interpret the meaning of the
> parameter. Like any variable, if it's value varies, it's meaning must be
> something that can be said to remain unchanged despite the fact that the
> value has changed.
>
> The meaning of 'count' and 'point' do not change anywhere within the
> following code:
>
> 	void zero_array(
> 	    int *point,
> 	    int count
> 	){
> 	    while(count-- > 0)
> 	        *point = 0;
> 	}
>
> At the start of the function, and at the end of each pass through the
> loop, 'count' contains the number of elements that still need to be
> zeroed, and if that count is non-zero, then 'point' points at the first
> of the elements that still need to be zeroed.

This is not an example where one needs a local variable to maintain
an unmodified copy of the original. And actually the meanings of
count and point *do* change, initially they describe the entire
set of points, and later on they describe the set of points
yet-to-be-processed.  In this simple example the difference is
futile, because there is no reason to keep the entire set for
later reference. Looking at a slightly more complicated example
that *does* need local variables:

    void froboz_array(int *point, int count)
    {
      int *all_point = point;
      int all_count = count;
      while (count-- > 0)
        fro(*point++);

      point = all_point;
      count = all_count;
      while (count-- > 0)
        boz(*point++);
    }

some might prefer a variant that is almost identical,
but has the advantage that it does not modify the parameters:

    void froboz_array(int *all_point, int all_count)
    {
      int *point = all_point;
      int count = all_count;
      while (count-- > 0)
        fro(*point++);

      point = all_point;
      count = all_count;
      while (count-- > 0)
        boz(*point++);
    }

In the simpler example that you showed (only one sweep
across the point array), one can make a tradeoff between two
desirable objectives:
a) keeping the parameters constant
b) minimizing the number of local variables

I think a) vs. b) is a honest tradeoff, and not a dumb vs. smart question.

>>> Needing to use something once, where use modifies that thing, clearly
>>> does not require you to maintain an unmodified copy of the original.
>>>
>>> If you are unable to see the difference between these cases, then you
>>> will clearly be hampered when it comes to chosing appropriate coding
>>> techniques. That, however, is your problem, and not the language's
>>> problem. 
>> 
>> If somebody has a different view, it's not necessarily because they
>> are "unable" to see things your way.
>
> He's not addressing your failure to agree with him, but rather your
> claim that the alternative approach leads to confusion. He's saying, in
> essence, that any person who would be confused for that reason still has
> a lot to learn about programming.

Phil was talking to Joe; I am not Joe.

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

#12435

Ike Naar wrote:
 
> In the simpler example that you showed (only one sweep
> across the point array), one can make a tradeoff between two
> desirable objectives:
> a) keeping the parameters constant
> b) minimizing the number of local variables
> 
> I think a) vs. b) is a honest tradeoff,
> and not a dumb vs. smart question.

My preference is to alter the value of parameters 
at every given oportunity.

void strcpy(char *s1, const char *s2)
{
    while ((*s1++ = *s2++) != '\0') {
        ;
    }
}

If it turns out that I need the original value
of a parameter throughout the code,
then my preference is to do that by initializing
a const qualified local variable with the original value
of the parameter.

That's very easy to do, 
even as an alteration to code which was originally written
without preserving the parameter value.

char *strcpy(char *s1, const char *s2)
{
    char *const p1 = s1;

    while ((*s1++ = *s2++) != '\0') {
        ;
    }
    return p1;
}

-- 
pete

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

#12438

On 11/01/2011 05:51 AM, Ike Naar wrote:
> On 2011-11-01, James Kuyper <jameskuyper@verizon.net> wrote:
>> On 10/31/2011 08:11 PM, Ike Naar wrote:
...
>> The meaning of 'count' and 'point' do not change anywhere within the
>> following code:
>>
>> 	void zero_array(
>> 	    int *point,
>> 	    int count
>> 	){
>> 	    while(count-- > 0)
>> 	        *point = 0;

Correction:
	        *point++ = 0;
>> 	}
>>
>> At the start of the function, and at the end of each pass through the
>> loop, 'count' contains the number of elements that still need to be
>> zeroed, and if that count is non-zero, then 'point' points at the first
>> of the elements that still need to be zeroed.
> 
> This is not an example where one needs a local variable to maintain
> an unmodified copy of the original.

Well, true - that was precisely my point. As a result:

> In the simpler example that you showed (only one sweep
> across the point array), one can make a tradeoff between two
> desirable objectives:
> a) keeping the parameters constant
> b) minimizing the number of local variables
> 
> I think a) vs. b) is a honest tradeoff, and not a dumb vs. smart question.

I'm in perfect agreement with that.

...
>>> If somebody has a different view, it's not necessarily because they
>>> are "unable" to see things your way.
>>
>> He's not addressing your failure to agree with him, but rather your
>> claim that the alternative approach leads to confusion. He's saying, in
>> essence, that any person who would be confused for that reason still has
>> a lot to learn about programming.
> 
> Phil was talking to Joe; I am not Joe.

Sorry - I sometimes loose track of who's saying what, paying attention
only to the points that they are arguing. Your points seemed similar to
Joe's. Replace "your" with "Joe's" in the preceding paragraph.
-- 
James Kuyper

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

#12440

On 11/01/2011 05:51 AM, Ike Naar wrote:
> On 2011-11-01, James Kuyper <jameskuyper@verizon.net> wrote:
...
>> The meaning of 'count' and 'point' do not change anywhere within the
>> following code:
>>
>> 	void zero_array(
>> 	    int *point,
>> 	    int count
>> 	){
>> 	    while(count-- > 0)
>> 	        *point = 0;
>> 	}
...
> ... And actually the meanings of
> count and point *do* change, initially they describe the entire
> set of points, and later on they describe the set of points
> yet-to-be-processed.

No, those variables always describe the set of points to be processed;
the fact that this is the entire set at the beginning of the routine is
just a special case. It's not necessarily true even then:

	int array[20];
	
	zero_array(array+5, 10);
-- 
James Kuyper

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

#13080

On Nov 1, 3:01 am, James Kuyper <jameskuy...@verizon.net> wrote:
> On 10/31/2011 08:11 PM, Ike Naar wrote:
>
> > On 2011-10-31, Phil Carmody <thefatphil_demun...@yahoo.co.uk> wrote:
> >> Needing to use something more than once, where use modifies that
> >> thing, clearly requires you to maintain an unmodified copy of the
> >> original.
>
> > If a local variable is needed to maintain an unmodified copy of the original,
> > one might as well leave the original parameter unmodified,
> > and use a local variable as the entity-to-be-modified.
> > This is (arguably) cleaner, because the meaning of the parameter
> > does not change during the process.
>
> That depends entirely upon how you interpret the meaning of the
> parameter. Like any variable, if it's value varies, it's meaning must be
> something that can be said to remain unchanged despite the fact that the
> value has changed.
>
> The meaning of 'count' and 'point' do not change anywhere within the
> following code:
>
>         void zero_array(
>             int *point,
>             int count
>         ){
>             while(count-- > 0)
>                 *point = 0;
>         }
>
> At the start of the function, and at the end of each pass through the
> loop, 'count' contains the number of elements that still need to be
> zeroed, and if that count is non-zero, then 'point' points at the first
> of the elements that still need to be zeroed.
>
> >> Needing to use something once, where use modifies that thing, clearly
> >> does not require you to maintain an unmodified copy of the original.
>
> >> If you are unable to see the difference between these cases, then you
> >> will clearly be hampered when it comes to chosing appropriate coding
> >> techniques. That, however, is your problem, and not the language's
> >> problem.
>
> > If somebody has a different view, it's not necessarily because they
> > are "unable" to see things your way.
>
> He's not addressing your failure to agree with him, but rather your
> claim that the alternative approach leads to confusion. He's saying, in
> essence, that any person who would be confused for that reason still has
> a lot to learn about programming.
> --
> James Kuyper

I happen to know Ike and that last sentence had me ROTFL....

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

#12507

Joe writes this code:

    ...
    val = *frp++;
    HAIRY_MACRO(val, qux);
    ...

It works fine and everyone's happy.

Bob comes along and says 'maybe we don't need "val", maybe it is used
only once', and he finds that it is.

He makes this change:

    ...
    HAIRY_MACRO(*frp++, qux);
    ...

The change works fine, so no one notices.

Bob's like 'i'm a genius!'.

...

A year later, Jim is working on a big new project.

He changes:

    #define HAIRY_MACRO(X, Y) \
    (((X) & 0x8000) == 0 ? BIGMAC1(Y) : BIGMAC2(Y))

to:

    #define HAIRY_MACRO(X, Y) \
    (((X) & 0x8000) == 0 ? BIGMAC1(Y) : \
    ((X) & 0x4000) == 0 ? BIGMAC2(Y) : BIGMAC3(Y))

We know the second bit is never set in the old code, so the only
possible problem is a bug in BIGMAC3.

The new code works, mostly...  Worst yet, the old code works, mostly...
There is some glitch that no one can track down.

Jim invites his friends to look over the macros, and related functions,
but they find nothing wrong.

Jim spends a few hours debugging his favorite test program, trying to
pinpoint the problem.  Then he gets it.

Jim's like 'oh!  some a---hole put a postincrement in the macro
argument!  who does that?!'.

[OBTW Bob is no longer with the company]

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

#12508

On 11/ 2/11 04:36 PM, Joe keane wrote:
> Joe writes this code:
>
>      ...
>      val = *frp++;
>      HAIRY_MACRO(val, qux);
>      ...
>
> It works fine and everyone's happy.
>
> Bob comes along and says 'maybe we don't need "val", maybe it is used
> only once', and he finds that it is.
>
> He makes this change:
>
>      ...
>      HAIRY_MACRO(*frp++, qux);
>      ...
>
> The change works fine, so no one notices.
>
> Bob's like 'i'm a genius!'.
>
> ....
>
> A year later, Jim is working on a big new project.
>
> He changes:
>
>      #define HAIRY_MACRO(X, Y) \
>      (((X)&  0x8000) == 0 ? BIGMAC1(Y) : BIGMAC2(Y))
>
> to:
>
>      #define HAIRY_MACRO(X, Y) \
>      (((X)&  0x8000) == 0 ? BIGMAC1(Y) : \
>      ((X)&  0x4000) == 0 ? BIGMAC2(Y) : BIGMAC3(Y))

Reason number 248 for not using function-like macros.

-- 
Ian Collins

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

#12517

Ian Collins <ian-news@hotmail.com> writes:
> On 11/ 2/11 04:36 PM, Joe keane wrote:
[...]
>> A year later, Jim is working on a big new project.
>>
>> He changes:
>>
>>      #define HAIRY_MACRO(X, Y) \
>>      (((X)&  0x8000) == 0 ? BIGMAC1(Y) : BIGMAC2(Y))
>>
>> to:
>>
>>      #define HAIRY_MACRO(X, Y) \
>>      (((X)&  0x8000) == 0 ? BIGMAC1(Y) : \
>>      ((X)&  0x4000) == 0 ? BIGMAC2(Y) : BIGMAC3(Y))
>
> Reason number 248 for not using function-like macros.

Reason number 1 for not using expressions with side effects as
arguments to function-like macros.

I don't suggest that function-like macros are necessarily a good idea,
especially when inline functions are available, but they *can* be used
reasonably safely if you exercise a reasonable amount of care.

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

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

#12412

On Mon, 2011-10-31, Joe keane wrote:
> In article <20111029175230.259@kylheku.com>,
> Kaz Kylheku  <kaz@kylheku.com> wrote:
>>Firstly, you're neglecting to take advantage of parameters being
>>local variables.
>
> I don't like that "feature" of C.
>
> It's harder to debug, it's harder to maintain.

I found your example upthread hard to understand /because/ it didn't
take advantage -- too many (non-const) variables with similar-looking
names.

If you don't intend to modify your parameters, at least make them const.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

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

#12268

In article <j8hrok$3cq$1@reader1.panix.com>, jgk@panix.com (Joe keane) wrote:

> Which is better?

Whichever best expresses your intentions.

-- 
White folks think they're at the top,  |   Faded, patched, secret so tight...
ask any proud white male.              |       I'm whoever you want me to be.
A million years of evolution,          |  Annoying Usenet one post at a time.
and we get Danny Quayle.               |    At least I can stay in character.

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

#12270

jgk@panix.com (Joe keane) writes:

> Which is better?

<snip>

No.

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

#12272

On Sat, 29 Oct 2011, Joe keane wrote:

> Which is better?
>
> ...

int fc(int fool, struct foo *foob)
{
     ...

     for (int i = 0; i < fool; i++)
     {
	...(foob[i])
     }

     ...
}

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

#12367

compare

int fc(int len, struct foo *fob, struct bar *bab)
{
    ...

    for (j = 0; j < len; j++)
    {
	fob[j].a = bab[j].x;
	fob[j].b = bab[j].y + 1;
	fob[j].c = bab[j].d;
    }

    ...
}

versus

int fd(int len, struct foo *fob, struct bar *bab)
{
    ...

    for (j = 0; j < len; j++)
    {
	fop = &fob[j];
	bap = &bab[j];
	fop->a = bap->x;
	fop->b = bap->y + 1;
	fop->c = bap->d;
    }

    ...
}

The first one looks like Pascal or Fortran.  The second one looks more
like C.  It says 'i don't need the array base and index, just give me
the pointer'.

All style, you should get the same machine code.  But i've seen too many
cases where the code that looks 'faster' actually is!  I mean it's nice
to say 'the optimizer will take care of this', but then it doesn't hurt
to help it some, by not making code more complicated than it should be.

Anyway readability is key; to me code like

    ct = len;
    fop = fob;
    while (--ct >= 0)
    {
	...(fop)
	fop++;
    }

is so idiomatic that it's easiest.

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

#12398

On 2011-10-31, Joe keane <jgk@panix.com> wrote:
> Anyway readability is key; to me code like
>
>     ct = len;
>     fop = fob;
>     while (--ct >= 0)
>     {
> 	...(fop)
> 	fop++;
>     }
>
> is so idiomatic that it's easiest.

As pointed out upthread, it's an infinite loop should ct ever happen
to be unsigned. Learning disability?

C programmers who know what they are donig rarely use predecrement like this in
descending loops, because the counter decrements even in the case that the loop
guard fails and the body is not to be executed any more, which means that it
decrements one past zero.

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

#12399

Kaz Kylheku <kaz@kylheku.com> writes:

> On 2011-10-31, Joe keane <jgk@panix.com> wrote:
>> Anyway readability is key; to me code like
>>
>>     ct = len;
>>     fop = fob;
>>     while (--ct >= 0)
>>     {
>> 	...(fop)
>> 	fop++;
>>     }
>>
>> is so idiomatic that it's easiest.
>
> As pointed out upthread, it's an infinite loop should ct ever happen
> to be unsigned. Learning disability?

It seems likely to me that the compiler would warn that the loop
condition cannot ever be true.
-- 
char a[]="\n .CJacehknorstu";int putchar(int);int main(void){unsigned long b[]
={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da6aa6a,0xa67f6aaa,0xaa9aa9f6,0x11f6},*p
=b,i=24;for(;p+=!*p;*p/=4)switch(0[p]&3)case 0:{return 0;for(p--;i--;i--)case+
2:{i++;if(i)break;else default:continue;if(0)case 1:putchar(a[i&15]);break;}}}

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

#12400

On 10/31/2011 03:38 PM, Ben Pfaff wrote:
> Kaz Kylheku <kaz@kylheku.com> writes:
> 
>> On 2011-10-31, Joe keane <jgk@panix.com> wrote:
>>> Anyway readability is key; to me code like
>>>
>>>     ct = len;
>>>     fop = fob;
>>>     while (--ct >= 0)
>>>     {
>>> 	...(fop)
>>> 	fop++;
>>>     }
>>>
>>> is so idiomatic that it's easiest.
>>
>> As pointed out upthread, it's an infinite loop should ct ever happen
>> to be unsigned. Learning disability?
> 
> It seems likely to me that the compiler would warn that the loop
> condition cannot ever be true.

"true" => "false".

A compiler that warns whenever a loop condition can never be false would
annoy those people who rely upon the while(1) idiom.

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

#12402

James Kuyper <jameskuyper@verizon.net> writes:

> On 10/31/2011 03:38 PM, Ben Pfaff wrote:
>> Kaz Kylheku <kaz@kylheku.com> writes:
>> 
>>> On 2011-10-31, Joe keane <jgk@panix.com> wrote:
>>>> Anyway readability is key; to me code like
>>>>
>>>>     ct = len;
>>>>     fop = fob;
>>>>     while (--ct >= 0)
>>>>     {
>>>> 	...(fop)
>>>> 	fop++;
>>>>     }
>>>>
>>>> is so idiomatic that it's easiest.
>>>
>>> As pointed out upthread, it's an infinite loop should ct ever happen
>>> to be unsigned. Learning disability?
>> 
>> It seems likely to me that the compiler would warn that the loop
>> condition cannot ever be true.
>
> "true" => "false".
>
> A compiler that warns whenever a loop condition can never be false would
> annoy those people who rely upon the while(1) idiom.

The compiler is smarter than that (I see that it isn't actually
specific to loop conditionals):

    blp@blp:~/nicira/openflow(0)$ cat foo.c
    int
    main(void)
    {
        unsigned x = 5;
        while (--x >= 0) {
            ;
        }
        while (1) {
            ;
        }
        return 0;
    }
    blp@blp:~/nicira/openflow(0)$ gcc -Wall -Wextra foo.c
    foo.c: In function 'main':
    foo.c:5: warning: comparison of unsigned expression >= 0 is always true
    blp@blp:~/nicira/openflow(0)$ 

-- 
"To get the best out of this book, I strongly recommend that you read it."
--Richard Heathfield

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

#12409

James Kuyper <jameskuyper@verizon.net> writes:
[...]
> A compiler that warns whenever a loop condition can never be false would
> annoy those people who rely upon the while(1) idiom.

Yes, such compilers exist, and yes, they're annoying.

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

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

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

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

csiph-web