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

for-loop mutates to an endless-loop

Started by	"Walter H." <Walter.H-Nntp@mathemainzel.info>
First post	2020-01-03 13:27 +0100
Last post	2020-01-04 22:17 +0000
Articles	20 on this page of 68 — 17 participants

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

  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 2 of 4 — ← Prev page 1 [2] 3 4 Next page →

#148783

From	James Kuyper <jameskuyper@alumni.caltech.edu>
Date	2020-01-04 21:32 -0500
Message-ID	<qurhro$gtd$1@dont-email.me>
In reply to	#148750

On 1/4/20 10:15 AM, Walter H. wrote:
> On 03.01.2020 14:26, James Kuyper wrote:
>> On 1/3/20 7:27 AM, Walter H. wrote:
>> ...
>>> long int i32Iter;
>>
>> That name implies that you expect long int to be a 32-bit type.
> 
>  > On many systems it is, on other systems it is not.
> 
> have you an example of a system where it is not?
> (I have never heard of this)

I've frequently used Linux 64-bit systems where long was a 64-bit type.

>> If it's important to you that
>> it be an exactly 32-bit int, use int32_t.
> 
> mostly there are other types either #define or typedef's like
> DWORD, BYTE, WORD, ...

Those are Microsoft-specific; you should not count on them being
available on other systems. The mandatory <stdint.h> types must be
available on any implementation of C that conforms to C99 or later.

>> The problem with the code below comes precisely from the fact that long
>> int apparently is a 32-bit type. In order to write code this way, you
>> need a type bigger than 32 bits:
> 
> this must be a mistake; the loop must go through the whole range of the 
> integral type;

It does. And when it reaches i32Iter==2147483647, the loop condition
continues to be true, so the loop body executes, and then so does
i32Iter++. That is equivalent to i32Iter = i32Iter + 1. The result of
i32Iter + 1 should be 2147483648, but that value is not representable in
a 32-bit type.

"If an exceptional condition occurs during the evaluation of an
expression (that is, if the result is not mathematically defined or not
in the range of representable values for its type), the behavior is
undefined." (6.5p5).

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

#148795

From	scott@slp53.sl.home (Scott Lurndal)
Date	2020-01-05 21:48 +0000
Message-ID	<YQsQF.36452$iQ2.16024@fx16.iad>
In reply to	#148783

James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>On 1/4/20 10:15 AM, Walter H. wrote:
>> On 03.01.2020 14:26, James Kuyper wrote:
>>> On 1/3/20 7:27 AM, Walter H. wrote:
>>> ...
>>>> long int i32Iter;
>>>
>>> That name implies that you expect long int to be a 32-bit type.
>> 
>>  > On many systems it is, on other systems it is not.
>> 
>> have you an example of a system where it is not?
>> (I have never heard of this)
>
>I've frequently used Linux 64-bit systems where long was a 64-bit type.

This was also the case for IRIX, SVr4, HP-UX, Digital Unix and other
64-bit unicies.

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

#148784

From	James Kuyper <jameskuyper@alumni.caltech.edu>
Date	2020-01-04 21:43 -0500
Message-ID	<qurig8$gtd$3@dont-email.me>
In reply to	#148750

On 1/4/20 9:32 PM, James Kuyper wrote:
...
> i32Iter + 1 should be 2147483648, but that value is not representable in
> a 32-bit type.
That should have been "32-bit signed integer type". It's entirely
representable in 32-bit unsigned integer and floating point types.

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

#148708

From	Bonita Montero <Bonita.Montero@gmail.com>
Date	2020-01-03 14:47 +0100
Message-ID	<qunglm$1f8$1@news.albasani.net>
In reply to	#148702

>      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;
        while( nIter++ < 32767 );

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

#148712

From	Ben Bacarisse <ben.usenet@bsb.me.uk>
Date	2020-01-03 14:39 +0000
Message-ID	<874kxcppsp.fsf@bsb.me.uk>
In reply to	#148708

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/==/=/

>        while( nIter++ < 32767 );

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

-- 
Ben.

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

#148713

From	Bonita Montero <Bonita.Montero@gmail.com>
Date	2020-01-03 15:42 +0100
Message-ID	<qunjt6$o6m$1@news.albasani.net>
In reply to	#148712

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

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

#148714

From	Ben Bacarisse <ben.usenet@bsb.me.uk>
Date	2020-01-03 15:07 +0000
Message-ID	<87y2uoo9wx.fsf@bsb.me.uk>
In reply to	#148713

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/==/=/
>>
>>>         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.

It is not portable for reasons that have nothing to do with what you
have said here.  See my other post if you want to know why.

-- 
Ben.

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

#148715

From	Bonita Montero <Bonita.Montero@gmail.com>
Date	2020-01-03 16:18 +0100
Message-ID	<qunm0n$kls$1@news.albasani.net>
In reply to	#148714

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

> It is not portable for reasons that have nothing to do with what
> you have said here. See my other post if you want to know why.

You're telling nonsense.

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

#148716

From	Bonita Montero <Bonita.Montero@gmail.com>
Date	2020-01-03 16:47 +0100
Message-ID	<qunnn0$gda$1@news.albasani.net>
In reply to	#148715

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

>> It is not portable for reasons that have nothing to do with what
>> you have said here. See my other post if you want to know why.

