Interpretation response
------------------------
The standard states the requirements for pointer types , and
conforming implementations must conform to this. However, concerns have
been raised about this which are being referred to the sponsor.

Rationale:
-------------
None.

Notes to the Editor (not part of this interpretation):
-------------------------------------------------------


After a lengthy discussion on the e-mail list based on the proposed
resolution in Note: 0000129, the committee decided to revise the text.
These changes solve:
1.  the issue initially raised in this report,
2.  the issue raised in 0000099 (which will be closed as a dup of
    this bug when this bug resolution is approved),
3.  the issue raised in 0000100 (which will be closed as a dup of
    this bug when this bug resolution is approved),
4.  some inconsistencies between the uses of the term object in this
    standard and in ISO C (as noted by Konrad in Note: 0000155 and
    Note: 0000156), and
5.  the inconsistent use of the term symbol in this standard (in the
    rest of this standard, symbol refers either to a graphic
    representation of a character or to a symbolic constant; in the
    description of dlsym(), however, symbol refers to what is known by
    the term identifier in ISO C.

This note was discussed during the August 27, 2009 conference call and
minor edits have made done in place (without creating a new note).

------------------------------------------------------------------------

Delete subclause 2.12.3 from P541, L18881-18886.

------------------------------------------------------------------------

Replace the NAME, SYNOPSIS, DESCRIPTION, RETURN VALUE, ERRORS, EXAMPLES,
and APPLICATION USAGE sections of the dlclose() descripion on P728,
L24469-24513 with:

NAME
        dlclose -- close a symbol table handle

SYNOPSIS
        #include <dlfcn.h>
        int dlclose(void *handle);

DESCRIPTION
        The dlclose() function shall inform the system that the symbol
        table handle specified by handle is no longer needed by the
        application.

        An application writer may use dlclose() to make a statement of
        intent on the part of the process, but this statemen does not
        create any requirement upon the implementation.  When the symbol
        table handle is closed, the implementation may unload the
        executable object files that were loaded by dlopen() when the
        symbol table handle was opened and those that were loaded by
        dlsym() when using the symbol table handle identified by handle.
        Once a symbol table handle has been closed, an application
        should assume that any symbols (function identifiers and data
        object identifiers) made visible using handle, are no longer
        available to the process.

        Although a dlclose() operation is not required to remove any
        functions or data objects from the address space, neither is an
        implementation prohibited from doing so.  The only restriction
        on such a removal is that no function nor data object shall be
        removed to which references have been relocated, until or unless
        all such references are removed.  For instance, an executable
        object file that had been loaded with a dlopen() operation
        specifying the RTLD_GLOBAL flag might provide a target for
        dynamic relocations performed in the processing of other
        relocatable objects--in such environments, an application may
        assume that no relocation, once made, shall be undone or remade
        unless the executable object file containing the relocated
        object has itself been removed.

RETURN VALUE
        If the referenced symbol table handle was successfully closed,
        dlclose() shall return 0.  If handle does not refer to an open
        symbol table handle or if the symbol table handle could not be
        closed, dlclose() shall return a non-zero value.  More detailed
        diagnostic information shall be available through dlerror().

ERRORS
        No errors are defined.

EXAMPLES
        The following example illustrates use of dlopen() and dlclose():

        #include <dlfcn.h>
        int     eret;
        void    *mylib;
        ...
        /* Open a dynamic library and then close it ... */
        mylib = dlopen("mylib.so", RTLD_LOCAL | RTLD_LAZY);
        ...
        eret = dlclose(mylib);
        ...

APPLICATION USAGE
        A conforming application should employ a symbol table handle
        returned from a dlopen() invocation only within a given scope
        bracketed by a dlopen() operation and the corresponding
        dlclose() operation.  Implementations are free to use reference
        counting or other techniques such that multiple calls to
        dlopen() referencing the same executable object file may return
        a pointer to the same data object as the symbol table handle.
        Implementations are also free to reuse a handle.  For these
        reasons, the value of a handle must be treated as an opaque data
        type by the application, used only in calls to dlsym() and
        dlclose().

------------------------------------------------------------------------

Replace the NAME, SYNOPSIS, DESCRIPTION, and RETURN VALUE sections of
the dlopen() descripion on P732-733, L24575-24666:

NAME
        dlopen -- open a symbol table handle

SYNOPSIS
        #include <dlfcn.h>
        void *dlopen(const char *file, int mode);

DESCRIPTION
        The dlopen() function shall make the symbols (function
        identifiers and data object identifiers) in the executable
        object file specified by file available to the calling program.
        The class of executable object files eligible for this operation
        and the manner of their construction are implementation-defined,
        though typically such files are shared libraries or programs.
        Implementations may permit the construction of embedded
        dependencies in executable object files.  In such cases, a
        dlopen() operation shall load those dependencies in addition to
        the executable object file specified by file.  Implementations
        may also impose specific constraints on the construction of
        programs that can employ dlopen() and its related services.

        A successful dlopen() shall return a symbol table handle which
        the caller may use on subsequent calls to dlsym() and dlclose().
        The value of this symbol table handle should not be interpreted
        in any way by the caller.

        The file argument is used to construct a pathname to the
        executable object file.  If file contains a <slash> character,
        the file argument is used as the pathname for the file.
        Otherwise, file is used in an implementation-defined manner to
        yield a pathname.

        If file is a null pointer, dlopen() shall return a global symbol
        table handle for the currently running process image.  This
        symbol table handle shall provide access to the symbols from an
        ordered set of executable object files consisting of the
        original program image file, any executable object files loaded
        at program start-up as specified by that process image file (for
        example, shared libraries), and the set of executable object
        files loaded using dlopen() operations with the RTLD_GLOBAL
        flag.  As the latter set of executable object files can change
        during execution, the set of symbols made available by this
        symbol table handle can also change dynamically.

        Only a single copy of an executable object file shall be brought
        into the address space, even if dlopen() is invoked multiple
        times in reference to the executable object file, and even if
        different pathnames are used to reference the executable object
        file.

        The mode parameter describes how dlopen() shall operate upon
        file with respect to the processing of relocations and the scope
        of visibility of the symbols provided within file.  When an
        executable object file is brought into the address space of a
        process, it may contain references to symbols whose addresses
        are not known until the executable object file is loaded.
        These references shall be relocated before the symbols can be
        accessed.  The mode parameter governs when these relocations
        take place and may have the following values:

        RTLD_LAZY       Relocations shall be performed at an
                        implementation-defined time, ranging from the
                        time of the dlopen() call until the first
                        reference to a given symbol occurs.  Specifying
                        RTLD_LAZY should improve performance on
                        implementations supporting dynamic symbol
                        binding since a process might not reference all
                        of the symbols in an executable object file.
                        And, for systems supporting dynamic symbol
                        resolution for normal process execution, this
                        behavior mimics the normal handling of process
                        execution.

        RTLD_NOW        All necessary relocations shall be performed
                        when the executable object file is first loaded.
                        This may waste some processing if relocations
                        are performed for symbols that are never
                        referenced.  This behavior may be useful for
                        applications that need to know that all symbols
                        referenced during execution will be available
                        before dlopen() returns.

        Any executable object file loaded by dlopen() that requires
        relocations against global symbols can reference the symbols in
        the original process image file, any executable object files
        loaded at program start-up, from the initial process image
        itself, from any other executable object file included in the
        same dlopen() invocation, and any executable object files that
        were loaded in any dlopen() invocation and which specified the
        RTLD_GLOBAL flag.  To determine the scope of visibility for the
        symbols loaded with a dlopen() invocation, the mode parameter
        should be a bitwise-inclusive OR with one of the following
        values:

        RTLD_GLOBAL     The executable object file's symbols shall be
                        made available for relocation processing of any
                        other executable object file.  In addition,
                        symbol lookup using dlopen(NULL, mode) and an
                        associated dlsym() allows executable object
                        files loaded with this mode to be searched.

        RTLD_LOCAL      The executable object file's symbols shall not
                        be made available for relocation processing of
                        any other executable object file.

        If neither RTLD_GLOBAL nor RTLD_LOCAL are specified, the default
        behavior is unspecified.

        If an executable object file is specified in multiple dlopen()
        invocations, mode is interpreted at each invocation.
        If RTLD_NOW has been specified, all relocations
        shall have been completed rendering further RTLD_NOW operations
        redundant and any further RTLD_LAZY operations irrelevant.
    If RTLD_GLOBAL has been specified, the executable object file
    shall maintain the RTLD_GLOBAL status regardless of any previous
    or future specification of RTLD_LOCAL, as long as the executable
    object file remains in the address space (see dlclose()).

        Symbols introduced into the process image through calls to
        dlopen() may be used in relocation activities.  Symbols so
        introduced may duplicate symbols already defined by the program
        or previous dlopen() operations.  To resolve the ambiguities
        such a situation might present, the resolution of a symbol
        reference to symbol definition is based on a symbol resolution
        order.  Two such resolution orders are defined: load order and
        dependency order.  Load order establishes an ordering among
        symbol definitions, such that the first definition loaded
        (including definitions from the process image file and any
        dependent executable object files loaded with it) has priority
        over executable object files added later (by dlopen()).  Load
        ordering is used in relocation processing.  Dependency ordering
        uses a breadth-first order starting with a given executable
        object file, then all of its dependencies, then any dependents
        of those, iterating until all dependencies are satisfied.  With
        the exception of the global symbol table handle obtained via a
        dlopen() operation with a null pointer as the file argument,
        dependency ordering is used by the dlsym() function.  Load
        ordering is used in dlsym() operations upon the global symbol
        table handle.

        When an executable object file is first made accessible via
        dlopen(), it and its dependent executable object files are added
        in dependency order.  Once all the executable object files are
        added, relocations are performed using load order.  Note that if
        an executable object file or its dependencies had been
        previously loaded, the load and dependency orders may yield
        different resolutions.

        The symbols introduced by dlopen() operations and available
        through dlsym() are at a minimum those which are exported as
        identifiers of global scope by the executable object file.
        Typically such identifiers shall be those that were specified in
        (for example) C source code as having extern linkage.  The
        precise manner in which an implementation constructs the set of
        exported symbols for an executable object file is
        implementation-defined.

RETURN VALUE
        Upon successful completion, dlopen() shall return a symbol table
        handle.  If file cannot be found, cannot be opened for reading,
        is not of an appropriate executable object file format for
        processing by dlopen(), or if an error occurs during the process
        of loading file or relocating its symbolic references, dlopen()
    shall return a null pointer.  More detailed diagnostic
    information shall be available through dlerror().

------------------------------------------------------------------------

Replace the NAME, SYNOPSIS, DESCRIPTION, RETURN VALUE, ERRORS, EXAMPLES,
APPLICATION USAGE, and RATIONALE sections of the dlsym() descripion on
P735-736, L24689-24748 with:

NAME
        dlsym -- get the address of a symbol from a symbol table handle

SYNOPSIS
        #include <dlfcn.h>
        void *dlsym(void *restrict handle, const char *restrict name);

DESCRIPTION
        The dlsym() function shall obtain the address of a symbol (a
        function identifier or a data object identifier) defined in the
        symbol table identified by the handle argument.  The handle
        argument is a symbol table handle returned from a call to
        dlopen() (and which has not since been released by a call to
        dlclose()), and name is the symbol's name as a character
        string.  The return value from dlsym(), cast to a pointer to the
        type of the named symbol, can be used to call (in the case of a
        function) or access the contents of (in the case of a data
        object) the named symbol.

        The dlsym() function shall search for the named symbol in
        the symbol table referenced by handle.  If the symbol table was
        created with lazy loading (see RTLD_LAZY in dlopen()), load
        ordering shall be used in dlsym() operations to relocate
        executable object files needed to resolve the symbol.  The
        symbol resolution algorithm used shall be dependency order
        as described in dlopen().

        The RTLD_DEFAULT and RTLD_NEXT symbolic constants (which may be
        defined in <dlfcn.h>) are reserved for future use as special
        values that applications may be allowed to use for handle.

RETURN VALUE
        Upon successful completion, if name names a function identifier,
        dlsym() shall return the address of the function converted from
        type pointer to function to type pointer to void; otherwise
        dlsym() shall return the address of the data object associated
        with the data object identfier named by name converted from a
        pointer to the type of the data object to a pointer to void.  If
        handle does not refer to a valid symbol table handle or if the
        symbol named by name cannot be found in the symbol table
    associated with handle, dlsym() shall return a null pointer.
    More detailed diagnostic information shall be available through
    dlerror().

ERRORS
        No errors are defined.

EXAMPLES
        The following example shows how dlopen() and dlsym() can be used
        to access either a function or a data object.  For simplicity,
        error checking has been omitted.

        void    *handle;
        int     (*fptr)(int),
                *iptr,
                result;

        /* open the needed symbol table */
        handle = dlopen("/usr/home/me/libfoo.so", RTLD_LOCAL | RTLD_LAZY);

        /* find the address of the function my_function */
        fptr = (int (*)(int))dlsym(handle, "my_function");

        /* find the address of the data object my_object */
        iptr = (int *)dlsym(handle, "my_OBJ");

        /* invoke my_function, passing the value of my_OBJ as the parameter */
        result = (*fptr)(*iptr);

APPLICATION USAGE
        The following special purpose values for handle are reserved for
        future use and have the indicated meanings:

        RTLD_DEFAULT    The identifier lookup happens in the normal
                        global scope; that is, a search for a identifier
                        using handle would find the same definition as a
                        direct use of this identifier in the program
                        code.

        RTLD_NEXT       Specifies the next executable object file after
                        this one that defines name.  This one refers to
                        the executable object file containing the
                        invocation of dlsym().  The next executable
                        object file is the one found upon the
                        application of a load order symbol resolution
                        algorithm (see dlopen()).  The next symbol is
                        either one of global scope (because it was
                        introduced as part of the original process image
                        or because it was added with a dlopen()
                        operation including the RTLD_GLOBAL flag), or is
                        in an executable object file that was included
                        in the same dlopen() operation that loaded this
                        one.

                        The RTLD_NEXT flag is useful to navigate an
                        intentionally created hierarchy of
                        multiply-defined symbols created through
                        interposition.  For example, if a program wished
                        to create an implementation of malloc() that
                        embedded some statistics gathering about memory
                        allocations, such an implementation could use
                        the real malloc() definition to perform the
                        memory allocation--and itself only embed the
                        necessary logic to implement the statistics
                        gathering function.

        Note that conversion from a void * pointer to a function pointer
        as in:

                fptr = (int (*)(int))dlsym(handle, "my_function");

        is not defined by the ISO C Standard.  This standard requires
        this conversion to work correctly on conforming implementations.

RATIONALE
        None.

------------------------------------------------------------------------