Path: utzoo!attcan!uunet!mcvax!hp4nl!philmds!prle!cstw01!meulenbr
From: meulenbr@cstw01.UUCP (Frans Meulenbroeks)
Newsgroups: comp.os.minix
Subject: Re: new and improved freopen.c (I hope)
Message-ID: <266@cstw01.UUCP>
Date: 18 Nov 88 09:33:56 GMT
References: <260@cst.UUCP> <1782@laidbak.UUCP>
Reply-To: meulenbr@cstw01.UUCP (Frans Meulenbroeks)
Organization: Centre for Software Technology, Philips Eindhoven
Lines: 125

In article <1782@laidbak.UUCP> katzung@laidbak.UUCP (Brian Katzung) writes:
>In article <260@cst.UUCP> meulenbr@cst.UUCP (Frans Meulenbroeks) writes:
>>X#define  PMODE    0644
>
>Shouldn't this be 0666 so that umask can be used to get the desired mode?

I've not the slightest idea! I just picked this from the original fopen.c
Can one of the Minix wizards (Johan? Andy?) comment?
>
>>X	flags = flags & !WRITEMODE & !READMODE;
>
>That sets all bits to zero (perhaps those are network-mangled tildas??).
>I believe you meant
>
>	flags &= ~(WRITEMODE | READMODE);
>
Oops: I meant:
	flags = flags & ~WRITEMODE & ~READMODE;
The error was brain mangled, not network mangled.

Note that this line of code is due to the fact that I assumed that
buffering etc. stays the same during a reopen. Could not find anything to
assert or deny this assumption. Anyone an idea?

>>X	case 'a': 
>>X		flags |= WRITEMODE;
>>X		if (( fd = open(name,1)) < 0 )
>>X			return((FILE *)NULL);
>>X		lseek(fd,0L,2);
>>X		break;         
>
>Append is really two attempts:
>
>	if ((fd = open(name, 1)) < 0 && (fd = creat(name, PMODE)) < 0)
>		return ((FILE *) NULL);
>
[ some stuff deleted]
The code I sent is again copied from fopen.c
>
>Do the original routines support r+, w+, and a+ modes?  These are nice

No! I'd love to see them, but haven't had time to make them.

>to have.  I'm not near a Minix machine at the moment.  Does Minix support
>open with 3 arguments?  This would make an implementation a little
>easier/cleaner.

Again. No.
>
[ small flame deleted]
>
>-- Brian Katzung  ...!spl1!laidbak!katzung



Newsgroups: comp.os.minix
Subject: Re: new and improved freopen.c (I hope)
Summary: 
Expires: 
References: <260@cst.UUCP> <1782@laidbak.UUCP>
Sender: 
Reply-To: meulenbr@cstw01.UUCP (Frans Meulenbroeks)
Followup-To: 
Distribution: 
Organization: Centre for Software Technology, Philips Eindhoven
Keywords: 

In article <1782@laidbak.UUCP> katzung@laidbak.UUCP (Brian Katzung) writes:
>In article <260@cst.UUCP> meulenbr@cst.UUCP (Frans Meulenbroeks) writes:
>>X#define  PMODE    0644
 
>Shouldn't this be 0666 so that umask can be used to get the desired mode?

I've not the slightest idea! I just picked this from the original fopen.c
Can one of the Minix wizards (Johan? Andy?) comment?
 
>>X	flags = flags & !WRITEMODE & !READMODE;
 
>That sets all bits to zero (perhaps those are network-mangled tildas??).
>I believe you meant
 
>	flags &= ~(WRITEMODE | READMODE);
 
Oops: I meant:
	flags = flags & ~WRITEMODE & ~READMODE;
The error was brain mangled, not network mangled.

Note that this line of code is due to the fact that I assumed that
buffering etc. stays the same during a reopen. Could not find anything to
assert or deny this assumption. Anyone an idea?

>>X	case 'a': 
>>X		flags |= WRITEMODE;
>>X		if (( fd = open(name,1)) < 0 )
>>X			return((FILE *)NULL);
>>X		lseek(fd,0L,2);
>>X		break;         
 
>Append is really two attempts:
 
>	if ((fd = open(name, 1)) < 0 && (fd = creat(name, PMODE)) < 0)
>		return ((FILE *) NULL);
 
[ some stuff deleted]
The code I sent is again copied from fopen.c
 
>Do the original routines support r+, w+, and a+ modes?  These are nice

No! I'd love to see them, but haven't had time to make them.

>to have.  I'm not near a Minix machine at the moment.  Does Minix support
>open with 3 arguments?  This would make an implementation a little
>easier/cleaner.

Again. No.
 
[ small flame deleted]
 
>-- Brian Katzung  ...!spl1!laidbak!katzung


-- 
Frans Meulenbroeks        (meulenbr@cst.prl.philips.nl)
	Centre for Software Technology
	( or try: ...!mcvax!philmds!prle!cst!meulenbr)