[bug-gs] 8.12: minor issues: non-doc

[der Mouse]

[Ray Johnston <ray.johnston at artifex.com>]
> A single bug report with all of the issues is fine since [...].
> If it is convenient to send the documentation issues separately from
> the build issues, that's slightly preferable, [...]

Okay, here are the non-doc issues.

genarch.c:

    Some of my build attempts ended up hanging while running genarch.
    I built a versino of genarch with -g and then attached to the
    running process with gdb.  It turns out that t_eps had a very large
    value - it looked like a small negative number in an unsigned
    variable.  (I didn't record the exact number; it could have been
    (the negative of) anything less than several thousand and I
    wouldn't've noticed the difference.)

    I don't understand how t_eps managed to come out negative.  Either
    clock()'s return value decreased or the second call failed, it
    appears, and neither of those looks very possible - but it quite
    definitely happened.  I added a little more code to genarch.c and
    it started working reliably for me:

	--- OLD/src/genarch.c	Thu Jan  1 00:00:00 1970
	+++ NEW/src/genarch.c	Thu Jan  1 00:00:00 1970
	@@ -228,11 +228,19 @@
	 
	 	/*
	 	 * Increase the number of repetitions until the time is
	-	 * long enough to exceed the likely uncertainty.
	+	 * long enough to exceed the likely uncertainty.  This code
	+	 * is careful to handle both signed and unsigned clock_t, and,
	+	 * at the same time, avoid compiler warnings.
	 	 */
	 
	-	while ((t = time_clear(buf, bsize, nreps)) == 0)
	-	    nreps <<= 1;
	+	t_eps = ~(clock_t)511;
	+	if (t_eps < 1)
	+		while ((t = time_clear(buf, bsize, nreps)) <= 0)
	+		    nreps <<= 1;
	+	else
	+		while (((t = time_clear(buf, bsize, nreps)) == 0) ||
	+		       (t > t_eps))
	+		    nreps <<= 1;
	 	t_eps = t;
	 	while ((t = time_clear(buf, bsize, nreps)) < t_eps * 10)
	 	    nreps <<= 1;

    I fully agree that this code should not be necessary, and I do not
    understand why it seems to be.  I put some time into trying to find
    out why it was, but with no success - it appears to be a Heisenbug;
    even ktracing the process made it go away.

src/unix{-gcc,ansi}.mak:

    Why does unix-gcc.mak include "libdir = $(exec_prefix)/lib" when
    unixansi.mak doesn't?

Relevant filename unknown:

    Adding $(PSD)/rasterop.dev to FEATURE_DEVS doesn't seem to work,
    even though it's in one of the commented-out FEATURE_DEVS lines and
    it's in FEATURE_DEVS_ALL.  The error I get:

	...
		./obj/echogs -e .dev -a-  ./obj/dpsnext -obj ./obj/zdpnext.o
		./obj/echogs -e .dev -a-  ./obj/dpsnext -oper zdpnext
		./obj/echogs -e .dev -a-  ./obj/dpsnext -ps gs_dpnxt
		make: don't know how to make ./obj//rasterop.dev. Stop

    What I did to deal with this was just to take the rasterop item
    back out of FEATURE_DEVS.

NetBSD-specific item:

    NetBSD's make(1) has a delightful little bug (well, I call it a
    bug, though since it's clearly deliberate I suppose it really ought
    to be called a misfeature) whereby, in the absence of being
    specifically told not to (by environment variables), if a
    subdirectory obj/ exists, it will at startup chdir into it.  This
    of course breaks commands that (not unreasonably) expect the
    current directory to be the starting directory.  While this isn't
    an issue for a successful build, it causes trouble if anything
    breaks and you try to restart the build without destroying obj/
    first (just emptying it out isn't enough).  While I hesitate to
    suggest renaming obj/ just to work around something that shouldn't
    have been put there in the first place, maybe an OS-specific
    section for NetBSD should be added that warns of this?

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse at rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B