[Development] Backporting the Keccak change
Thiago Macieira
thiago.macieira at intel.com
Tue Sep 5 19:16:33 CEST 2017
On Tuesday, 5 September 2017 14:04:14 -03 Oswald Buddenhagen wrote:
> On Tue, Sep 05, 2017 at 10:29:44AM -0300, Thiago Macieira wrote:
> > On Tuesday, 5 September 2017 05:09:19 -03 Oswald Buddenhagen wrote:
> > > # ifndef QT_FIXED_SHA3
> > >
> > > QT_DEPRECATED_SINCE(5, 10, 0) Sha3_224 = 7,
> > > QT_DEPRECATED_SINCE(5, 10, 0) Sha3_256,
> > > QT_DEPRECATED_SINCE(5, 10, 0) Sha3_384,
> > > QT_DEPRECATED_SINCE(5, 10, 0) Sha3_512,
> > >
> > > # else
> >
> > Almost. There are two things there:
> > 1) I'dl ike people to opt into the broken code, so I think the #if should
> > be>
> > reversed. It will cause a few support tickets and bug reports, but I think
> > it's best this way for the long term. At some point, we'd have to do it
> > anyway.
>
> well, i know that you'd like to, but it's still breaking the compat
> promise for no _really_ convincing reason.
Other than correctness? And that we've done it in 5.9.0 and 5.9.1 anyway?
I think people who want a *second* behaviour change should need to opt into
it.
> while the current implementation is clearly broken, it apparently works
> well enough for those who use it, and the others don't use it anyway
> (obviously). so the idea is to not fix the problem, but to do an, ehhm,
> "specification update". ;)
>
> there isn't really much added value to making the wrong behavior opt-in,
> because the user can then just use the new enum values straight away.
Not if they need to keep compatibility with pre-5.9 code. That's the advantage
of a #define solution over Peppe's original implementation. They may have one
codebase that should keep working with both.
Additionally, they can add the #define now and not worry about when they need
to rebuild with 5.9 or 5.10.
> > 2) you can't use QT_DEPRECATED or Q_DECL_DEPRECATED on enumerations
> > unless __cpp_enumerator_attributes >= 201411
>
> i sort of expected that. how about a separate macro for enums, to avoid
> an ifdef mess? maybe we have it already?
I thought we did. I distinctly remember doing this before, but I can't find it.
It must have been in a change of mine that never panned out.
I'm more afraid of the fall-out of other SD-6 issues, like Clang issuing
warnings. So I'll add the deprecated macros for 5.9.3 or 5.10, as we have more
time to test it. Let 5.9.2 go without warnings.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
More information about the Development
mailing list