[FFmpeg-devel] [RFC] AES init

Alex Beregszaszi alex
Sun May 13 17:54:04 CEST 2007


Hi,

> > > > 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*

In any case, [4][1023] is not a valid memory area.

--
Alex Beregszaszi






More information about the ffmpeg-devel mailing list