Sender: rich AT phekda DOT freeserve DOT co DOT uk
Message-ID: <3E2C0B37.4A3E5973@phekda.freeserve.co.uk>
Date: Mon, 20 Jan 2003 14:44:07 +0000
From: Richard Dawe <rich AT phekda DOT freeserve DOT co DOT uk>
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.2.23 i586)
X-Accept-Language: de,fr
MIME-Version: 1.0
To: djgpp-workers AT delorie DOT com
Subject: Re: _createnew
References: <200301201208 DOT NAA02824 AT lws256 DOT lu DOT erisoft DOT se>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com

Hello.

Martin Stromberg wrote:
[snip]
> Buuuuut, consider that some application can use _creatnew() for
> creating a lock file. In that case O_RDONLY might make sense(1). With
> that workaround some other process might be able to open the file in
> between _creatnew()'s closing and reopening.

If you are opening a lock file, do you care where it actually opens it
read-only or not? AFAICS you are either:

* just creating the file ("touch lockfile") and don't care whether or not you
can write to it;

* or you want to write to it.

> Anyway it's DOZE we're talking about so that scenario doesn't make
> much sense, but I've heard that our libc is used in other places as
> well.

I'm curious. Where?
 
> (1) Personally I think if you try to create a file with O_RDONLY, you
> don't know what you're doing. How about this for a different
> implementation: if you call _creatnew() without some write permission,
> fail the call.

That seems OK to me. Since it ignores what flags you tell it at the moment, it
could be useful for finding bugs in programs that expect the flags to be
honoured.

OTOH if this isn't causing problems, is there any point changing it?

Bye, Rich =]

-- 
Richard Dawe [ http://www.phekda.freeserve.co.uk/richdawe/ ]