> You're telling nonsense.

Or more precisely: long is at least 32 bits.
So all the summed up values fit in it.

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

#148728

From	Ben Bacarisse <ben.usenet@bsb.me.uk>
Date	2020-01-03 20:41 +0000
Message-ID	<87sgkwnuhn.fsf@bsb.me.uk>
In reply to	#148716

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

>>>> 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.
>
>>> It is not portable for reasons that have nothing to do with what
>>> you have said here. See my other post if you want to know why.
>
>> You're telling nonsense.
>
> Or more precisely: long is at least 32 bits.
> So all the summed up values fit in it.

The code you posted is not portable for reasons that you have not
addressed.  No number of unrelated true statements will alter that
fact.

-- 
Ben.

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

#148730

From	Bonita Montero <Bonita.Montero@gmail.com>
Date	2020-01-04 01:05 +0100
Message-ID	<quoks0$9tv$2@news.albasani.net>
In reply to	#148728

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

>>>> It is not portable for reasons that have nothing to do with what
>>>> you have said here. See my other post if you want to know why.

>>> You're telling nonsense.

>> Or more precisely: long is at least 32 bits.
>> So all the summed up values fit in it.

> The code you posted is not portable for reasons that you have not
> addressed.  No number of unrelated true statements will alter that
> fact.

No, it is portable.

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

#148723

From	gazelle@shell.xmission.com (Kenny McCormack)
Date	2020-01-03 18:30 +0000
Message-ID	<quo178$ovd$1@news.xmission.com>
In reply to	#148715

In article <qunm0n$kls$1@news.albasani.net>,
Bonita Montero  <Bonita.Montero@gmail.com> wrote:
>>> 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.
>
>> It is not portable for reasons that have nothing to do with what
>> you have said here. See my other post if you want to know why.
>
>You're telling nonsense.
>

Could you two just go get a room somewhere - and have it out like the manly
men you obviously are?

-- 
The only thing Trump's made great again is Saturday Night Live.

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

#148736

From	Robert Wessel <robertwessel2@yahoo.com>
Date	2020-01-04 00:23 -0600
Message-ID	<ckb01ftf1aggpqtq21cuiejl9j796tucug@4ax.com>
In reply to	#148713

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.

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

#148738

From	Bonita Montero <Bonita.Montero@gmail.com>
Date	2020-01-04 08:10 +0100
Message-ID	<qupdpo$v46$2@news.albasani.net>
In reply to	#148736

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

... and compile the code in a museum.

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

#148758

From	scott@slp53.sl.home (Scott Lurndal)
Date	2020-01-04 16:41 +0000
Message-ID	<Be3QF.237135$MD2.205016@fx48.iad>
In reply to	#148738

Bonita Montero <Bonita.Montero@gmail.com> writes:
>>> 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.
>
>... and compile the code in a museum.

You are, as usual, incorrect.   There are several hundred of those
systems still running (many for the airlines) and if you have the
bread, a brand new one can be purchased today.

https://www.unisys.com/offerings/clearpath-forward/clearpath-forward-products/clearpath-forward-dorado-systems

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

#148761

From	Bonita Montero <Bonita.Montero@gmail.com>
Date	2020-01-04 17:44 +0100
Message-ID	<quqfd6$lb1$2@news.albasani.net>
In reply to	#148758

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

>> ... and compile the code in a museum.

> You are, as usual, incorrect.   There are several hundred of those
> systems still running (many for the airlines) and if you have the
> bread, a brand new one can be purchased today.
> https://www.unisys.com/offerings/clearpath-forward/clearpath-forward-products/clearpath-forward-dorado-systems

This isn't link a proof that "there are several hundred of those systems
still running".

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

#148743

From	Bart <bc@freeuk.com>
Date	2020-01-04 11:15 +0000
Message-ID	<jt_PF.794880$O9t.556319@fx36.am4>
In reply to	#148736

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?

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

#148746

From	Jorgen Grahn <grahn+nntp@snipabacken.se>
Date	2020-01-04 12:33 +0000
Message-ID	<slrnr111ha.9in.grahn+nntp@frailea.sa.invalid>
In reply to	#148743

On Sat, 2020-01-04, Bart 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:
...
>>> 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?

Yes, because it's worth a lot to have a common language, standard C.

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.

  (I have my own non-standard model of C too, but at least that one is
  limited by another standard, POSIX.)

And what's the value of assuming two's complement, anyway?

/Jorgen

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

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

#148748

From	"Walter H." <Walter.H-Nntp@mathemainzel.info>
Date	2020-01-04 15:59 +0100
Message-ID	<h7bniiFmb28U1@mid.individual.net>
In reply to	#148746

On 04.01.2020 13:33, Jorgen Grahn wrote:

>
> And what's the value of assuming two's complement, anyway?

this assumes that there is not any range check validation either ...

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

#148749

From	Bonita Montero <Bonita.Montero@gmail.com>
Date	2020-01-04 16:01 +0100
Message-ID	<quq9cs$qha$1@news.albasani.net>
In reply to	#148746

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

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

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

csiph-web

for-loop mutates to an endless-loop

Contents

#148783

#148795

#148784

#148708

#148712

#148713

#148714

#148715

#148716

#148728

#148730

#148723

#148736

#148738

#148758

#148761

#148743

#148746

#148748

#148749