[FFmpeg-devel] [PATCH] Check for signal.h, conditionally compile parts of ffmpeg.c

[Måns Rullgård]

Ramiro Polla <ramiro.polla at gmail.com> writes:

> On Mon, Jul 13, 2009 at 7:11 PM, Martin Storsj?<martin at martin.st> wrote:
>> The attached two patches first check for signal.h in configure, and then
>> leave out non-critical parts of ffmpeg.c if it isn't found.
>>
>> signal.h isn't available on mingw32ce (mingw32 for WinCE). These patches
>> reduce the amount of ugly hacking needed to compile ffmpeg.c on that
>> platform.
>>
>> The double definition of received_sigterm isn't really pretty, but IMHO
>> looks better than ifdeffing all the places where it's used. Another
>> solution would be to add "typedef sig_atomic_t int;" somewhere if signal.h
>> isn't available, and move the variable definition out of the ifdef block.
>
> I think redefining a POSIX type is even worse.

I agree.

> Mans, what do you think about this patch?

There is no need for this to variable to be sig_atomic_t in the first
place.  The worst that could possibly happen is the encoding loop
doing one extra iteration, and that only if an 'int' cannot be read in
a single instruction, which is exceedingly unlikely to be the case on
any platform we'll ever support.

-- 
M?ns Rullg?rd
mans at mansr.com