Broken autoconf mmap test

Corinna Vinschen corinna-cygwin@cygwin.com
Fri Mar 25 09:34:00 GMT 2011


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



More information about the Cygwin-developers mailing list