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

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

Is this defined behavior?

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

Contents

  Is this defined behavior? Anthony Cuozzo <anthony@cuozzo.us> - 2024-02-02 10:56 -0500
    Re: Is this defined behavior? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-02 08:28 -0800
      Re: Is this defined behavior? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-03 00:44 -0800
        Re: Is this defined behavior? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-03 16:07 +0000
          Re: Is this defined behavior? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-03 13:41 -0800
            Re: Is this defined behavior? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-04 03:18 +0000
              Re: Is this defined behavior? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-03 19:48 -0800
                Re: Is this defined behavior? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-04 04:34 +0000
          Re: Is this defined behavior? David Brown <david.brown@hesbynett.no> - 2024-02-04 13:24 +0100
            Re: Is this defined behavior? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-04 15:16 +0000
              Re: Is this defined behavior? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-04 13:31 -0800
                Re: Is this defined behavior? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-04 23:18 +0000
                  Re: Is this defined behavior? Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-04 15:56 -0800
                    Re: Is this defined behavior? gazelle@shell.xmission.com (Kenny McCormack) - 2024-02-05 00:05 +0000
                  Re: Is this defined behavior? Poprocks <please@replytogroup.com> - 2024-02-05 13:35 -0500
                    Re: Is this defined behavior? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-06 13:10 +0000
                    Is this sane behavior? (Was: Is this defined behavior?) gazelle@shell.xmission.com (Kenny McCormack) - 2024-02-06 14:52 +0000
                      Re: Is this sane behavior? (Was: Is this defined behavior?) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-06 15:50 +0000
                Re: Is this defined behavior? Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-04 23:21 -0800
            Re: Is this defined behavior? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-04 15:27 +0000
              Re: Is this defined behavior? David Brown <david.brown@hesbynett.no> - 2024-02-04 18:23 +0100

Page 2 of 2 — ← Prev page 1 [2]

#381750

On 04/02/2024 16:27, Ben Bacarisse wrote:
> David Brown <david.brown@hesbynett.no> writes:
> 
>> On 03/02/2024 17:07, Malcolm McLean wrote:
>>> On 03/02/2024 08:44, Tim Rentsch wrote:
>>>> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>>>>
>>>>> Anthony Cuozzo <anthony@cuozzo.us> writes:
>>>>>
>>>>>> Time T:  Add N to a uintptr_t
>>>>>>
>>>>>> Time T+1:  Subtract N from that same uintptr_t
>>>>>>
>>>>>> Questions:
>>>>>>
>>>>>> 1.  Is this behavior defined?
>>>>>
>>>>> Sure, why wouldn't it be?  uintptr_t is just an unsigned integer
>>>>> type.  The guarantees about converting to and from void* don't
>>>>> affect its arithmetic behavior.  Adding and then subtracting N
>>>>> yields the original value.
>>>>
>>>> Extremely likely to hold.  A perverse implementation could choose
>>>> (IIANM) a uintptr_t whose integer conversion rank is less than
>>>> that of int, and that could mess things up.  In practical terms
>>>> though what you say is spot on.
>>
>> An 8-bit implementation with very limited RAM might use 8-bit pointers, at
>> least for "normal" pointers.  (Typically such systems also support
>> extensions such as "far" pointers, or "code memory" pointers.)  I haven't
>> seen such an implementation, but it is certainly conceivable. ("int" would
>> be 16-bit.)
> 
> I think you are suggesting that uintptr_t might, on such a system, be
> only 8 bits wide, but that's no permitted.  UINTPTR_MAX can be no less
> than 2**16 - 1.  Of course that alone does not prevent its rank being
> less that that of int, but the system you describe would not be an
> example.
> 

Good point.  (Of course, many 8-bit implementations have deviations from 
the standards, at least as options - some allow 8-bit "int", for 
example.  But then we are no longer talking about standard C.)

I have also used a system where the total memory space fit within a 16 
bit address range, while the cpu can handle 32-bit data and arithmetic 
directly.  IIRC, it had a 16-bit "int", but such a system could 
reasonably have had 16-bit uintptr_t and 32-bit int.  But again, that's 
still hypothetical - just not unimaginable.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web