Austin Group Defect Tracker

Aardvark Mark IV


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0001847 [1003.1(2024)/Issue8] System Interfaces Objection Error 2024-08-02 01:15 2024-09-16 17:08
Reporter philip-guenther View Status public  
Assigned To
Priority normal Resolution Accepted As Marked  
Status Interpretation Required  
Name Philip Guenther
Organization OpenBSD
User Reference
Section dlfnc.h and dladdr()
Page Number 238 and
Line Number 8391 and
Interp Status Approved
Final Accepted Text Note: 0006863
Summary 0001847: dladdr()'s second argument should be Dl_info*, not Dl_info_t*
Description The common opensource systems of Linux, FreeBSD, NetBSD, and OpenBSD all have an existing dladdr() whose second argument is Dl_info*, not Dl_info_t*.
Desired Action Require implementations to provide Dl_info as an equivalent type to its current Dl_info_t

Mark the Dl_info_t type as obsolescent, or with a future direction of removal, or whatever can be done to clean this up. ("The standard is clear, but concerns have been raised to the sponsor...")
Tags tc1-2024
Attached Files

- Relationships

-  Notes
(0006856)
geoffclare (manager)
2024-08-05 14:41

I am in favour of adding Dl_info as a synonym for Dl_info_t.

I am not in favour of deprecating Dl_info_t (with a view to removing it in Issue 9). Since Solaris 11 has specified Dl_info_t in its dladdr() man page for many years, there will be existing code which uses it. (And there may well be more code written between now and TC1 that follows the standard as published, by people unaware of this request.) I don't see a desire to "clean this up" as sufficient justification for forcing such code to change in order for it to conform to Issue 9.

I'd suggest instead that we add some application usage along these lines:
Although this standard requires Dl_info and Dl_info_t to be defined as synonyms for the same type, historically many systems only defined Dl_info and did not define Dl_info_t. Consequently, choosing to use Dl_info over Dl_info_t may provide better portability to non-conforming implementations (such as those which conform to earlier versions of this standard from before dladdr() was added but which also provide dladdr() as an extension).
(0006859)
philip-guenther (reporter)
2024-08-11 01:46

That'll increase the portability over what's there, so sure.
(0006860)
philip-guenther (reporter)
2024-08-11 01:47

(It feels like there was a process miss/failure in the alteration of the original request without call-out of the alternation in the ticket, but I don't have a magic way to catch that in the future, other than "everyone reads and puts cycles on EVERYTHING". :| oh well)
(0006863)
geoffclare (manager)
2024-08-15 15:33

Interpretation response
------------------------
The standard states that <dlfcn.h> defines Dl_info_t and does not define Dl_info, and conforming implementations must conform to this. However, concerns have been raised about this which are being referred to the sponsor.

Rationale:
-------------
There is existing application code that uses Dl_info_t and existing code that uses Dl_info. To enable both to be ported to a standard-conforming environment with minimal change, the standard should define both types.

Notes to the Editor (not part of this interpretation):
-------------------------------------------------------
After page 238 line 8393 section <dlfcn.h>, add:
The <dlfcn.h> header shall define the Dl_info type to be the same type as Dl_info_t.


On page 238 line 8409 section <dlfcn.h>, change APPLICATION USAGE from "None" to:
Although this standard requires Dl_info and Dl_info_t to be defined as synonyms for the same type, historically many systems only defined Dl_info and did not define Dl_info_t. Consequently, choosing to use Dl_info over Dl_info_t may provide better portability to non-conforming implementations (such as those which conform to earlier versions of this standard from before dladdr() was added but which also provide dladdr() as an extension).
(0006864)
agadmin (administrator)
2024-08-15 15:56

Interpretation proposed: 15 August 2024
(0006878)
agadmin (administrator)
2024-09-16 17:08

Interpretation approved: September 16 2024

- Issue History
Date Modified Username Field Change
2024-08-02 01:15 philip-guenther New Issue
2024-08-02 01:15 philip-guenther Name => Philip Guenther
2024-08-02 01:15 philip-guenther Organization => OpenBSD
2024-08-02 01:15 philip-guenther Section => dlfnc.h and dladdr()
2024-08-02 01:15 philip-guenther Page Number => 238 and
2024-08-02 01:15 philip-guenther Line Number => 8391 and
2024-08-05 14:41 geoffclare Note Added: 0006856
2024-08-11 01:46 philip-guenther Note Added: 0006859
2024-08-11 01:47 philip-guenther Note Added: 0006860
2024-08-15 15:33 geoffclare Note Added: 0006863
2024-08-15 15:34 geoffclare Interp Status => Pending
2024-08-15 15:34 geoffclare Final Accepted Text => Note: 0006863
2024-08-15 15:34 geoffclare Status New => Interpretation Required
2024-08-15 15:34 geoffclare Resolution Open => Accepted As Marked
2024-08-15 15:35 geoffclare Tag Attached: tc1-2024
2024-08-15 15:56 agadmin Interp Status Pending => Proposed
2024-08-15 15:56 agadmin Note Added: 0006864
2024-09-16 17:08 agadmin Interp Status Proposed => Approved
2024-09-16 17:08 agadmin Note Added: 0006878


Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker