Time T: Add N to a uintptr_t

Time T+1: Subtract N from that same uintptr_t

Questions:

1. Is this behavior defined?

2. If it is, then will I be guaranteed to get back the same void * value
I cast to uintptr_t?

Thank you,
--Anthony

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Keith Thompson <[email protected]> writes:

Anthony Cuozzo <[email protected]> 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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 03/02/2024 17:07, Malcolm McLean wrote:

On 03/02/2024 08:44, Tim Rentsch wrote:

Keith Thompson <[email protected]> writes:

Anthony Cuozzo <[email protected]> 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.)

OK, so this is completely topical and there's no issue there. But it's
also fair to say that it's the sort of post which gives the newgroup a
bad reputation.

No, it is the kind of thing that gives this group a /good/ reputation.

People with questions about C behaviour can come here and ask, and get considered answers. In particular, they get answers from people who
look carefully at the standards - not just one or two implementations.
They tell you about uncommon situations that others might not have
considered - including uncommon real implementations, and also possible implementations. For people who want to write code that they /know/
works, and /know/ is correct even if it is used on other platforms, this
kind of information is invaluable.

For people who are happy with "I tried it and it worked on my compiler
on my machine", it is of little interest.

If this newsgroup were filled with nothing but discussions about C
standard minutiae, it would be boring to many people - and yet still a
value resource for people to visit when they need to. But it is not
filled with that - it is an important aspect of the group, but not the
only one.


The validity of pointers as they are converted or arithmetic is applied
is of huge interest, and is a significant area of research in language
design and compiler design. There is a lot of work being done on
"pointer providence" - where pointers come from, and what they can point
to. Knowing what, if anything, they can point to, and whether there
are aliases, is massively relevant to code correctness and optimisation opportunities for compilers.

If you don't care about any of this, that's fine - skip the thread. But
let the people that do care talk about these things.

I'm not going to take a position. But since we've had complaints about
the diection things are going in, other people might like to weigh in on this.

You /have/ taken a position, and you /have/ criticised Tim for his post
- by making this complaint.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

David Brown <[email protected]> writes:

On 03/02/2024 17:07, Malcolm McLean wrote:

On 03/02/2024 08:44, Tim Rentsch wrote:

Keith Thompson <[email protected]> writes:

Anthony Cuozzo <[email protected]> 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.

--
Ben.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 04/02/2024 16:27, Ben Bacarisse wrote:

David Brown <[email protected]> writes:

On 03/02/2024 17:07, Malcolm McLean wrote:

On 03/02/2024 08:44, Tim Rentsch wrote:

Keith Thompson <[email protected]> writes:

Anthony Cuozzo <[email protected]> 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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <[email protected]>,
Keith Thompson <[email protected]> wrote:

Malcolm McLean <[email protected]> writes:
[...]

I know that this is hard for you because you your psychological type.

[...]

Go away.

Very mature.

And about what we expect from your psychological type.

--
The randomly chosen signature file that would have appeared here is more than 4 lines long. As such, it violates one or more Usenet RFCs. In order to remain in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/RightWingMedia

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Keith Thompson <[email protected]> writes:

[... some discussion regarding a posting of mine and alleged
reactions to it ...]

If you have something to say about what was wrong with Tim's post,
you're free to say it. If not, please drop this -- and I suggest
that others not take the bait.

Thank you for this summary. I second your suggestion.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-02-04, Malcolm McLean wrote:

On 04/02/2024 21:31, Keith Thompson wrote:

[snip]

You haven't given your views. You've just falsely claimed that it's
"also fair to say that it's the sort of post which gives the newgroup a
bad reputation".

I think you're trying to start an argument while pretending to be above
the fray. I don't know or care why.

If you have something to say about what was wrong with Tim's post,
you're free to say it. If not, please drop this -- and I suggest that
others not take the bait.

I know that this is hard for you because you your psychological type.
But try to step think back and think what the reaction of a perfectly
normal person might be if, coming to the ng for the first time, that was
the first post he read. Then think what other people have said on
related subjects, and whether or not it is an objective reality,
independent of my opinion, whether or not that has been said.

[snip]

I'm not exactly coming to this ng for the first time, but I've been a
casual occasional reader at best and am coming back to it after a long
while. The original parent thread was the first thread that looked
interesting to me, and I read it and gained some knowledge.

And then I spent 10 minutes of my life I'll never get back, reading this bizarre, passive-aggressive flamebait.

*plonk*

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)