Gribnif@UMass.BITNET.UUCP (11/25/87)
portal!atari!apratt@uunet.uu.net (Allan Pratt) writes: > Now here's the tricky part: Fdelete (as called from outside GEMDOS or > within it, like from Fcreate) checks to see if anybody has the file open. > If the current process has the file open, Fdelete closes it before deleting > it. If some OTHER process has the file open, Fdelete returns EACCDN > ("access denied"). This seems to be what is happening, but I can't > figure out why, because nobody else has the file open! > Proc1: > ------ > Fcreate ("file1",0); > Fcreate ("file2",0); > Pexec(4,"Proc2",0L,0L); > > Proc2: > ------ > Fdelete("file1",0); > /* returns EACCDN: Proc1 has file open */ > > Fcreate("file2",0); > /* works, even though it should fail */ > > Pterm0(); > Pterm0(); What you are forgetting is that the first Fcreate not only creates the file, it also opens it and returns a file handle (long) which can be used in any I/O later on. It is for this reason that the Fdelete in Proc2 fails. Actually, Fcreate is often preferable over Fopen because what it seems to do is it checks to see if the file exists and, if it does, it tries to open the file. Otherwise it creates a new file with that name and opens it. I do agree that it *does* (this is the bug) create a new file if the file is already opened. (Maybe the type of access matters? Would an Fopen( file, READ_ONLY ) also mess things up? I may try that and see...) On the subject of my earlier letter regarding what I thought were several bugs in MWC... The first complaint was universally agreed upon to be the fault of the compiler. Both: int i = -32768; and unsigned int i = 60000; should be valid but the compiler always produces the message 'integer "i" promoted to long'. In my second example, however, the bug was my own. I made the mistake of not testing this thoroughly enough. The situation in which I was getting what I thought was an incorrect result was not as I stated in my example. The example does work correctly, my apologies; my problem arose when the operand being added to was a character pointer. Normally, if you try something like: char *c; c = <any long number that is the result of calculations> the compiler comes back with an "integer pointer pun" warning, however this is not the case when the "=" is instead a "+=". Certainly, if the compiler truly perceives a character pointer as being only 16 bits long (as the warning message and the fact that the only way to avoid it is to change the line to "(long) c = ..." would have me believe ) then adding a long to it without any type conversion would lead to strange results. Maybe somebody could enlighten me a bit though: Why should the type cast be necessary? Since a pointer is an address in memory, shouldn't it always be 32 bits long? If not, should the compiler also warn me when I am trying to += what it sees as being a 16 bit address with a long number? I just ran the following program with the results that follow: main(){ char *c; long i; i = 99999L; c = 0L; printf( "c: %D n", c ); c += i; printf( "c += i: %D n", c ); c = i; /*gives "integer pointer pun" warning*/ printf( "c = i: %D n", c ); } c: 0 c += i: 1 c = i: 99999 So it would appear that even though it calls the last one a pun (why not the first one too?) it does assign the value correctly. For whatever reason the second one seems to be incorrect though. Any ideas? I apologize fort he incorrect example in my first letter (and also for using the phrase "ones compliment". Can you say, "stop writing letters at 3 am?" I knew that you could...) Dan Wilga ----------------------------------------------------------------------------- AndOr@UMASS.Bitnet "That young girl...is the least beknightedly Arpa? Your guess is unintelligent organic life form, it has been as good as mine! my profound lack of pleasure not to be able to avoid meeting" -- Hitchhikers