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

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

for-loop mutates to an endless-loop

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

Contents

  for-loop mutates to an endless-loop "Walter H." <Walter.H-Nntp@mathemainzel.info> - 2020-01-03 13:27 +0100
    Re: for-loop mutates to an endless-loop David Brown <david.brown@hesbynett.no> - 2020-01-03 14:01 +0100
    Re: for-loop mutates to an endless-loop Dan Purgert <dan@djph.net> - 2020-01-03 13:18 +0000
      Re: for-loop mutates to an endless-loop James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-03 08:28 -0500
        Re: for-loop mutates to an endless-loop Dan Purgert <dan@djph.net> - 2020-01-03 13:33 +0000
          Re: for-loop mutates to an endless-loop James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-03 21:10 -0500
      Re: for-loop mutates to an endless-loop David Brown <david.brown@hesbynett.no> - 2020-01-03 15:34 +0100
    Re: for-loop mutates to an endless-loop James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-03 08:26 -0500
      Re: for-loop mutates to an endless-loop "Walter H." <Walter.H-Nntp@mathemainzel.info> - 2020-01-04 16:15 +0100
        Re: for-loop mutates to an endless-loop David Brown <david.brown@hesbynett.no> - 2020-01-04 17:17 +0100
        Re: for-loop mutates to an endless-loop Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-04 16:20 +0000
          Re: for-loop mutates to an endless-loop "Walter H." <Walter.H-Nntp@mathemainzel.info> - 2020-01-04 18:43 +0100
            Re: for-loop mutates to an endless-loop David Brown <david.brown@hesbynett.no> - 2020-01-04 19:28 +0100
              Re: for-loop mutates to an endless-loop Bart <bc@freeuk.com> - 2020-01-04 18:59 +0000
                Re: for-loop mutates to an endless-loop David Brown <david.brown@hesbynett.no> - 2020-01-05 14:24 +0100
              Re: for-loop mutates to an endless-loop Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-04 13:47 -0800
                Re: for-loop mutates to an endless-loop David Brown <david.brown@hesbynett.no> - 2020-01-05 14:26 +0100
                Re: for-loop mutates to an endless-loop "Walter H." <Walter.H-Nntp@mathemainzel.info> - 2020-01-06 20:31 +0100
            Re: for-loop mutates to an endless-loop Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-04 22:25 +0000
        Re: for-loop mutates to an endless-loop Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-04 14:08 -0800
        Re: for-loop mutates to an endless-loop James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-04 21:32 -0500
          Re: for-loop mutates to an endless-loop scott@slp53.sl.home (Scott Lurndal) - 2020-01-05 21:48 +0000
        Re: for-loop mutates to an endless-loop James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-04 21:43 -0500
    Re: for-loop mutates to an endless-loop Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-03 14:47 +0100
      Re: for-loop mutates to an endless-loop Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-03 14:39 +0000
        Re: for-loop mutates to an endless-loop Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-03 15:42 +0100
          Re: for-loop mutates to an endless-loop Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-03 15:07 +0000
            Re: for-loop mutates to an endless-loop Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-03 16:18 +0100
              Re: for-loop mutates to an endless-loop Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-03 16:47 +0100
                Re: for-loop mutates to an endless-loop Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-03 20:41 +0000
                  Re: for-loop mutates to an endless-loop Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-04 01:05 +0100
              Re: for-loop mutates to an endless-loop gazelle@shell.xmission.com (Kenny McCormack) - 2020-01-03 18:30 +0000
          Re: for-loop mutates to an endless-loop Robert Wessel <robertwessel2@yahoo.com> - 2020-01-04 00:23 -0600
            Re: for-loop mutates to an endless-loop Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-04 08:10 +0100
              Re: for-loop mutates to an endless-loop scott@slp53.sl.home (Scott Lurndal) - 2020-01-04 16:41 +0000
                Re: for-loop mutates to an endless-loop Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-04 17:44 +0100
            Re: for-loop mutates to an endless-loop Bart <bc@freeuk.com> - 2020-01-04 11:15 +0000
              Re: for-loop mutates to an endless-loop Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-01-04 12:33 +0000
                Re: for-loop mutates to an endless-loop "Walter H." <Walter.H-Nntp@mathemainzel.info> - 2020-01-04 15:59 +0100
                Re: for-loop mutates to an endless-loop Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-04 16:01 +0100
                  Re: for-loop mutates to an endless-loop Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-01-04 16:04 +0000
                    Re: for-loop mutates to an endless-loop Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-04 17:06 +0100
                  Re: for-loop mutates to an endless-loop scott@slp53.sl.home (Scott Lurndal) - 2020-01-04 16:42 +0000
                    Re: for-loop mutates to an endless-loop Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-04 17:44 +0100
              Re: for-loop mutates to an endless-loop Robert Wessel <robertwessel2@yahoo.com> - 2020-01-04 17:55 -0600
                Re: for-loop mutates to an endless-loop "Walter H." <Walter.H-Nntp@mathemainzel.info> - 2020-01-06 20:43 +0100
                  Re: for-loop mutates to an endless-loop scott@slp53.sl.home (Scott Lurndal) - 2020-01-06 19:50 +0000
                    Re: for-loop mutates to an endless-loop Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2020-01-06 15:37 -0500
                      Re: for-loop mutates to an endless-loop scott@slp53.sl.home (Scott Lurndal) - 2020-01-06 21:59 +0000
                    Re: for-loop mutates to an endless-loop Robert Wessel <robertwessel2@yahoo.com> - 2020-01-06 17:33 -0600
        Re: for-loop mutates to an endless-loop gazelle@shell.xmission.com (Kenny McCormack) - 2020-01-03 18:31 +0000
          Re: for-loop mutates to an endless-loop Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-04 01:06 +0100
            Re: for-loop mutates to an endless-loop Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-04 01:38 +0000
              Re: for-loop mutates to an endless-loop Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-04 08:10 +0100
                Re: for-loop mutates to an endless-loop Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-04 16:39 +0000
                  Re: for-loop mutates to an endless-loop Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-04 17:41 +0100
                    Re: for-loop mutates to an endless-loop Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-04 17:49 +0100
                      Re: for-loop mutates to an endless-loop Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-04 22:49 +0000
                        Re: for-loop mutates to an endless-loop Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-05 03:44 +0100
              Re: for-loop mutates to an endless-loop David Brown <david.brown@hesbynett.no> - 2020-01-04 13:09 +0100
    Re: for-loop mutates to an endless-loop Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-03 14:28 +0000
      Re: for-loop mutates to an endless-loop jak <nospam@please.ty> - 2020-01-05 00:40 +0100
      Re: for-loop mutates to an endless-loop "Walter H." <Walter.H-Nntp@mathemainzel.info> - 2020-01-06 20:50 +0100
        Re: for-loop mutates to an endless-loop Manfred <noname@add.invalid> - 2020-01-06 21:28 +0100
      Re: for-loop mutates to an endless-loop Manfred <noname@add.invalid> - 2020-01-06 21:02 +0100
      Re: for-loop mutates to an endless-loop Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-11 10:01 -0800
    Re: for-loop mutates to an endless-loop Richard Damon <Richard@Damon-Family.org> - 2020-01-04 16:21 -0500
      Re: for-loop mutates to an endless-loop Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-01-04 22:17 +0000

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

