bug-autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: test for restrict fails with MS compiler


From: Jerker Bäck
Subject: RE: test for restrict fails with MS compiler
Date: Sun, 22 Jul 2007 13:33:40 +0200

In Interix SDK docs about mmap, quote:

##################
MAP_FIXED 
The pointer returned by the function must be equal to addr. Normally, the
returned pointer is derived from the addr but does not have to be identical.
This is the least portable way of coding with the function.
...
[EINVAL]
The off (or the addr argument, if MAP_FIXED was specified), was not a
multiple of the page size (as returned by sysconf (2)) or was otherwise
invalid; or flags was invalid (neither MAP_PRIVATE nor MAP_SHARED was set).

##################
I tried any combination of mmap to get MAP_FIXED to succeed => errno =
EINVAL. I think the developers tried a way to implement this once for NT BSD
POSIX, but it's now broken. It could be a rest from the first implementation
from early 90ths.

The test:
pagesize = getpagesize(); => 65536
...
data2 = (char *) malloc (2 * pagesize);
...
data2 += (pagesize - ((long int) data2 & (pagesize - 1))) & (pagesize - 1);
=> data2 += 41776
=> not a multiple of the page size
...
if (data2 != mmap (data2, pagesize, PROT_READ | PROT_WRITE,
    MAP_PRIVATE | MAP_FIXED, fd, 0L))
    return 1;
=> errno = EINVAL

I don't understand this really. data2 is already allocated, pointing + 41776
bytes into the buffer and are supposed to be equal to the address of a
memory mapped file (pointing to fd) allocated here. How can this be allowed?
Who owns the memory at this address? What happens if we free data2? (Sorry
if you feel I'm unix illiterate, but this seems strange).

> If your program does not make use of mmap(MAP_FIXED), then I assume
> that you could get away with AC_CHECK_FUNC([mmap]) rather than using
> AC_FUNC_MMAP.  See the manual on details of this macro.

Yes, but this test is the one commonly used to test for memory mapped files
support in GNU utils.

Cheers, Jerker





reply via email to

[Prev in Thread] Current Thread [Next in Thread]