From: "Alejandro (Alex) Colomar" <alx.manpages@gmail.com>
To: JeanHeyd Meneide <wg14@soasis.org>,
Joseph Myers <joseph@codesourcery.com>
Cc: Florian Weimer <fweimer@redhat.com>, libc-alpha@sourceware.org
Subject: Re: [PATCH] inttypes.h: imaxabs(3): Implement as a macro
Date: Thu, 15 Sep 2022 14:33:38 +0200 [thread overview]
Message-ID: <4a52fe57-ca86-d5ae-6125-b44c62565ede@gmail.com> (raw)
In-Reply-To: <CACqA6+nOefuPfq=X5gM9mXh6p8+pacODWov+mnmVM2SdjWufOA@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 6205 bytes --]
Dear JeanHeyd, Joseph,
On 9/14/22 21:03, JeanHeyd Meneide wrote:
> Dear Alejandro, Joseph,
>
> On Wed, Sep 14, 2022 at 12:41 PM Joseph Myers <joseph@codesourcery.com> wrote:
>>
>> On Wed, 14 Sep 2022, Alejandro Colomar via Libc-alpha wrote:
>>
>>>> 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.
>>
>> It provides a clearer statement of intent to readers of the code than long
>> long does.
>>
>> As I noted in the WG14 discussions of a few proposed obsoletions, just
>> because some language feature is not useful for *all* the things some
>> people might like to be able to use it for isn't a reason for obsoletion
>> when it's still useful for *some* of those things.
Hmm, I guess that makes sense.
>
>
> I agree here. I have a proposal to fix this, based on the
> assembly labels and similar existing practice found on a lot of
> compilers, and based on what BSDs such as NetBSD have been using for
> 25+ years to provide ABI stability despite shifting architectures and
> types: https://thephd.dev/_vendor/future_cxx/papers/C%20-%20Transparent%20Aliases.html
It was a good read! Let me share some thoughts on it.
>
> I would rather we not fall back to macros for all the reasons
> Joseph and others mentioned (the standard library #undef macro reason
> is also listed in the above-linked paper). I personally view the
> exemptions we made for the upcoming C2x (C23) standard as stop-gaps to
> allow important evolution and implementation work from, but not
> general-purpose solutions. I think transparent aliases is a generic
> solution to the problem and would achieve much of what we need to do,
> but it will not be in until C2y/C3a (the next revision of the C
> standard) if I work hard at it and polish the wording while surfacing
> implementations. I also found a few embedded folks who similarly
> suffered drawbacks because their platform's compiler could not deal
> with the asm("") labels for ABIs, and broke the entire build on their
> machine. So even for non-large systems, there's a real need for a
> language-level indirection mechanism that has all the same properties
> as normal functions.
I think macros can be used for this same purpose (but don't cry so fast;
please continue reading ;). They effectively achieve the aliasing
objective, with an already existing feature.
The objection seems to be 7.1.4. As your N2970 paper says, 7.1.4 is
there to make sure that users can "remove" the aliasing that macros may
be doing, so that they make sure they call the exact function they are
trying to call by using #undef. That's not really true, since compilers
don't care how much you #undef things, but they'll use builtins whether
you like it or not, unless you work hard enough on your compiler flags
and maybe even asm() statements to work around that. But let's ignore
compiler builtins. The objective of 7.1.4 was that users can avoid
macros and make sure they call a function called foo() if they want.
Keeping 7.1.4, but then adding _Alias is a bit of lying. _Alias, like a
macro, will make user code call a function different from what they
think: in neither case will the generated assembly code have traces of
foo(), if it was defined or _Aliased to something else; and you cannot
#undef an _Alias, so 7.1.4 becomes a bit irrelevant.
Nevertheless, and even if macros can achieve what _Alias does in the
same way, given that the 7.1.4 restrictions were lifted, either for all
functions, or for specific ones, I do like _Alias. In the end, macros
can achieve what typedef does, and we still have it, and I like it. It
provides a bit more safety, by being a C feature, and not a cpp(1) one;
we get more warnings and more restrictions, which are nice.
In general I like the paper very much. I'd say that the part of the
rationale that talks about 7.1.4 is a bit of a lie in the sense that I
stated above, but that's not a big issue to me. The feature makes
sense, and seems an improvement over the GNU attribute. The GNU C issue
could be overcome through macros (again), so it wasn't as painful to
use, but still those macros make clear the the interface was less than
ideal. See what I used:
#define ALX_ALIAS_DECLARATION(aka, original) \
[[gnu::copy(original)]] extern typeof(original) aka
#define ALX_ALIAS_DEFINITION(aka, original) \
[[gnu::alias(#original)]] ALX_ALIAS_DECLARATION(aka, original)
#define ALX_ALIAS_WEAK_DEF(aka, original) \
[[gnu::weak]] ALX_ALIAS_DEFINITION(aka, original)
So, yeah, your paper makes a lot of sense to standardize this. About
the naming, if I may give my opinion, _Alias (and the alias macro) seem
quite nice. 'using' would also be nice if the feature is a strict
subset of the C++ one, so that programmers know they are the same exact
feature, just that C++ obviously can apply it to more contexts.
>
> I hope that we can still make do with implementation extensions
> while I (and others?) work to make proper strides in implementation.
> And I apologize it took me this long to come up with these things; I
> certainly do wish I was "faster on the draw" to solving these
> problems, so to speak.
Time gives the opportunity to think it very well, so I don't see it as
bad. Just knowing that it is in the process of being fixed makes me
happy enough. :-)
Cheers,
Alex
>
> Best Wishes,
> JeanHeyd
--
<http://www.alejandro-colomar.es/>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
prev parent reply other threads:[~2022-09-15 12:33 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-13 15:18 Alex Colomar
2022-09-13 15:28 ` Alejandro Colomar
2022-09-13 15:34 ` Alejandro Colomar
2022-09-13 18:27 ` Joseph Myers
2022-09-13 18:47 ` Paul Eggert
2022-09-13 19:30 ` Joseph Myers
2022-09-13 20:59 ` Paul Eggert
2022-09-13 22:43 ` Alejandro Colomar
2022-09-13 22:56 ` Joseph Myers
2022-09-13 23:43 ` Alejandro Colomar
2022-09-14 16:41 ` Joseph Myers
2022-09-14 19:03 ` JeanHeyd Meneide
2022-09-15 12:33 ` Alejandro (Alex) Colomar [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4a52fe57-ca86-d5ae-6125-b44c62565ede@gmail.com \
--to=alx.manpages@gmail.com \
--cc=fweimer@redhat.com \
--cc=joseph@codesourcery.com \
--cc=libc-alpha@sourceware.org \
--cc=wg14@soasis.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).