verifying file ownership with dlopen()
in [Unix Programming]
|
From: Ersek, Laszlo on 6 May 2010 22:08 On Thu, 6 May 2010, William Ahern wrote: [snip] > There can be no conversion from a void or object pointer to a function > pointer. AFAICT the ISO C standard doesn't prohibit this for any and all derivate standards. It simply doesn't define this kind of conversion. Hereby I'll appeal to authority: see [0]. (For the "authority" part, see [1], [2], [3].) > Query: does the following require a diagnostic? > > struct s { int a; } s; > int i; > > i = (int)s; /* pretty please! */ I won't try to answer that, but I think defining something in a derivative standard that was left undefined by the ISO C standard is different than changing an "inherited" constraint. This seems to be supported by the wording of the CX margin code [4] ("any conflict is unintentional"). Cheers, lacos [0] http://groups.google.com/group/comp.lang.c.moderated/msg/9424a7526e343c52 Message-ID: <clcm-20091222-0026(a)plethora.net> [1] http://www.opengroup.org/onlinepubs/9699919799/frontmatter/participants.html [2] http://groups.google.com/group/comp.lang.c.moderated/msg/e9a5008c16c28f49 Message-ID: <clcm-20091217-0003(a)plethora.net> [3] http://groups.google.com/group/comp.lang.c.moderated/msg/159aae9d761d79ef Message-ID: <clcm-20100120-0002(a)plethora.net> [4] http://www.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap01.html#tag_01_07_01
From: William Ahern on 7 May 2010 00:23 Ersek, Laszlo <lacos(a)caesar.elte.hu> wrote: <snip> > [1] http://www.opengroup.org/onlinepubs/9699919799/frontmatter/participants.html The fact that the committee is vascillating between type-punning and cast-to-function-pointer suggests that there's confusion. What's most clearly problematic as far as standards conformance goes, is the suggestion in the comments to the defect report that they could drop the 2.12.3 pointer equivalence clause. That's necessary no matter what method. BTW, it just occurred to me that the following is allowable. I can't believe that I didn't catch it earlier--6.3.2.3, para. 5 and 6. const char *(*getver)(void); getver = ((const char *)(*)(void))(intptr_t)dlsym(lib, name); It of course depends on representation.
From: Ersek, Laszlo on 7 May 2010 06:58 On Thu, 6 May 2010, William Ahern wrote: > What's most clearly problematic as far as standards conformance goes, is > the suggestion in the comments to the defect report that they could drop > the 2.12.3 pointer equivalence clause. That's necessary no matter what > method. (I suppose you're implying <http://austingroupbugs.net/view.php?id=74#c156>.) Dropping 2.12.3 would obliterate a generic requirement. dlsym() could still be required to return appropriate values -- that would define a more "narrow" behavior than 2.12.3 does now, ie. a proper subset of 2.2.13. Thus it would likely not clash with anything in ISO C, just as 2.12.3 doesn't. > BTW, it just occurred to me that the following is allowable. I can't > believe that I didn't catch it earlier--6.3.2.3, para. 5 and 6. > > const char *(*getver)(void); > getver = ((const char *)(*)(void))(intptr_t)dlsym(lib, name); > > It of course depends on representation. That seems to be a very good idea to me. (I don't know if the Austin Group participants have considered it before, I'm a rookie subscriber.) Thanks! lacos
From: Geoff Clare on 7 May 2010 08:46
William Ahern wrote: > I don't understand why the Austin Group would entertain returning to the > casting form. If the intention is to be able to drop the 2.12.3 requirement, > then they've just shot themselves in the foot. By adding 2.12.3 they tried to solve a problem with one specific function (dlsym) by creating a much more general requirement. One which, it turns out, introduced problems of its own. Someone else has posted a link to the austin-group-l thread on bug 74. Let's not repeat that discussion here. The fix for bug 74 is to remove 2.12.3 and introduce a different fix for the dlsym problem that is specifically targeted at just dlsym. Specifically, the new description of dlsym says: 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. -- Geoff Clare <netnews(a)gclare.org.uk> |