#148752

On Sat, 2020-01-04, Bonita Montero wrote:
>> It seems to me most of the heat generated in comp.lang.c comes from
>> people who have their own private idea of how C works, and clash with
>> people who have a different idea.  It's such a waste of time.
>
> The "private idea" in this case matches every relevant system today.

In assembly language maybe, but I'm talking about standard C.

/Jorgen

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

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

#148753

>>> It seems to me most of the heat generated in comp.lang.c comes from
>>> people who have their own private idea of how C works, and clash with
>>> people who have a different idea.  It's such a waste of time.

>> The "private idea" in this case matches every relevant system today.

> In assembly language maybe, but I'm talking about standard C.

The systems which don't use 2's complement vanished in the 70s.

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

#148760

Bonita Montero <Bonita.Montero@gmail.com> writes:
>> It seems to me most of the heat generated in comp.lang.c comes from
>> people who have their own private idea of how C works, and clash with
>> people who have a different idea.  It's such a waste of time.
>
>The "private idea" in this case matches every relevant system today.

You stating it repeatedly, doesn't make it a fact.

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

#148763

>>> It seems to me most of the heat generated in comp.lang.c comes from
>>> people who have their own private idea of how C works, and clash with
>>> people who have a different idea.  It's such a waste of time.

>> The "private idea" in this case matches every relevant system today.

