This is the mail archive of the
cygwin-developers
mailing list for the Cygwin project.
Re: Broken autoconf mmap test
On Mar 24 13:59, Eric Blake wrote:
> On 03/24/2011 01:13 PM, Larry Hall (Cygwin Developers) wrote:
> >> And, is the autoconf test perhaps the only client for this solution
> >> since no sensible application will read and write bytes beyond EOF? If
> >> so, it's kind of sad that an autoconf test will result in lots of
> >> application not using mmap, even though none of them actually uses the
> >> map beyond EOF.
> >>
> >> So, whatever we do in Cygwin's mmap, it's either rock or hard place,
> >> as far as I can see
> >
> > I do think it's worthwhile to examine the "why" before making changes here.
> > If the main (only?) gain here is to appease autoconf, is there a way we can
> > "cheat" at this?
Well, just if that has gone lost, there's no reason to cheat anything on
32-bit Windows systems since Cygwin works POSIXy enough there.
As for 64-bit systems...
In theory, the problem wouldn't show up if we revert the pagesize from
64K to 4K. But this would re-introduce other problems, as the inability
to allocate all the available address space via mmap.
Other than that, how do you know that this is *the* autoconf test? Maybe
like this:
If the file to mmap is called "conftest.txt", and if its len is 1 byte,
and if it has been opened with PROT_READ | PROT_WRITE access, and if
the flags are set to MAP_SHARED.
And if that all is the case *and* we're running on a 64-bit system, just
return an anonymous mapping of 64K. With this mapping the autoconf test
succeeds.
> > Getting autoconf'd packages to use mmap is a good thing
> > but it does sound to me like it needs to be way easier for Cygwin to do
> > this right, we need a specific work-around to target autoconf checks, or we
> > shouldn't bother (for now).
>
> I'm perfectly fine with a patch to autoconf that weakens the semantics
> of the autoconf test (and/or splits it into two tests, with the old name
> being weaker and only the new name requiring full POSIX compliance),
> along with autoconf documentation about the portability restrictions
> where a portable program cannot do the corner case guaranteed by POSIX,
> if we can be reasonably sure that this really is a corner case unlikely
> to hit real programs.
That may be a good thing, but only helps for projects using the latest
autoconf, of course.
If you guys think that cheating for autoconf on 64 bit systems is a good
idea, I'm willing to implement it.
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
Red Hat