Project

General

Profile

Bug #2404

mmap.s inconsistency

Added by Igor Pashev over 8 years ago. Updated over 8 years ago.

Status:
Feedback
Priority:
Normal
Assignee:
-
Category:
-
Start date:
2012-03-13
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage
Gerrit CR:

Description

usr/src/lib/libc/common/sys/mmap.s

Snippet in question (mmap.s):

#if !defined(_LARGEFILE_SOURCE)
    ANSI_PRAGMA_WEAK(mmap,function)
#else
    ANSI_PRAGMA_WEAK(mmap64,function)
#endif

#include "SYS.h" 
#include <sys/mman.h>        /* Need _MAP_NEW definition     */

#if !defined(_LARGEFILE_SOURCE)

Those two checks for _LARGEFILE_SOURCE mayby inconsistent, because
sys/mman.h includes sys/feature_tests.h and _LARGEFILE_SOURCE can be redefined there (sys/feature_tests.h):

#if    (!defined(_STRICT_STDC) && !defined(__XOPEN_OR_POSIX)) || \
        defined(_KERNEL) || defined(_KMEMUSER) || \
        defined(__EXTENSIONS__)
#undef    _LARGEFILE64_SOURCE
#define    _LARGEFILE64_SOURCE    1
#endif
#if    _LARGEFILE64_SOURCE - 0 == 1
#undef    _LARGEFILE_SOURCE
#define    _LARGEFILE_SOURCE    1
#endif

History

#1

Updated by Rich Lowe over 8 years ago

  • Status changed from New to Feedback

As best as I can tell, this code is just bad.

The largefile environment when compiling libc shouldn't matter, what's important is the environment of the process actually using libc (and which is set up by the various redefine_extname, etc, tricks we have).

I'm pretty sure that this should be unifdef'd and the true side of the conditions removed, since by any reading I have, they cannot possibly work (or at least, work in a way which is reasonable).

#2

Updated by Igor Pashev over 8 years ago

Shouldn't it be splitted into two parts: mmap.s and mmap64.s? AFAIK both mmap and mmap64 should exists in libc.

#3

Updated by Rich Lowe over 8 years ago

I'd vastly prefer that, yes.

Also available in: Atom PDF