Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT sourceware DOT cygnus DOT com>
List-Archive: <http://sourceware.cygnus.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT sourceware DOT cygnus DOT com>
List-Help: <mailto:cygwin-developers-help AT sourceware DOT cygnus DOT com>, <http://sourceware.cygnus.com/ml/#faqs>
Sender: cygwin-developers-owner AT sourceware DOT cygnus DOT com
Delivered-To: mailing list cygwin-developers AT sourceware DOT cygnus DOT com
Message-ID: <38E89EB5.65FC1A41@vinschen.de>
Date: Mon, 03 Apr 2000 15:37:57 +0200
From: Corinna Vinschen <corinna AT vinschen DOT de>
Reply-To: cygdev <cygwin-developers AT sourceware DOT cygnus DOT com>
X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.13 i686)
X-Accept-Language: de, en
MIME-Version: 1.0
To: cygwin-developers AT sourceware DOT cygnus DOT com
Subject: Re: Permission denied with makeinfo from texinfo-4.0
References: <20000402204634 DOT D23469 AT cygnus DOT com> <200004030110 DOT UAA11749 AT hp2 DOT xraylith DOT wisc DOT edu> <20000402212045 DOT A24086 AT cygnus DOT com> <20000402221700 DOT A25094 AT cygnus DOT com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Chris Faylor wrote:
> 
> On Sun, Apr 02, 2000 at 09:20:45PM -0400, Chris Faylor wrote:
> >I can't see an easy fix for this behavior other than to detect an
> >ERROR_ACCESS_DENIED in _read and then attempt to see if we're at EOF.
> >In this case, we'd have to figure out how many bytes are actually left
> >in the file and just pass that many to ReadFile.  That could still fail,
> >of course, but in that case, it would be a UNIX-type failure.
> 
> On second thought, this isn't feasible either.  We actually have to figure
> out how many bytes are actually valid (x) in the buffer and how many bytes
> would be read in (y).  If y <= x then the read should succeed.
> 
> Corinna, do you want to take a shot at fixing this?  I think the correct
> place to do this is probably in fhandler_disk_file::read since you can't
> really determine the number of bytes remaining anywhere else, can you?
> 
> Maybe to be safe we need a new fhandler method which can be triggered to
> restart a read in the above scenario.  So it would be something like:
> [...]

Should be no problem to do so, but I still wonder why this should be
needed. I have checked this out on my linux box (2.2.13 kernel,
glibc-2):

=== SNIP ===
#include <sys/types.h> etcetera...
...
int
main(int argc, char** argv)
{
  int fd;
  char buf1[64000];
  ssize_t bytes;

  if ((fd = open (argv[1] ? argv[1] : argv[0], O_RDONLY)) < 0)
    return 0;
  lseek (fd, (off_t) 0, SEEK_END);
  bytes = read (fd, buf1 + 64000, 40000);
  printf ("read: %d, err: %d, %s\n", bytes, errno, strerror(errno));
  close (fd);
  return 0;
}
=== SNAP ===

and the message is

read: -1, err: 14, Bad address       <=== EFAULT!

as it's currently under cygwin, too, and it _is_ an UNIX-style error.
This is documented in the linux read(2) man page as well.

So, if this behaviour is the same in a "reference os", where is
the problem??? Well, uhm, I have no copy of POSIX, obviously...

Corinna