[AD] Allegro 4 bugs

[Christopher G Dotyhumphrey <orz@xxxxxxxxxx>]

I've posted a number of bugs on allegro.cc over the last several months,
and the reply I get is always "Repost on the conductors list." even when I
post forum supposedly for reporting Allegro bugs, so I finally got around
to subscribing to AD and posting my bug reports here.

1.  Redrawing in grabber
Run a windows build of grabber.exe.
Press escape to quit.
Press alt-tab to go away.
Press alt-tab to come back.
Only the quit alert is redrawn, not the rest of the screen, even once you
exit the quit dialog. On my computer, this happens 100% of the time.
(win2k)

2.  Strangeness on linux?
I was recently attempting to telnet into a users linux box to figure out
why my allegro program wouldn't work there.  I found strangeness... after
a little while I wrote a simple test program, which I reproduce in full
here:
#include <stdio.h>
#include <allegro.h>
int main(int argc, char *argv[]) {
  FILE *f = fopen("out.log", "wt");
  fprintf(f, "%s\n", "foo");
  allegro_init();
  fprintf(f, "bar\n");
  fclose(f);
  return 0;
}
END_OF_MAIN()

This test program produces the following results:

~/timewarp$ rm out.log
~/timewarp$ ./test
Allegro application is running on VT 12
~/timewarp$ cat out.log
foo
~/timewarp$ logout

This was not exactly a wonderfull test environment, since this is some
elses computer, I have no clue how it's configured, I don't know anything
about linux or unix in the first place, and I'm running in a telnet
session.
But I cannot think of any rational reason to get this behavior.

3.  set_gfx_mode
Okay, this may not be exactly a bug, but I think this behavior should be
mentioned in the documentation.
Okay here's what I do to run into the issue:
My program launches, sets a valid video mode (using
GFX_AUTODETECT_WINDOWED in my test case), blah blah.  Then, it tries to
set a new video mode (calls set_gfx_mode a second time, using the same
GFX_AUTOD...).  But, this video mode is not available, so set_gfx_mode
returns a negative number, just like the docs say it will.  BUT, at this
point, even though I was in a valid video mode before the set_gfx_call,
and my program still appears to have a window, I am no longer in a valid
video mode now.  The next call that does video IO will crash (an alert()
call in my test case).  To avoid this, I call set_gfx_mode a third time
with the same parameters as I gave the first set_gfx_mode call (presumably
that mode still works...), and my video mode is once again works.