[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