But that (just being able to do pointer arithmetic) is not the logic of the current standard. One would have to change that logic first or at the same time. And reason, why it is done as it is done now. And what ramifications changing it would have.   The trend in C++ goes to more safety. Sometimes more safety lies in more direct control of the hardware Sometimes more safety lies in being more abstract.   On the topic of pointers, I personally expect the trend to go more into the abstract direction to catch more memory bugs. That means, just doing pointer arithmetic will work less and less.     -----Ursprüngliche Nachricht----- Von:zxuiji via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Do 31.07.2025 18:27 Betreff:Re: [std-proposals] Standardising 0xdeadbeef for pointers An:std-proposals_at_[hidden]; CC:zxuiji <gb2985_at_[hidden]>; 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 On Thu, 31 Jul 2025 at 17:25, Jason McKesson via Std-Proposals <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> > wrote: On Thu, Jul 31, 2025 at 12:20 PM zxuiji <gb2985_at_[hidden] <mailto: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] <mailto:std-proposals_at_[hidden]> > wrote: >> >> On Thu, Jul 31, 2025 at 12:12 PM zxuiji <gb2985_at_[hidden] <mailto: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] <mailto:std-proposals_at_[hidden]> > wrote: >> >> >> >> On Thu, Jul 31, 2025 at 12:03 PM zxuiji via Std-Proposals >> >> <std-proposals_at_[hidden] <mailto: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] <mailto: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 <http://macieira.info> - thiago (AT) kde.org <http://kde.org> >> >> >>   Principal Engineer - Intel Platform & System Engineering >> >> >> >> >> >> >> >> >> >> >> >> -- >> >> >> Std-Proposals mailing list >> >> >> Std-Proposals_at_[hidden] <mailto:Std-Proposals_at_[hidden]> >> >> >> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals >> >> > >> >> > -- >> >> > Std-Proposals mailing list >> >> > Std-Proposals_at_[hidden] <mailto:Std-Proposals_at_[hidden]> >> >> > https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals >> >> -- >> >> Std-Proposals mailing list >> >> Std-Proposals_at_[hidden] <mailto:Std-Proposals_at_[hidden]> >> >> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals >> -- >> Std-Proposals mailing list >> Std-Proposals_at_[hidden] <mailto:Std-Proposals_at_[hidden]> >> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals -- Std-Proposals mailing list Std-Proposals_at_[hidden] <mailto: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