What are you passing in as path?
	If its null, empty, or just all 'X', then wont 81 fall of the 
	start of the string?

		David/abs

david@city.ac.uk +44 171 477 8186 (MIME) david@southern.com +44 0181 88 8949
Network Analyst, UCS, City University   System Manager, Southern Studios Ltd
Northampton Square, London EC1V 0HB                PO Box 59, London N22 1AR

        <<< Monochrome - Largest UK Internet BBS - telnet mono.org >>>
>=- Microsoft: Abort and Retry Cancel -or- NetBSD: http://www.netbsd.org -=<
         (Apologies for long signature - in process of changing jobs)

On Tue, 24 Oct 1995, Jon Buller wrote:

> Well, here's a strange one I've run into.  It almost looks like a
> code-gen bug in gcc 2.6.3, but I re-compiled with -O, and got the
> same result.  Here's the mktemp code in my libc.  I compiled it
> with -g and ran it with gdb, and the findings are that it gets the
> bus error on line 82, implying that a pointer has gone off the deep
> end.  Except that the pointer is actually pointing to the end of
> the path parameter like it's supposed to.  (BTW, the error occurs
> about 20 unoptomized machine instructions into line 82, where I'd
> guess the assignment is roughly taking place.  It happens the first
> time line 82 is executed.)
> 
> static int
> _gettemp(path, doopen)
> 	char *path;
> 	register int *doopen;
> {
> 	extern int errno;
> 75	register char *start, *trv;
> 76	struct stat sbuf;
> 77	u_int pid;
> 78
> 79	pid = getpid();
> 80	for (trv = path; *trv; ++trv);		/* extra X's get set to 0's */
> 81	while (*--trv == 'X') {
> 82		*trv = (pid % 10) + '0';
> 83		pid /= 10;
> 84	}
> 
> Any ideas?  If it's really a bug, I hope it's out by 1.1  On the
> other hand, I've had my machine pull some suprises on me in the
> past, and this could just be another one.
> 
> Jon
>