Sender:	rich AT phekda DOT freeserve DOT co DOT uk
Message-ID:	<3E6B2DB0.D315AA68@phekda.freeserve.co.uk>
Date:	Sun, 09 Mar 2003 12:04:00 +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:	Eli Zaretskii <eliz AT elta DOT co DOT il>
CC:	dj AT delorie DOT com, djgpp-workers AT delorie DOT com
Subject:	Re: New POSIX: pwrite, revision 2 [PATCH]
References:	<E18roPd-0000Rn-00 AT phekda DOT freeserve DOT co DOT uk> <200303090033 DOT h290XfN11047 AT envy DOT delorie DOT com> <8632-Sun09Mar2003061943+0200-eliz AT elta DOT co DOT il>
Reply-To:	djgpp-workers AT delorie DOT com

Hello.

Eli Zaretskii wrote:
> 
> > Date: Sat, 8 Mar 2003 19:33:41 -0500
> > From: DJ Delorie <dj AT delorie DOT com>
> >
> > I still think this is the wrong test.  FILE_DESC_PIPE is set by the
> > pipe() call, but that call *always* uses regular files.  We should be
> > testing the "is a device" bit from int 21/44/00
> 
> Yes, I agree: we should fail the function for character devices.

Why should it fail for character devices?

If I've understood the draft of new POSIX correctly, pwrite is allowed on
devices that do not support seeks. From the section describing write on the
write & pwrite page, it says:

"On a file not capable of seeking, writing shall always take place starting at
the current position. The value of a file offset associated with such a device
is undefined."

It does not say in the pwrite section that pwrite is not allowed on devices
that do not support seeks.

The behaviour of lseek on devices that don't support seeking is
implementation-defined. It seems to work fine on DJGPP with stdout, stderr.

My interpretation is that:

    char buf[] = "hello mum";
    pwrite(fileno(stdout), buf, strlen(buf), 1000);

is perfectly legitimate when stdout is not redirected. (I think we've
established it's legitimate when redirected too, since that goes through
regular files.)

This compares with the case for pipes, where the page says in the section
about how pwrite can fail:

"The pwrite( ) function shall fail and the file pointer remain unchanged if:

[EINVAL] The offset argument is invalid. The value is negative.
[ESPIPE] fildes is associated with a pipe or FIFO.

- Raw text -