> You stating it repeatedly, doesn't make it a fact.

It is a fact, you pettifogging idiot.

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

#148782

On Sat, 4 Jan 2020 11:15:15 +0000, Bart <bc@freeuk.com> wrote:

>On 04/01/2020 06:23, Robert Wessel wrote:
>> On Fri, 3 Jan 2020 15:42:46 +0100, Bonita Montero
>> <Bonita.Montero@gmail.com> wrote:
>> 
>>>>>>        short int nIter;
>>>>>>        long lSum = 0;
>>>>>>        for ( nIter = -32768; nIter <= 32767; nIter++ )
>>>>>>            lSum += nIter;
>>>>>
>>>>> Use this:
>>>>>
>>>>>          short nIter = -32768;
>>>>>          long  lSum  = 0;
>>>>>          do
>>>>>              lSum +== nIter;
>>>>
>>>> s/==/=/
>>>>
>>>>>          while( nIter++ < 32767 );
>>>
>>>> This is not entirely portable (see my other post for why) but will work
>>>> on most implementations.
>>>
>>> This is portable because short is guaranteed to be 16 bit at least
>>> and there's no platform that has something different than twos-com-
>>> plement today.
>> 
>> 
>> You can still order the C89 compiler from Unisys for one of their
>> Clearpath systems (supporting the old Unisys 2200 architecture). While
>> not 16-bit shorts (actually 18 bits), it is ones' complement.
>> 
>> It might not be common, might run on an obscure system, and might not
>> support the latest standards, but it's still a real implementation.
>> 
>
>But should that affect the way that a million programmers write their 
>programs, whose code is never going to run on such a system?


I never said anything like that.  The claim was made that no such
systems exist.  Which is wrong.

Now a bunch of our code does make some of these assumptions (and
generally tries to test for sane configurations, FSVO "sane"), but we
don't claim portability beyond those (hopefully well considered)
bounds.  I quite expect a bunch of that to fail if we ever actually
tried to run on a system where CHAR_BIT is not 8, for example, but if
we did this right, the sanity checks should prevent the compile at all
(and with a pointed message as to the issue).

We're willing to apply those constraints somewhat conditionally.  We
*do* support EBCDIC systems, but not everything is intended to run
there, so code that may have character set dependencies includes a
check for ASCII.

Most of those things could probably be dealt with, some quite easily*,
but don't really seem worth the effort at the moment.

I don't really consider this any different that other environmental
requirements.  A bunch of our code does communications stuff - a
system without a TCP/IP stack (for example), isn't going to support
many of those functions.

In fact, I'd like C and C++ to make it a bit easier to implement
checks of the assumptions made (there has been progress, of course,
but slower than one might have hoped for).


*For example, one of the modules that I know has an ASCII issue is the
core of a VT-320 terminal emulator - for whatever reason, a bunch of
the terminal escape sequences ended up defined in as C character
constants or literals.  Changing a bunch of lines like the following
would be a bit tedious, but trivial.  But there's just no chance this
is ever going to run on zOS.

unsigned char rpt_secondary_da320_7[] = "\x1b[>24;11;0c";

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

#148805

On 05.01.2020 00:55, Robert Wessel wrote:
>
> But there's just no chance this
> is ever going to run on zOS.
>
> unsigned char rpt_secondary_da320_7[] = "\x1b[>24;11;0c";

then this programme would do funny work on non-ASCII systems

[code]
#include <stdio.h>

int dow(int m,int d,int y)
{y-=m<3;return(y+y/4-y/100+y/400+"-bed=pen+mad."[m]+d)%7;}

