jt@nrcvax.UUCP (11/11/85)
Newsgroups: mod.computers.vax Subject: Re: Open bug in VAX C V2.0 References: <8511071615.AA04882@ucbvax.berkeley.edu> Reply-To: jt@nrcvax.UUCP (Jerry Toporek) Organization: Network Research Corp. Oxnard, CA Keywords: vms c open bug In article <8511071615.AA04882@ucbvax.berkeley.edu> "NUNN, JOHN C." <nunn@nbs-vms.ARPA> writes: > >There is a bug in the open function of VAX C V2.0 which will >cause some UNIX utilities to fail when compiled and run under >VMS. When an open is called for a file which does not exist, >the next file descriptor, which would be assigned to the file >if it existed, is assigned to the non-existent file. > ... >Can someone verify whether this bug also exists in V2.1 of VAX C? >Also, does anyone know if this has been SPR'ed? >------ Yes, the bug is still in v2.1. I have submitted an SPR. --------- Jerry Toporek Network Research Corp. ihnp4!nrcvax!jt 1620 Federal Ave. Suite #2 ucbvax!calma!nrcvax!jt LA, CA, 90025, USA {sdcsvax,hplabs}!sdcrdcf!psivax!nrcvax!jt (213) 479-6436
jmsellens@WATERLOO.CSNET (John M Sellens) (11/13/85)
"That was no bug, that was my wife"
Any program that relies on getting a particular file descriptor at a
particular point in its execution is broken. If you care what unit
number you get, use dup() or freopen(). Sure enough someone will add
some code to open a log or error file or something, and the whole
shebang will stop working.
My sympathies to anyone forced (at gunpoint presumably) to port such broken
code.
John
UUCP: {decvax|utzoo|ihnp4|allegra|clyde}!watmath!jmsellens
CSNET: jmsellens%watmath@waterloo.csnet
ARPA: jmsellens%watmath%waterloo.csnet@csnet-relay.arpaH_Eidnes%vax.runit.unit.uninett@NTA-VAX.ARPA (H}vard Eidnes) (11/16/85)
> Any program that relies on getting a particular file descriptor at a > particular point in its execution is broken. ... Well, the fact remains that the semantics that you get the *lowest free* file descriptor is *documented* in every Unix Programming Manual (at least all that I have come across...), so all programmers creating programs to be run under Unix, can rely on this "feature". So if Vax/Vms C should be "compatible" with Unix C, it should also implement and document this feature. If it is a wise design decision to impose this rule in the first place, however, is another matter...
info-vax@ucbvax.UUCP (11/22/85)
> > Any program that relies on getting a particular file descriptor at a > > particular point in its execution is broken. ... > > Well, the fact remains that the semantics that you get the > *lowest free* file descriptor is *documented* in every Unix > Programming Manual (at least all that I have come across...), I have two versions of Unix Programmer's Manuals; one is the 4th Berkeley Distribution, and the other is from Fortune Systems (For:Pro is the name they use for their port of Unix). The rule you cite is not mentioned in the description of the open system call (vol 1, open(2)). Where, precisely (version, volume, section, page), have you seen this rule documented? And how, in general, does one know where to look? Gary Samuelson
H_Eidnes%vax.runit.unit.uninett@NTA-VAX.ARPA (H}vard Eidnes) (11/26/85)
> > > Any program that relies on getting a particular file descriptor at a > > > particular point in its execution is broken. ... > > > > Well, the fact remains that the semantics that you get the > > *lowest free* file descriptor is *documented* in every Unix > > Programming Manual (at least all that I have come across...), > > ... The rule you cite is > not mentioned in the description of the open system call (vol 1, open(2)). Well, now I've learned my lesson. Don't write what you *think* is in the manual. Write what *is* in the manual (and look before you write :-) Well - seems I mixed it up the behaviour of open(2) and dup(2). (It is documented that dup(2) returns the lowest free file descriptor.) Sorry to have to trouble you all with this mistake.