Re: 1.5.8 build failure on Solaris 8
* On 2005.03.04, in <20050304160002.GA6183@xxxxxxxxxxxxxx>,
* "Brendan Cully" <brendan@xxxxxxxxxx> wrote:
>
> > The only other option is unpleasant: change all calls to look like this:
> >
> > struct s *p = ...;
> > int fd = (p->open)(name, mode);
> > (p->close)(fd);
>
> I actually don't mind this version. In a way I like it better than
> the global rename, even though it's about the same amount of work. It
> makes me feel like the namespace is a little less polluted :)
For what it's worth.... I don't mind this, either. It's a little
unattractive, but it eliminates a category of problems, not just a
single instance.
The problem we're talking about is essentially a risk of using function
pointers as elements of structures, not with the "open" symbol itself.
Changing the name of the symbol is just reducing the likelihood of
namespace conflict, but the same problem could occur in some other
circumstance -- on another OS, or another compiler environment, of if
someone patches some accessory library into the code. And I have seen
this happen with namespace prefixes.
Placing calls through function pointers within parentheses is a sure
fix, though. I'm satisfied with adopting that as standard practice
when I use function pointers, just to dodge any risk of this category
of problem. And as a rule, it becomes a recognizable pattern and thus
somewhat less unattractive to look at. :)
Thanks, Aaron, for the summary and for pointing out that workaround.
I've run into this before with assorted other functions (not standard
ones), but I've never thought to do anything but rename the pointers.
--
-D. dgc@xxxxxxxxxxxx NSIT::ENSS
"So now, less than five years later, you can go up on a steep hill...
and with the right kind of eyes you can almost see the high-water
mark -- the place where the wave finally broke and rolled back." -HST