Opened 2 years ago

Closed 2 years ago

#6117 closed defect (needs_more_info)

type mismatch of AC3EncodeContext in different translation units

Reported by: dkrupp Owned by:
Priority: normal Component: undetermined
Version: unspecified Keywords:
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

Summary of the bug:
While analyzing your project with clang I spotted the following problem.

The struct AC3EncodeContext (defined in ac3enc.h) is defined differently depending on the CONFIG_AC3ENC_FLOAT macro.

When compiling eac3enc.c the CONFIG_AC3ENC_FLOAT is 1, while in ac3enc.c it is 0.

But there is a pass of this struct from in line 417 in ac3enc.c
...

if (CONFIG_EAC3_ENCODER && s->eac3)

ff_eac3_get_frame_exp_strategy(s);

...
The two translation units (TU) are linked together, and since the definition of the struct in the TUs are different, this could cause memory corruption problems when accessing its fields (and against the one definition rule).

The potential bug still exists in commit e4d65434633b67fd03d379fe9d0ab9dc97d767dc

Change History (5)

comment:1 Changed 2 years ago by cehoyos

How can I reproduce the memory corruption?

comment:2 Changed 2 years ago by dkrupp

I did not reproduce the problem in run-time. Inspecting the code a bit more in detail I see that in AC3EncodeContext there are only pointers to the changing types: SampleType?,CoefType? and thus the size of and memory layout of the struct remains the same in the 2 TUs. So I do not expect run-time error in the current form of the struct.

Still, this violates the one definition rule of C/C++ which may not cause run-time error in this very specific case.

comment:3 Changed 2 years ago by cehoyos

How can I reproduce the analysis that shows this issue?

comment:4 Changed 2 years ago by cehoyos

Does the "one definition rule" really apply to C?

comment:5 Changed 2 years ago by cehoyos

  • Resolution set to needs_more_info
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.