On Thu, Mar 30, 2023, 12:36 Alejandro Colomar <alx.mailinglists@gmail.com> wrote:


On Thu, Mar 30, 2023, 12:27 Marcin Jaczewski via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
czw., 30 mar 2023 o 11:26 Alejandro Colomar via Std-Proposals
<std-proposals@lists.isocpp.org> napisał(a):
>
>
>
> On 3/30/23 10:58, David Brown via Std-Proposals wrote:
> > On 29/03/2023 17:18, Arthur O'Dwyer via Std-Proposals wrote:
> >
> >> A new `uintmax_extended_t` (or whatever) can communicate properly from
> >> the get-go: "Hey! This type will change in the future! Don't build it
> >> into your APIs!"
> >> But then, if you aren't using this type in APIs, then where /*are*/ you
> >> using it, and why does it need to exist in the standard library at all?
> >>
> > That, I think, is the key point - /why/ would you want a "maximum size
> > integer type" ?
>
> For example to printf(3) an off_t variable.
> Or to write a [[gnu::always_inline]] function that accepts any integer.
> Or to write a type-generic macro that handles any integer.
>
> The addition of functions that handle [u]intmax_t was the design mistake.
> If they had been added as macros, we wouldn't be discussing ABI issues,
> because macros don't have ABI.  Of course, the problem is that _Generic(3)
> was only added in C11, but intmax_t was added in C99, so they had to do it
> as functions.  History sucks.
>

No, this would change nothing, if it was macro, you still could put it
on some API and then worry about ABI break.
Usage of this causes risk of ABI break, not how it was defined.

I already mentioned this on this thread (but maybe I sent the mail from an incorrect account and didn't reach the list): In the Linux man-pages page for _Generic(3), I wrote a proof of concept of how to implement imaxabs(3) and similar calls as macros, so that no traces of 
intmax_t are left in any ABI:


BTW, I just learned that PRIdMAX exists.  In that page, I used %jd to print a intmax_t, which causes ABI issues.  Since that example program is to avoid ABI issues, I'll change it to use the macro.  :)


The actual calls will be made to functions of fundamental types.

That would require modifying the standard to allow these calls to be implemented as macros only, with no real function of that name, but I think that shouldn't be a big deal.  Implementations could keep a compat symbol for previous programs that called the function.