[PATCH] inttypes.h: imaxabs(3): Implement as a macro

[Alejandro Colomar]

Hi Joseph,

On 9/14/22 00:56, Joseph Myers wrote:
> On Tue, 13 Sep 2022, Alejandro Colomar wrote:
> 
>> I don't understand the process by which gcc expands builtins.  How does
>> exactly the suggested macro interfere with it?  Is it because of the macro?
>> Or because of _Generic()?
> 
> My point is that you already have to go out of your way to get a link-time
> reference to imaxabs - it will almost always have been expanded inline
> instead.  Given that, your patch is adding extra complexity to address an
> issue that doesn't actually exist.

Ahh, now I understand.  So, kind of the situation with bzero(3) which is 
implemented in the compiler, and glibc doesn't support it because the 
compiler always transforms it to memcpy(3).

Then, if there are still any references, glibc still needs to fix that, 
or if there are no references, glibc could just remove the function 
completely.

However, imaxabs(3) was just the starting point, because it happened to 
be the function I chose to use at random.  Other functions using the 
type may not be so commonly inlined.

> 
>> That is a workaround to the type being broken.  The type can't widen, due to
>> ABI issues; for some time, the compiler provided __int128 as a limbo extension
>> that wouldn't be covered by intmax_t, and later ISO C just acknowledged the
>> fact and reworded the definition of intmax_t to be less of "the widest type"
>> and more or "a wide but not really widest type, so don't really trust it very
>> much".
> 
> It is the type used for preprocessor arithmetic, for example.

Yep.  Happens to always coincide with long long though (not in rank, but 
in width), so not much would be lost by using long long.

> 
> intmax_t was discussed at length in WG14, and while there was agreement on
> reducing its uses (hence the change to floating-point return types for
> fromfp functions, for example, see bug 28327), there was not agreement on
> any particular form of obsolescence.  And it *is* useful in practice for
> printing types such as off_t or mode_t with no corresponding printf
> formats; those could just do with appropriate constraints to be no wider
> than intmax_t when a future POSIX revision is based on C2x.

Yes, and yet the same can be said about long long.  intmax_t is one less 
character (both in the type name, and in "j"), but apart from that, no 
much benefit.

Do we really need a typedef for a type that is guaranteed to be as wide 
as any system data type (effectively that is long long)?  It wasn't the 
original intention for intmax_t, AFAIK, and neither is necessary.  I 
considered changing to long long in the man pages to keep it simple.

> 
>> If there's no hope in intmax_t, we should just mark the type as obsolescent,
>> and discard any idea of having a "widest" type at all.
> 
> I don't think it's useful to try to rehash here discussions that were had
> at length in WG14.

Okay.

> 
>> Ahh, you anticipated part 2 of my plan.  Deprecate "j", and add a new set of
>> macros PRIdMAX and the like.  This type has it deserved.  But I know those
>> macros aren't very well received, so it is just part 2.
> 
> The actual direction is to move away from those macros (adding length
> modifiers for printing intN_t / int_leastN_t / int_fastN_t without needing
> to use such macros any more).

While for fixed-width types it makes sense to use fixed strings "w<N>", 
for variable-width types, it doesn't so much.  Otherwise, the types are 
really fixed-width, as far as the ABI is concerned, even if they are not 
explicit-width.  I think having a macro PRIdMAX could make sense.  But 
of course it depends on the meaning of intmax_t.

-- 
<http://www.alejandro-colomar.es/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20220914/e0f10be0/attachment.sig>