x264のスレッドのバグと、前提条件について

fix a crash on win32 with threads.

fix a crash on win32 with threads.
r852 introduced an assumption in deblock that the stack is aligned.

何が問題かというと、r852によって、スタックが16バイトアラインメントされているというassumptionがあったのだ。x86_32のABIは、4バイトアラインメントしか保障していない。何故この問題がテストに引っかからなかったかというと、linux上のgccは、常にスタックを16バイト上にアラインメントするからだ。

17:15 (hito) i had never met crash with multi-thread encoding. is it a rare thing to happen? i wonder why this bug is windows only.
17:19 (pengvado) x86_32 abi only guarantees 4-byte stack alignment. pthread-win32 does that. but gcc on linux does 16-byte alignment.
17:20 (hito) hmm intresting.

そして、新しいファイル、standards.txtがdoc以下に加えられている。この中身は次の通り

x264 is written in C. The particular variant of C is: intersection of gcc-2.95 and msvc. This means C89 + a few C99 features.
The extra utilities (mostly checkasm) are written in C99, with no attempt at compatibility with old compilers.

We make the following additional assumptions which are true of real systems but not guaranteed by C99:
* Two's complement.
* Signed right-shifts are sign-extended.

x86-specific assumptions:
* The stack is 16-byte aligned. We align it on entry to libx264 and on entry to any thread, but the compiler must preserve alignment after that.
* We call emms before any float operation and before returning from libx264, not after each mmx operation. So bad things could happen if the compiler inserts float operations where they aren't expected.

つまり、x264のコードは、2の補数である事と、符号ビットが右シフトで動くことを前提としている。これはC99では保障されていない。なぜこんなドキュメントをつけたかというと、まあ、私が吹っかけた議論ではあるのだが。

22:29 (hito) in x264_median, is it always guaranteed?　a-b >= 0, b-c >= 0
22:30 (Dark_Shikari) no
22:31 (hito) in C spec, shift operands must be nonnegative. otherwise its behavior is undefined.
22:32 (Dark_Shikari) where is there such a case
22:32 (Dark_Shikari) in the code
22:32 (Dark_Shikari) all the shift values are 31
22:33 (Dark_Shikari) ((a-b)>>31) is equivalent to "give us the sign bit"
22:33 (hito) i mean if there is expression like "a >> b", both a and b must be nonnegtive.
22:33 (Manao) hito: huh ? >> on signed value is a sar
22:34 (Manao) it's well defined
22:34 (hito) standard say nothing about sign bit. just leave it as implementaion defined.
22:35 (Manao) and every C compiler is know of treat it as a sar. So there may be an addendum to the C standard
22:35 (Manao) s/is/I/
22:35 (Dark_Shikari) if someone didn't treat it as a sar other programs would probably break too >_>
22:40 (hito) maybe someone release strange architecture which place sign bit at the least significant bit.