Date: Sat, 11 Oct 1997 23:59:53 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: mdean@best.com (mdean) Cc: tlambert@primenet.com, freebsd-hackers@FreeBSD.ORG Subject: Re: Is this a bug, or just a feature. Message-ID: <199710112359.QAA11116@usr07.primenet.com> In-Reply-To: <Pine.SGI.3.95.971011154726.27647A-100000@shellx.best.com> from "mdean" at Oct 11, 97 03:54:46 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> Sorry, I was confused I meant
> open ("/dev/fd0", O_RDWR|O_WRONLY, 0);
> which gives a valid descriptor when executed(and a disk is in the drive)
Yes. A descriptor with a flag value of "1" (0x0002|0x0001) == 3... and
a file flags value of 4.
I don't understand how this could be "caught", since the value of
manifest constant arithmatic is constant, and therefore computed
at compile time.
The point of these values is historical compatability. Many older programs
do not use defined manifest values, and instead use constant 0, 1, or 2.
Once in the open code in the kernel, the FFLAGS() macro is called on
the value.
The point of masking at 3 is that the values 0, 1, 2 won't overflow
two bits if you add one: the become 1, 2, and 3. The correspond to
FREAD, FWRITE, and FREAD|FWRITE, respectively.
If you give a constant value of 3, then you overflow to 4. Basically,
O_NONBLOCK.
> O_RDWR+O_WRONLY = O_ACCMODE which I am at least using to mask the oflags
> and running the remaining bits through a switch statement checking for
> O_RDONLY , O_RDWR, O_WRONLY (for this particular device these actually
> matter, I am using them to determine the direction of the port for some
> control regs) so at the end of the switch i have a default: return (EPERM);
> since having O_RDONLY and O_RDWR set at the same time is meaningless (they
> are mutually exclusive for me). I was just suprised this isn't caught
> before it gets passed to the driver.
Because this is effectively a lame bit encoding for open modes to bits 0
and 1 of the flags, I suppose you could mask the value and check for a
constant 3, and fail the open. This seems to be overkill to me, since
you are not allowed to pass in any of O_RDONLY, O_WRONLY, and O_RDWR
combinations by definition of the interface.
In your driver, you will be using FREAD/FWRITE bit tests, anyway. The
worst effect this should possibly have is badly coded programs that violate
the interface definition will send down "O_NONBLOCK" for file flags and set
neither FREAD or FWRITE (which you can detect by anding flags with three
to test for non-zero).
> > > Shouldn't it be an error to call open("/dev/fd0", RD_ONLY|WR_ONLY,0)?
You mean "to pass a 3 as the flags value to open"? I don't think it's
very useful, but it's not an error, I don't think. I suppose you could
still use the fd for an fchdir, in fact. I could see passing a 3 to get
a 4 and using an fcntl to unset non-blocking I/O... there could be a
number of reasons you'd want a decriptor that referenced an object, yet
could not be read or written.
Terry Lambert
terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199710112359.QAA11116>