[FFmpeg-devel] [RFC] AES init
Reimar Döffinger
Reimar.Doeffinger
Sun May 13 17:52:26 CEST 2007
Hello,
On Sun, May 13, 2007 at 05:44:45PM +0200, Alex Beregszaszi wrote:
> > > Current AES tables init looks as follows:
> > >
> > > if(!enc_multbl[4][1023]){
> > >
> > > While the tables are defined as:
> > >
> > > #ifdef CONFIG_SMALL
> > > static uint32_t enc_multbl[1][256];
> > > static uint32_t dec_multbl[1][256];
> > > #else
> > > static uint32_t enc_multbl[4][256];
> > > static uint32_t dec_multbl[4][256];
> > > #endif
> > >
> > > That means [4][1023] is pointing to an invalid area in both case.
> > >
> > > For my case, this caused AES to malfunction, the AES struct was not
> > > inited (only the key's were there). This happened to me in GCC 4.0.3.
> > >
> > > My change is as follows, introducing a bad static variable. Other
> > > solution would be checking for enc_multbl[0][0] ? But than again, this
> > > probably breaks with compilers not zeroing those variables (like VisualC
> > > which sets them to 0xCC). I know some will shout that "broken compilers
> > > are not supported".
> >
> > global/static variables must be zeroed (see C standard)
> > also static type foober[123]={0} will zero it
>
> Okay, but this still doesnt clears the issue: [4][1023] points to
> invalid area. Why not just checking for this first byte?
No, that is not thread safe, you must check for whatever is inited last.
I personally would have preferred a separate volatile inited variable
that is set at the very end, but Michael seems to prefer not uselessly
introducing extra variables *g*
Greetings,
Reimar Doeffinger
More information about the ffmpeg-devel
mailing list