[Date Prev] [Date Next] [Thread Prev] [Thread Next] Date Index Thread Index Search archive:
Date:Mon Nov 9 22:14:39 2003 
Subject:Re: Using 'varargs' vs 'stdargs' (and new pc+linux tar ball) 
From:A . Sloman 
Volume-ID:1031109.01 

Waldek wrote, in response to my query about varargs vs stdargs:

> FYI stdarg.h in in ANSI C standard from 1989. Gnu C supported it very
> early (I remember it in 1992 version, but probably it was introduced
> few years earlier). In 1995 using varargs.h was a smart move, as many
> systems had obsolete compilers  (some vendors by default shiped old
> compilers with new systems, charging extra for new compiler) without
> support for stdarg.h. Of 17 configurations in the Poplog tree 3 certainly
> have stdarg.h (pcunix, pcwnt and sun4r5), 5 is so old that probably
> do not support it (sun3, sun3x, hpbob, vaxunix4.2, vaxunix4.3) and
> other are uncertain.

At present, I am working ONLY on the pc+linux system, ignoring others,
as there is quite a lot of work to be done to reconfigure various
things, and it has to fit between many other tasks.

I only have access to linux at home (with remote access to a sun), so to
save my time I am changing things and testing them only on linux (on my
pc). From time to time I check that the changes work on different
versions of linux. (Currently I have problems with a PC cluster running
RedHat 8 with support for dual cpu. Poplog used to work, but has stopped
after some reconfiguring of the machine. But I have not had time to sort
out why).

Later, I plan to propogate the changes to other systems using whatever
help I can get.

I regard the following as permanently frozen, and probably dead in
several cases:
	(Motorola 68xxx-based systems) sun3, sun3x, hpbob
	VAX systems: 	vax+vms, vax+ultrix, vax+unix(all flavours)
	decstation
	hppa: (HP9000_700)
	SGI machines, e.g. iris
	sun4 (sparc + SunOs)
	Alpha + VMS
	and maybe also ppc + aix
		(unless IBM, or an IBM user shows some interest in reviving
		this.)

After I think the PC+linux version has reached a fairly stable
and steady state I hope to transfer the upgrades to the
sparc+solaris version. At present that uses the SparcWorks
compiler, but if it can be rebuilt using gcc, as someone
recently suggested, that may be preferable, since not everyone
wishes to pay for Sun's Sparc compiler.

I used to have access to an alpha running digital unix, but no longer
have. It was a nice system -- the only 64bit version of poplog, so
it would be good if someone with access to an alpha could upgrade poplog
when it reaches a suitable state.

The windows versions are being dealt with by others, led by Jeff Best: I
know nothing about windows, and never use it, except occasionally
helping my wife get out of some mess (one-eyed leading the blind): I
would convert her machine to linux except that she needs to use the
superb 'ocad' package for making orienteering maps.

In the short run this means that the work on the sourceforge system and
my work will diverge a bit. However, I am keeping track of changes and
hope to provide a package that can be uploaded when all the sourceforge
mechanisms are working, in particular when there's a usable windows
poplog with the full X-based poplog graphical facilities working under
cygwin. It can then be upgraded to whatever version I have in
Birmingham. What I do should be orthogonal to the work being done at the
sourceforge site, so any changes I make should be simple to import.

Regarding varargs-stdargs

[WH]
> So the change will probably break many old configurations, but modern
> ones should work OK. AFAIK one can still use old configurations, just
> need first to install Gnu C.

For the time being I have saved the old varags files (there are only
three of them), with an AREADME file in
	$usepop/pop/x/Xpw-varargs/

So if needed they can be copied across to
	$usepop/pop/x/Xpw/

I have now packaged the new stdargs version of Xpw, along with fixes to
the other problems identified by Andreas Eder, in
	http://www.cs.bham.ac.uk/research/poplog/bham-linux-poplog.tar.gz
		21198852 bytes Nov 9 21:31

I hope this now works on SuSe and FreeBSD as well as RedHat.

John Duncan raised the problem of replacing dependence on termcap with
use of ncurses, for the benefit of debian users, and maybe others.

I have no idea how much work that would be as don't know anything in
detail about either termcap or ncurses, except that they are both
concerned with cursor control on dumb-terminal interfaces. I presume it
would be tedious but not difficult to make the changes to provide the
option for ncurses to work, but it's not something I'll ever have time
to look into.

Aaron