Email List: Xaustin-group-lX
[All Lists]

UNS: RE: [1003.1(2008)/Issue 7 0000074]: Pointer Types Problem

To: "Wojtek Lerch" <Wojtek@xxxxxxx>
Subject: UNS: RE: [1003.1(2008)/Issue 7 0000074]: Pointer Types Problem
From: <wollman+austin-group@xxxxxxxxxxx>
Date: Wed, 8 Jul 2009 16:09:34 -0400
Cc: <austin-group-l@xxxxxxxxxxxxx>
References: <e26e5335cda9d0dfe49395e6115066fe@austingroupbugs.net><1730938080F74546ACC51CB65BA00565@ott.qnx.com><20090702094404.GA28393@squonk.masqnet><4A4CC239.2040603@qnx.com><5030E566C603DA449D6B4C060CE529B73A8F37@MCHP7RDA.ww002.siemens.net><4A4D2366.9090904@qnx.com><5030E566C603DA449D6B4C060CE529B73A8FF1@MCHP7RDA.ww002.siemens.net><19022.23792.699537.351052@khavrinen.csail.mit.edu><9FC357E76048C74C93F3BD3D69A16B88045641AC@nova.ott.qnx.com>
<<On Sat, 4 Jul 2009 07:41:02 -0400, "Wojtek Lerch" <Wojtek@qnx.com> said:

>> From: wollman+austin-group@lcs.mit.edu 
>> After all this, wouldn't it simply be easier to define a new dlfunc()
>> interface?  There is prior art.

> Easier to define, probably.  But it wouldn't make life easier for
> implementors, especially those ones who already have the old dlsym() but
> not the new dlfunc() in their implementations, would it?

Not necessarily.  In one case, they, and their customers, have to deal
with (or disable) diagnostics emitted by Standard C99 compilers (that
they may not even control) about undefined behavior that POSIX is now
attempting to define.  In the other case, they have to add a one-line
function to their standard library and a one-line declaration in their
<dlfcn.h>, and potentially deal with a single compiler diagnostic in
one place, which can be documented.  

Numerous clients of this interface already exist, and they deal with
its absence in the obvious (diagnostic-inducing) way.

-GAWollman

<Prev in Thread] Current Thread [Next in Thread>