Date: Sun, 19 Apr 2026 22:41:25 -0700
On Sunday, 19 April 2026 19:30:46 Pacific Daylight Time Zhao YunShan wrote:
> You always trouble proposers with subjective questions like "Is this
> proposal worthy?" I'm curious, since you aren't even a committee member,
> why are you so confident that my proposal is unworthy and will never be
> written as a formal proposal?
I did not say your proposal is unworthy. You asked if I thought it should be
part of the Standard and not justify my answer, to which I honestly answered I
thought it shouldn't.
That doesn't mean the *proposal* is unworthy. I just happen to think there are
technical reasons why it will not be made part of the Standard, but you asked
that I not explain myself, so I didn't. You can also see in the reply to
Frederick that I think your proposal *has* a chance of being accepted, however
low that might be, whereas his has practically none. Both *techniques* have
value and I have used them, but I don't think they need to be part of the
Standard to be valuable and used.
You are now asking why I am answering to your proposal in particular: it's
because intercepting functions is an area I have a lot of expertise in. In
fact, I have been trying for years to make function/symbol resolving on ELF
systems more efficient, by making them not look the symbol by name but directly
resolve via relative addressing. And I have had some success getting changes
implemented in compilers and linkers towards that goal. Those changes make
intercepting functions even more difficult, because you could only intercept
calls made from one library to another. To solve that, I'd like to see an
attribute marking the function as interceptable, which would also make the
compiler never inline or clone them. No other function should be intercepted.
So the reason I am replying to you is that I think you would benefit from my
expertise. Even when I don't think the proposal will make it through
acceptance in the Standard, I would like to see a *well-written* and thought
out proposal. As I said before, the only worse thing is to have a defective
proposal accepted.
> You always trouble proposers with subjective questions like "Is this
> proposal worthy?" I'm curious, since you aren't even a committee member,
> why are you so confident that my proposal is unworthy and will never be
> written as a formal proposal?
I did not say your proposal is unworthy. You asked if I thought it should be
part of the Standard and not justify my answer, to which I honestly answered I
thought it shouldn't.
That doesn't mean the *proposal* is unworthy. I just happen to think there are
technical reasons why it will not be made part of the Standard, but you asked
that I not explain myself, so I didn't. You can also see in the reply to
Frederick that I think your proposal *has* a chance of being accepted, however
low that might be, whereas his has practically none. Both *techniques* have
value and I have used them, but I don't think they need to be part of the
Standard to be valuable and used.
You are now asking why I am answering to your proposal in particular: it's
because intercepting functions is an area I have a lot of expertise in. In
fact, I have been trying for years to make function/symbol resolving on ELF
systems more efficient, by making them not look the symbol by name but directly
resolve via relative addressing. And I have had some success getting changes
implemented in compilers and linkers towards that goal. Those changes make
intercepting functions even more difficult, because you could only intercept
calls made from one library to another. To solve that, I'd like to see an
attribute marking the function as interceptable, which would also make the
compiler never inline or clone them. No other function should be intercepted.
So the reason I am replying to you is that I think you would benefit from my
expertise. Even when I don't think the proposal will make it through
acceptance in the Standard, I would like to see a *well-written* and thought
out proposal. As I said before, the only worse thing is to have a defective
proposal accepted.
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Principal Engineer - Intel Data Center - Platform & Sys. Eng.
Received on 2026-04-20 05:41:33