A NOTE has been added to this issue. 
====================================================================== 
https://austingroupbugs.net/view.php?id=1644 
====================================================================== 
Reported By:                bastien
Assigned To:                
====================================================================== 
Project:                    1003.1(2016/18)/Issue7+TC2
Issue ID:                   1644
Category:                   System Interfaces
Type:                       Enhancement Request
Severity:                   Comment
Priority:                   normal
Status:                     New
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:         
====================================================================== 
Date Submitted:             2023-03-22 09:52 UTC
Last Modified:              2023-03-23 14:45 UTC
====================================================================== 
Summary:                    void * to function pointer is described in annex J
of C standard (informative).
====================================================================== 

---------------------------------------------------------------------- 
 (0006234) wlerch (reporter) - 2023-03-23 14:45
 https://austingroupbugs.net/view.php?id=1644#c6234 
---------------------------------------------------------------------- 
> 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
<i>sometimes</i> 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 <i>always</i> 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?... 

Issue History 
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                          
======================================================================


  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group

Reply via email to