On Thu, Jul 31, 2025 at 12:27 PM zxuiji <gb2985_at_[hidden]> wrote:
>
> It's still a pointer so it has pointer arithmetic, that's all that matters which therefore means it's not UB to use pointer arithmetic on nullptr or NULL

The literal text of the standard in [expr.add]/4 clearly and
unequivocally says that pointer arithmetic on a nullptr (except with a
value of 0) is undefined behavior. This is not a matter of opinion.
There is no room for debate or nuance. This is how C++ is defined.

Pointers don't have "pointer arithmetic". Pointers to arrays have
pointer arithmetic. A pointer to a single object can act as a pointer
to an array of size one, but that's it. `nullptr` doesn't point to an
array or a single object. Therefore, it cannot undergo pointer
arithmetic (except with a value of 0).

It does not matter if you can point to implementations such that it
might have some value. It doesn't matter if you think it'd be really
useful. The standard defines what is and is not defined behavior, and
pointer arithmetic on a nullptr with a value other than 0 is UB.

You don't have to like it, but that's the way it is and it is unlikely
to change just because you want to do low-level shenanigans.

> On Thu, 31 Jul 2025 at 17:25, Jason McKesson via Std-Proposals <std-proposals_at_[hidden]> wrote:
>>
>> On Thu, Jul 31, 2025 at 12:20 PM zxuiji <gb2985_at_[hidden]> wrote:
>> >
>> >
>> > In what real world scenario has a pointer to an array not been a pointer capable of pointer arithmetic?
>>
>> Pointers to arrays *are* capable of pointer arithmetic. `nullptr` is
>> not a "pointer to an array". It doesn't point to *anything*; that's
>> kinda the point of it.
>>
>> > On Thu, 31 Jul 2025 at 17:16, Jason McKesson via Std-Proposals <std-proposals_at_[hidden]> wrote:
>> >>
>> >> On Thu, Jul 31, 2025 at 12:12 PM zxuiji <gb2985_at_[hidden]> wrote:
>> >> >
>> >> > how's it UB? it's basic pointer arithmetic, not derefencing a pointer. snprintf could provide the garauntee that within said address range it would be able to optionally prevent a segfault, which is enough for a developer to potentially see the log of caught instances before a hacker could cotton on and exploit it.
>> >>
>> >> [expr.add]/4: https://timsong-cpp.github.io/cppwp/expr.add#4
>> >>
>> >> If the pointer is not a pointer to an array, pointer arithmetic is not
>> >> defined (except in the case of a null pointer, but only if the added
>> >> value is zero). `nullptr` is not a pointer to an array. Thus UB.
>> >>
>> >> > On Thu, 31 Jul 2025 at 17:08, Jason McKesson via Std-Proposals <std-proposals_at_[hidden]> wrote:
>> >> >>
>> >> >> On Thu, Jul 31, 2025 at 12:03 PM zxuiji via Std-Proposals
>> >> >> <std-proposals_at_[hidden]> wrote:
>> >> >> >
>> >> >> > thiago I used NULL there to indicate what would be passed if something like the following occurred:
>> >> >> >
>> >> >> > int leng = 0, index = 0;
>> >> >> > char *text = foo(&leng,&index);
>> >> >> > // oops didn't check foo succeeded:
>> >> >> > snprintf( buff, max, ".*s", leng, text + index );
>> >> >>
>> >> >> That's interesting, but it's still UB the moment `text+index` is
>> >> >> executed. Which happens *before* `snprintf` gets called.
>> >> >>
>> >> >> > On Thu, 31 Jul 2025 at 16:59, Thiago Macieira via Std-Proposals <std-proposals_at_[hidden]> wrote:
>> >> >> >>
>> >> >> >> On Thursday, 31 July 2025 08:56:26 Pacific Daylight Time zxuiji via Std-
>> >> >> >> Proposals wrote:
>> >> >> >> > snprintf( buff, max, "%.*s", length, NULL + index. ) could catch the
>> >> >> >> > invalid pointer (so long as index is small) before a segfault can occur and
>> >> >> >> > if stdlib is not in debug mode then allow the segafault to occur, otherwise
>> >> >> >> > return -1 and set errno to some relevant value
>> >> >> >>
>> >> >> >> Do note that the program is UB before snprintf() was called.
>> >> >> >>
>> >> >> >> Could such a check function ever be used *before* UB happened?
>> >> >> >>
>> >> >> >> --
>> >> >> >> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>> >> >> >> Principal Engineer - Intel Platform & System Engineering
>> >> >> >>
>> >> >> >>
>> >> >> >>
>> >> >> >> --
>> >> >> >> Std-Proposals mailing list
>> >> >> >> Std-Proposals_at_[hidden]
>> >> >> >> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>> >> >> >
>> >> >> > --
>> >> >> > Std-Proposals mailing list
>> >> >> > Std-Proposals_at_[hidden]
>> >> >> > https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>> >> >> --
>> >> >> Std-Proposals mailing list
>> >> >> Std-Proposals_at_[hidden]
>> >> >> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>> >> --
>> >> Std-Proposals mailing list
>> >> Std-Proposals_at_[hidden]
>> >> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals