Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: notesfiles
Path: utzoo!watmath!clyde!akgua!sdcsvax!sdcrdcf!hplabs!hp-pcd!hpfcla!ajs
From: ajs@hpfcla.UUCP
Newsgroups: net.unix-wizards
Subject: Re: HP Fortran bug
Message-ID: <43900009@hpfcla.UUCP>
Date: Mon, 28-May-84 01:13:00 EDT
Article-I.D.: hpfcla.43900009
Posted: Mon May 28 01:13:00 1984
Date-Received: Thu, 31-May-84 19:37:11 EDT
References: <-31000@uiucme.UUCP>
Organization: Hewlett-Packard Fort Collins Systems Division - Fort Collins, CO
Lines: 28
Nf-ID: #R:uiucme:3100003:hpfcla:43900009:000:1347
Nf-From: hpfcla!ajs    May 19 21:13:00 1984

This is posted on behalf of the Hewlett Packard Computer  Languages Lab.
It is in response to an earlier  complaint  here about the HP9000 Series
500  FORTRAN  compiler.  Note that I  previously  posted a more  general
description of the bug in fopen(3s), USG System III version.

Alan Silverstein, Hewlett-Packard Fort Collins Systems Division, Colorado
{ihnp4 | hplabs}!hpfcla!ajs, 303-226-3800 x3053, N 40 31'31" W 105 00'43"

	Problem:   If a super-user with umask of 022 runs a FORTRAN 
		   compile (on the Series 500) such as "fc myfile.f", 
		   the root removes group and others write permission on 
		   /dev/null.  This has the effect of preventing non-
		   super-users from running the compiler.

	Reason:    An fopen("/dev/null","w+") call causes umask to be
		   applied to /dev/null's file permissions.  This is 
		   incorrect because /dev/null already exists.  Both
		   the FORTRAN and the Pascal compilers may make calls 
		   of this type to fopen.

	Solution:  Umask will not be applied to a file that already 
		   exists by an fopen "w+" (create for update) call
		   under HP-UX version 4.0.  Until then, a super-user
		   with a non-zero umask will usually have to reset the
		   file permissions ("chmod +rw /dev/null") after a 
		   FORTRAN or a Pascal compile.
   
                   From: CLL Technical Support Group