screen at Linux/Alpha blows up, unless...

[Matti Aarnio <matti aarnio sonera fi>]

resent with corrected address to axp-list ...
( Subject:  screen at Linux/Alpha blows up, unless... )
( To:  screen@uni-erlangen.de, axp-linux@redhat.com )

Hello,

	At RedHat 5.1 there is screen version 3.7.4 along with
	two patches from 3.6.2 era with (mainly) PTY related
	fixes to support Linux.

	When autoconfiguring that into GLIBC 2.0 system the result
	gets one thing wrong -- perhaps source-code should be altered ?
	Namely, the source tries to use its own  xvsnprintf() routine
	which has some  "xva_list"  argument list definition.

	Unfortunately that "xva_list" does not match the real "va_list"
	as used in the system, and thus sometimes the result is apparent
	corruption of the stack-frame with seeminly innocent usage:

	Call:	Msg(..., "foomsg %s", strptr);

	The "strptr" value appears to be truncated into 32-bits, and
	as such its value is the high 32-bits of the 64-bit "fmt"
	pointer...  NULL, that is.

	Naturally the screen gets a SIGSEGV from that, and all the hell
	has broken loose.

	The sad part is, the ./configure  run has detected that the
	system has  vsnprintf()  and has set:
		HAS_VSNPRINTF
	variable into  config.h  file.
	However, that condition variable is only tested if another
	variable is set, namely:
		USEVARARGS
	which isn't set..   Manually setting that after the configuration
	run was complete did produce sane and working program which
	reported "Bell at screen N" when I was at some other screen.
	So it can be coerced to behave like it does at ia32 machines
	with otherwise same environment.

	Another issue is that the system does not appear to do
	test for "getcwd", and uses 'os.h' to rely on "-DSYSV"
	definition to tell when to cast that fine supported and
	well working routine into deprecated  getwd()  version.


	How to fix these ?
	At ZMailer I use following tests in  configure.in,  and
	related output values in my  config.h(.in):

		AC_CHECK_HEADERS(varargs.h stdarg.h)
		AC_CHECK_FUNCS(getcwd)

	My code there then sees if 'HAVE_STDARG_H' is defined, and
	acts according to it (modulo __STDC__.)  If that is not found,
	my code falls back to assume 'HAVE_VARARGS_H'.

/Matti Aarnio <matti.aarnio@sonera.fi>