int main()
{
   int w;
   printf("22. Feb. 2002: %d - 
%s",w,&("Sun\0Mon\0Tue\0Wed\0Thu\0Fri\0Sat\0Sun\0"[4*(w=dow(2,22,2002))]));
   return 0;
}
[/code]

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

#148807

"Walter H." <Walter.H-Nntp@mathemainzel.info> writes:
>On 05.01.2020 00:55, Robert Wessel wrote:
>>
>> But there's just no chance this
>> is ever going to run on zOS.
>>
>> unsigned char rpt_secondary_da320_7[] = "\x1b[>24;11;0c";
>
>then this programme would do funny work on non-ASCII systems

That entirely depends on the non-ASCII system.   Burroughs
mainframes were EBCDIC, but all the terminals were ASCII;
the I/O controller could be programmed to convert between
ebcdic and ascii during the transfer to/from the terminal.

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

#148810

Scott Lurndal wrote:

> "Walter H." <Walter.H-Nntp@mathemainzel.info> writes:
>>On 05.01.2020 00:55, Robert Wessel wrote:
>>>
>>> But there's just no chance this
>>> is ever going to run on zOS.
>>>
>>> unsigned char rpt_secondary_da320_7[] = "\x1b[>24;11;0c";
>>
>>then this programme would do funny work on non-ASCII systems
> 
> That entirely depends on the non-ASCII system.   Burroughs
> mainframes were EBCDIC, but all the terminals were ASCII;
> the I/O controller could be programmed to convert between
> ebcdic and ascii during the transfer to/from the terminal.

That must have been an "imperfect" conversion:
- EBCDIC isn't a single characterset - it is a family of charactersets.
- There are ASCII characters that have no EBCDIC equivalent,
- There are ASCII characters that have equivalents in specific EBCDIC sets,
  and no equivalents in others
- There are ASCII characters that have equivalents in specific EBCDIC sets,
  and /different/ equivalents in other EBCDIC charactersets
- There are EBCDIC characters that have no ASCII equivalent

-- 
Lew Pitcher
30+ years VSE, MVS, zOS application architect, systems programmer and 
application developer, retired

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

#148811

Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
>Scott Lurndal wrote:
>
>> "Walter H." <Walter.H-Nntp@mathemainzel.info> writes:
>>>On 05.01.2020 00:55, Robert Wessel wrote:
>>>>
>>>> But there's just no chance this
>>>> is ever going to run on zOS.
>>>>
>>>> unsigned char rpt_secondary_da320_7[] = "\x1b[>24;11;0c";
>>>
>>>then this programme would do funny work on non-ASCII systems
>> 
>> That entirely depends on the non-ASCII system.   Burroughs
>> mainframes were EBCDIC, but all the terminals were ASCII;
>> the I/O controller could be programmed to convert between
>> ebcdic and ascii during the transfer to/from the terminal.
>
>That must have been an "imperfect" conversion:
>- EBCDIC isn't a single characterset - it is a family of charactersets.

Burroughs had a company standard EBCDIC.  A superset of the IBM EBCDIC
except, IIRC, the [] characters had a different encoding between burroughs
and IBM.  This included several ASCII glyphs that weren't in IBM EBCDIC.

>- There are ASCII characters that have no EBCDIC equivalent,

Burroughs EBCDIC and USASCII both have 256 codepoints when
represented by 8-bit bytes; it was trival to define a corporate-wide
conversion standard from any 8-bit encoded "EBCDIC" value to an 8-bit
encoded "ASCII" value. And vice versa.

All language manuals included in an appendix the table showing the
translations from EBCDIC 8-bit bytes to ASCII 8-bit bytes (technically,
only 7 bits were used, of course, at the time).  The tables also showed
the corresponding BCL and Hollerith encodings.  It was a 7 column table
(EBCDIC 8-bit internal code, EBCDIC Graphic, Hollerith Card Code,
USASCII 8-bit code, BCL 6-bit code, BCL graphic and BCL Hollerith Card Code).
Rows for values 0x00 through 0xff.

The programmer could choose whether to use the built-in transation in
the I/O processor(s) or to setup the ASCII bytes manually and transmit
to the terminal without any intermediate translation by the hardware.

All-in-all it happily satisfied the needs of everyone involved for
three decades.

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

#148812

On Mon, 06 Jan 2020 19:50:49 GMT, scott@slp53.sl.home (Scott Lurndal)
wrote:

>"Walter H." <Walter.H-Nntp@mathemainzel.info> writes:
>>On 05.01.2020 00:55, Robert Wessel wrote:
>>>
>>> But there's just no chance this
>>> is ever going to run on zOS.
>>>
>>> unsigned char rpt_secondary_da320_7[] = "\x1b[>24;11;0c";
>>
>>then this programme would do funny work on non-ASCII systems
>
>That entirely depends on the non-ASCII system.   Burroughs
>mainframes were EBCDIC, but all the terminals were ASCII;
>the I/O controller could be programmed to convert between
>ebcdic and ascii during the transfer to/from the terminal.


You've misunderstood the application.

This is from a terminal *emulator*.  If this code were to run on zOS,
you'd have (say) a TELNET connection going *out* from the (EBCDIC)
machine running this code, to a machine expecting a connection from a
VT320.  That machine (in this case) sends a terminal report
(secondary) command to the emulated terminal.  The terminal emulator
would send the above (binary) string back to the host, which would be
wrong, since it would have been compiled in a mish-mash of ASCII and
EBCDIC.

Yeah it's wrong, but this isn't going to run on zOS anytime soon (or
likely ever).  If that changes, someone will have to spend some time
going through the code redoing all those strings as:

unsigned char rpt_secondary_da320_7[] =
"\x1b\x5b\x3e\x32\x34\x3b\x31\x31\x3b\x30\x63";

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

#148724

In article <874kxcppsp.fsf@bsb.me.uk>,
Ben Bacarisse  <ben.usenet@bsb.me.uk> wrote:
>Bonita Montero <Bonita.Montero@gmail.com> writes:
>
>>>      short int nIter;
>>>      long lSum = 0;
>>>      for ( nIter = -32768; nIter <= 32767; nIter++ )
>>>          lSum += nIter;
>>
>> Use this:
>>
>>        short nIter = -32768;
>>        long  lSum  = 0;
>>        do
>>            lSum +== nIter;
>
>s/==/=/

s/=//


>>        while( nIter++ < 32767 );
>
>This is not entirely portable (see my other post for why) but will work
>on most implementations.

Use the -fwrapv (or whatever it is - I didn't look it up) option in gcc to
be sure.

-- 
A racist, a Nazi, and a Klansman walk into a bar...

Bartender says, "What will it be, Mr. Trump?"

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

#148731

>> s/==/=/

> s/=//

Ok, a typo, but not a portability-issue.

>>>         while( nIter++ < 32767 );

>> This is not entirely portable (see my other post for why) but will work
>> on most implementations.

> Use the -fwrapv (or whatever it is - I didn't look it up) option in gcc to
> be sure.

Not necessary.

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

#148733

Bonita Montero <Bonita.Montero@gmail.com> writes:

>>> s/==/=/
>
>> s/=//
>
> Ok, a typo, but not a portability-issue.
>
>>>>         while( nIter++ < 32767 );
>
>>> This is not entirely portable (see my other post for why) but will work
>>> on most implementations.
>
>> Use the -fwrapv (or whatever it is - I didn't look it up) option in gcc to
>> be sure.

I missed this.  Guaranteeing wrapping on signed integer overflow will
only matter for this code when int is also 16 bits.  There may not even
be a version of gcc with -fwrapv that targets an architecture with
16-bit ints.

> Not necessary.

Not for you, no, but for such a loop to be entirely portable it has to
deal with the two problems I pointed out to the OP.

-- 
Ben.

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

#148737

>> Not necessary.

> Not for you, no, but for such a loop to be entirely portable
> it has to deal with the two problems I pointed out to the OP.

The loop is terminated before the wrap-around.

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

#148757

Bonita Montero <Bonita.Montero@gmail.com> writes:

>>> Not necessary.
>
>> Not for you, no, but for such a loop to be entirely portable
>> it has to deal with the two problems I pointed out to the OP.
>
> The loop is terminated before the wrap-around.

The increment is done on every loop execution.  When int is wider than
short the effect of the last (unnecessary) increment is implementation
defined and hence the code is not 100% portable (for example, an
implementation may choose to raise a signal).  When int is the same
width as short the behaviour of that last increment is undefined (so,
technically, all bets are off).

The code is portable only to systems that meet the hidden assumptions
behind it.  Which is fine, by the way.  There's lots of code like that,
and a good living to be made fixing it when is has to be ported to other
systems that were not even in existence when the original was written.

-- 
Ben.

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

#148759

>> The loop is terminated before the wrap-around.

> The increment is done on every loop execution.  When int is wider than
> short the effect of the last (unnecessary) increment is implementation
> defined and hence the code is not 100% portable (for example, an
> implementation may choose to raise a signal).

No, because the increment is _post_-increment and doesn't
affect the evaluation of the value before.
You're among the most stupid pettifoggers in this group.

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

#148764

>> The increment is done on every loop execution.  When int is wider than
>> short the effect of the last (unnecessary) increment is implementation
>> defined and hence the code is not 100% portable (for example, an
>> implementation may choose to raise a signal).

> No, because the increment is _post_-increment and doesn't
> affect the evaluation of the value before.

C99-standard:
"The result of the postfix ++ operator is the value of the operand."

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

#148777

Bonita Montero <Bonita.Montero@gmail.com> writes:

>>> The increment is done on every loop execution.  When int is wider than
>>> short the effect of the last (unnecessary) increment is implementation
>>> defined and hence the code is not 100% portable (for example, an
>>> implementation may choose to raise a signal).
>
>> No, because the increment is _post_-increment and doesn't
>> affect the evaluation of the value before.
>
> C99-standard:
> "The result of the postfix ++ operator is the value of the operand."

The value of increment expression is not the issue.  One way forward
would be for you to ask for more explanation.  For example, you could
ask "why is the behaviour implementation defined (or undefined) even
though only the prior value is used by the loop condition?".

Another way forward would be to keep reading the C standard to find out
what else it says about postfix ++.  You would then, eventually, come
across the test that says that a signal might be raised in some cases
and also the text that says the whole program is undefined in others.

-- 
Ben.

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

#148785

>>>> The increment is done on every loop execution.  When int is wider than
>>>> short the effect of the last (unnecessary) increment is implementation
>>>> defined and hence the code is not 100% portable (for example, an
>>>> implementation may choose to raise a signal).

>>> No, because the increment is _post_-increment and doesn't
>>> affect the evaluation of the value before.

>> C99-standard:
>> "The result of the postfix ++ operator is the value of the operand."

> The value of increment expression is not the issue.  One way forward
> would be for you to ask for more explanation.  For example, you could
> ask "why is the behaviour implementation defined (or undefined) even
> though only the prior value is used by the loop condition?".

There's nothing implementation defined here.

> Another way forward would be to keep reading the C standard to find out
> what else it says about postfix ++.  You would then, eventually, come
> across the test that says that a signal might be raised in some cases
> and also the text that says the whole program is undefined in others.

You're telling stupid things.

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

#148745

On 04/01/2020 02:38, Ben Bacarisse wrote:
> Bonita Montero <Bonita.Montero@gmail.com> writes:
> 
>>>> s/==/=/
>>
>>> s/=//
>>
>> Ok, a typo, but not a portability-issue.
>>
>>>>>          while( nIter++ < 32767 );
>>
>>>> This is not entirely portable (see my other post for why) but will work
>>>> on most implementations.
>>
>>> Use the -fwrapv (or whatever it is - I didn't look it up) option in gcc to
>>> be sure.
> 
> I missed this.  Guaranteeing wrapping on signed integer overflow will
> only matter for this code when int is also 16 bits.  There may not even
> be a version of gcc with -fwrapv that targets an architecture with
> 16-bit ints.
> 

gcc supports several 16-bit devices (like the msp430 mentioned in 
another thread, though the OP does not say if he uses gcc), and at least 
one 8-bit device (the AVR) which also has 16-bit int.  These all support 
-fwrapv.

(This doesn't affect the validity of your point, I just thought you 
might like to know.)

>> Not necessary.
> 
> Not for you, no, but for such a loop to be entirely portable it has to
> deal with the two problems I pointed out to the OP.
> 

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

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

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

csiph-web