[net.unix] liszt compiler destination

michaelm@bcsaic.UUCP (michael maxwell) (02/21/86)

[Frantz Lisp Opus 38.91, running on a SUN II with v.2 operating sys = BSD4.2]

I just spent an hour tracking down a problem in a makefile that turned out to
be due to a bug in the way the liszt compiler handles path names.
You can give it a relative path name, but not an absolute path name!  That is, 
assuming I'm in the directory "dira", which has a subdir "dirb", the ff. works 
fine:
	liszt dirb/foo.l
--but the following:
	liszt foo.l /usr2/michaelm/dira/dirb/foo.l
--or:
	liszt ~michaelm/dira/dirb/foo.l
results in an empty file whose name is "/usr2/michaelm/dira/dirb/fum.o"!
All signs are that the compilation proceeds normally; it gives the expected
source and destination file names, and proceeds to create the expected output
file--but there's nothing in it.  Where does the assembled output go?

Similar problems occur when I use the -o option with a full path name.  
These problems do*not* happen when the output is sent to a file in /tmp, so I 
assume it has something to do with the directory permission.  (Doing "chmod 
755 dirb" does not fix the problem, so higher levels in the directory hierarchy 
must be causing problems (also).)  Presumably there is an attempt at security 
here, but it certainly doesn't work, as liszt cheerfully wipes out anything 
that was in the output file previously.

What's going on here?  Do any other compilers (etc.) have this problem?
-- 
Mike Maxwell
Boeing Artificial Intelligence Center
	...uw-beaver!uw-june!bcsaic!michaelm

chris@umcp-cs.UUCP (Chris Torek) (02/24/86)

In article <459@bcsaic.UUCP> michaelm@bcsaic.UUCP writes:

>[There is] a bug in the way the liszt compiler handles path names.
>You can give it a relative path name, but not an absolute path name!
>[...] liszt foo.l /usr2/michaelm/dira/dirb/foo.l
>results in an empty file whose name is "/usr2/michaelm/dira/dirb/fum.o"!
>[...] Where does the assembled output go?

Index: /bin/as	1.4, 2.0

Description:
	The Sun `as' assembler cannot handle an output file pathname
	longer than 32 characters.  What it in fact does is truncate
	the named file to zero length, then put its output in a file
	with the same name but truncated to 32 characters.

	I do not know whether the bug is present in 3.0 or 3.1.

Repeat-By:
	% mkdir bug; cd bug
	% cat >x.s <<end
		.globl	_foo
	_foo:	rts
	end
	% as -o 12345678901234567890123456789012345.o x.s
	% ls -l | sed 's/  */ /g'
	-rw-r--r-- 1 chris 57 Feb 23 16:33 12345678901234567890123456789012
	-rw-r--r-- 1 chris 0 Feb 23 16:33 12345678901234567890123456789012345.o
	-rw-r--r-- 1 chris 23 Feb 23 16:33 x.s
	%
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1415)
UUCP:	seismo!umcp-cs!chris
CSNet:	chris@umcp-cs		ARPA:	chris@mimsy.umd.edu