View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001644 | 1003.1(2016/18)/Issue7+TC2 | System Interfaces | public | 2023-03-22 09:52 | 2024-06-11 09:07 |
| Reporter | bastien | Assigned To | |||
| Priority | normal | Severity | Comment | Type | Enhancement Request |
| Status | Closed | Resolution | Accepted As Marked | ||
| Name | Bastien Roucaries | ||||
| Organization | debian | ||||
| User Reference | |||||
| Section | dlsym - get the address of a symbol from a symbol table handle | ||||
| Page Number | Application usage | ||||
| Line Number | all | ||||
| Interp Status | --- | ||||
| Final Accepted Text | 0001644:0006272 | ||||
| Summary | 0001644: void * to function pointer is described in annex J of C standard (informative). | ||||
| Description | Standard say 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. J.5.7 Function pointer casts 1 A pointer to an object or to void may be cast to a pointer to a function, allowing data to be invoked as a function (6.5.4). 2 A pointer to a function may be cast to a pointer to an object or to void, allowing a function to be inspected or modified (for example, by a debugger) (6.5.4). It is not true, this behavior is described in J - Portability issues, §J.5.7 Function pointer cast (informative) | ||||
| Desired Action | Add a note that POSIX conforment compiler should implement §J.5.7 Function pointer casts 1 A pointer to an object or to void may be cast to a pointer to a function, allowing data to be invoked as a function (6.5.4). 2 A pointer to a function may be cast to a pointer to an object or to void, allowing a function to be inspected or modified (for example, by a debugger) (6.5.4). | ||||
| Tags | applied_after_i8d3, tc3-2008 | ||||
|
|
Requiring §J.5.7 is overkill. Requiring support for calling into data, or examining code as data, sounds like asking for all sorts of security issues. All that is needed to have a working dlsym() is that a void* pointer returned by a dlsym() call that names a function, and no other void* pointer, can be safely converted to the correct function type and called. This can be achieved without opening up the entire address space for accessing data as code and code as data, as would be required by §J.5.7. |
|
|
@wlerch I perfectly understand your remark, nevertheless could we reformulate like this: the returned pointer of dlsym() may be cast to a pointer to a function, allowing data to be invoked as a function. Posix system should respect §J.5.7.1 of ISO C standard for the pointer returned by dlsym() I want in fact to use the same wording between C standard and POSIX. |
|
|
Why? The same wording would mean the same requirements, wouldn't it? Why would you want to impose unnecessary requirements that lead to potential security risks? dlsym does not need to allow data to be invoked as a function. The pointer returned by it does not need to point to data. The only requirement that is necessary is that it can be converted to a pointer to function, resulting in a pointer that can be used to call the function. |
|
|
Ok understood your point may be: a void* pointer returned by a dlsym() call that names a function, can be safely converted to the correct function type and called. |
|
|
I like the text suggested in 0000074
But it should say "converted", not "cast". And it could just say that result of the conversion will point to the object or function, and let C define what such a pointer can then be used for. I am not a big fan of the existing text saying that "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". It's not the job of POSIX to specify how an implementation of dlsym() must produce the void* value to return, and it makes particularly little sense to insist that it must use a conversion that has undefined behaviour in standard C. Saying later that a different conversion, from the void* pointer to a function pointer, is required to "work correctly" does not really fix that. |
|
|
> I like the text suggested in 0000074 > > dlsym()'s return value, cast to a pointer to the type of the symbol, may be > used to call (in case of a function) respectively access (in case of a [data] > object) the symbol. This was added to the standard, with minor wording changes, at line 25417: 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. > But it should say "converted", not "cast". I suspect the text says "cast" for the thing the application does because trying to do the conversion without a cast would cause C compilers to produce a diagnostic. (It can just say "converted" for the thing the implementation does because how it does that is internal implementation detail.) |
|
|
Ah, right, in the Description, somehow I didn't look there, thanks. :) Regarding "cast", no, a conversion without a cast would not necessarily produce a diagnostic -- a diagnostic is not required if the target type is a pointer to an object type. If the text said "converted", it would be up to the reader to figure out from the rules of C when a cast is necessary to prevent a diagnostic; but since it says "cast", it might make a pedantic reader wonder if it means to say that an explicit cast is indeed required, even in cases where an assignment without a cast would be just as good as far as standard rules of C are concerned. I suspect the real reason it says "cast" is because a lot of people refer to any conversion as a "cast" and a cast as an "explicit cast". I think it's common enough to be tolerable in less formal contexts, but in a formal document such as this it would be better to use terms defined in the C standard consistently with how they're defined there. |
|
|
> a diagnostic is not required if the target type is a pointer to an object type Of course you're right. In my mind I was replying in the context of the named symbol being a function, but I neglected to state that condition. > I suspect the real reason it says "cast" is because a lot of people refer to any conversion as a "cast" and a cast as an "explicit cast". If that were the reason, I would expect the related text in RETURN VALUE to say "cast" as well. |
|
|
> In my mind I was replying in the context of the named symbol being a function, but I neglected to state that condition. But my point is that the text in the standard does not state that condition either. Yes, trying to do the conversion without a cast would sometimes cause C compilers to produce a diagnostic, but other times it would not, so that does not sound like a good reason to have a wording that can be interpreted as implying that a cast is always required. > > I suspect the real reason it says "cast" is because a lot of people refer to any conversion as a "cast" and a cast as an "explicit cast". > If that were the reason, I would expect the related text in RETURN VALUE to say "cast" as well. The text that says "cast" was added after the text in RETURN VALUE was already there, wasn't it? It wouldn't make a lot of sense to adjust the existing text that was already using the more accurate "conversion" to use the less accurate "cast" instead, just because new text using "cast" was being added. I think would have been better to adjust the new text to use the more accurate "conversion" and be more consistent with the existing text, but if it was done by someone who thought of "cast" as a synonym for "conversion", I can understand why they would not have bothered. Anyway, investigating the reasons and motives behind the existing text is probably not quite as important as figuring out whether the existing text is sufficient or deserves some changes, is it?... |
|
|
> The text that says "cast" was added after the text in RETURN VALUE was already there, wasn't it? No, all of the wording about casting and conversion is from bug 0000074. > Anyway, investigating the reasons and motives behind the existing text is > probably not quite as important as figuring out whether the existing text is > sufficient or deserves some changes Indeed. |
|
|
On page 746 line 25418 section dlsym(), change:cast to a pointer to the type of the named symbolto: converted from type pointer to void to a pointer to the type of the named symbol |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2023-03-22 09:52 | bastien | New Issue | |
| 2023-03-22 09:52 | bastien | Name | => Bastien Roucaries |
| 2023-03-22 09:52 | bastien | Organization | => debian |
| 2023-03-22 09:52 | bastien | Section | => dlsym - get the address of a symbol from a symbol table handle |
| 2023-03-22 09:52 | bastien | Page Number | => Application usage |
| 2023-03-22 09:52 | bastien | Line Number | => all |
| 2023-03-22 13:24 | wlerch | Note Added: 0006220 | |
| 2023-03-22 15:15 | bastien | Note Added: 0006222 | |
| 2023-03-22 15:43 | wlerch | Note Added: 0006223 | |
| 2023-03-22 16:10 | bastien | Note Added: 0006224 | |
| 2023-03-22 18:43 | wlerch | Note Added: 0006225 | |
| 2023-03-23 09:39 | geoffclare | Note Added: 0006229 | |
| 2023-03-23 13:47 | wlerch | Note Added: 0006232 | |
| 2023-03-23 13:52 | wlerch | Note Edited: 0006232 | |
| 2023-03-23 14:02 | geoffclare | Note Added: 0006233 | |
| 2023-03-23 14:45 | wlerch | Note Added: 0006234 | |
| 2023-03-23 16:42 | geoffclare | Note Added: 0006235 | |
| 2023-03-23 16:42 | geoffclare | Relationship added | related to 0000074 |
| 2023-04-27 15:31 | geoffclare | Note Added: 0006272 | |
| 2023-04-27 15:32 | geoffclare | Interp Status | => --- |
| 2023-04-27 15:32 | geoffclare | Final Accepted Text | => 0001644:0006272 |
| 2023-04-27 15:32 | geoffclare | Status | New => Resolved |
| 2023-04-27 15:32 | geoffclare | Resolution | Open => Accepted As Marked |
| 2023-04-27 15:32 | geoffclare | Tag Attached: tc3-2008 | |
| 2023-06-13 10:48 | geoffclare | Status | Resolved => Applied |
| 2023-06-13 10:48 | geoffclare | Tag Attached: applied_after_i8d3 | |
| 2024-06-11 09:07 | agadmin | Status | Applied => Closed |
