[MPlayer-dev-eng] [PATCH] two trivial vbelib fixes

[D Richard Felker III]

On Mon, Nov 24, 2003 at 06:21:18PM +0100, Peter Kosinar wrote:
> Hello developers!
> 
> The following information is based on my limited knowledge of this area,
> so my conclusions may be wrong.  In such case, I'd like to ask you to
> correct me.
> 
> *** osdep/lrmi.c:run_vm86()
> When calling lrmi_vm86(), the value of GS is saved (and later restored),
> but the value of FS is not. This could interfere with some Windows-ish
> DLLs (eg. QuickTime) which use addressing relative to FS [vm86() call
> sets FS and GS to zero]. Fixed by copying the GS saving/restoring code.
> 
> *** osdep/vbelib.c:hide_terminal_output()
> Buggy lines (XXX stands for stdin/stdout/stderr, Y is "r" or "w"):
> 
> %   my_XXX  = fopen(ttyname(fileno(XXX)),Y);
> 
> If XXX is not a tty, ttyname(fileno(XXX)) returns NULL, which is passed as
> the first argument to fopen(). Usually, it would fail with EFAULT, because
> 0x0 is not a valid location. In this case, LRMI_init() was called before
> and it mmap()ed first few bytes of /dev/mem (int. vectors, ...) to location
> 0x0. Thus, fopen() will open (or create, if Y is "w") a file with a strange
> name (interrupt vector address, in my case "\x01").  Fixed by checking the
> return value of ttyname() and acting appropriately.

WTF?!?! mmap to 0x0 is NOT acceptable! This makes it so null pointer
dereferences will not cause sig11, but instead overwrite the mmapped
/dev/mem!!! Find some other way to make this work without mmapping to
0x0!

Rich