Re: [RFC/Patch] libstdc++/14320 aka class type streamoff doesn'twork :(

[Paolo Carlini <pcarlini at suse dot de>]

Gabriel Dos Reis wrote:

> If you carefully read my previous messages, you'll notice that it is
> the standard that should be fixed.
Again this old story? I'm not a member of the standard committee, I'm an
implementor, and here, since we are on the libstdc++ list you are also,
therefore, discussing that is a waste of time. You are right, I can only
agree with you and learn from you about those topics (I'm 100% serious,
for sure you understand what I mean), but we should preferably discuss
this offline, for the list is a pure waste of time. We are here for
implementing the standard to our best. Personally, I'm proud and honored
to be paid to do that, since I like my (implementor) work.

Each and every day we have the standard, we have PRs correct according to
it, and "prima facie" we have to thank submitters, fix our implementation,
and that's it. Or, we may decide to not fix a bug since we strongly believe
that the standard is incorrect, and in that case that is "WONTFIX", which
we (you) should respectfully explain to submitter (possibly citing a DR,
or submitting one ASAP) and, important, in the release notes. "Tertium non
datur".

My impression, to tell you what I really believe, is that too many times,
instead of fixing bugs or the release notes (either is OK) you prefer
lenghty discussions, which are absolutely not appropriate and a waste of
time for the *implementor* role (vs, C++ standard expert and scientist).

By the way, care of reviewing Jerry's fix for 3247, which you promised to
do in "a day or two" back at the beginning of January?

And what about 13450? I think that Roger has provided the infrastructure
that you requested, right?

And what about 8670? Honestly, either you *actually* provide quickly the
clean solution involving attributes, or someone else will answer the PR to
his own non-perfect best but, at the same time, in reasonable times, using
Martin's kind suggestion.

And so on...

Paolo.