overriding functions

[Eric]

I have a program that uses a custom function that, as it happens, has
the same name as a function in the standard library. By custom, I mean
it was something that was written in-house because at the time this
function did not exist in the standard library (as near as I can tell).

In general, how confident can I be that the resulting executable will
use my custom function rather than the libc version of the function?
(In particular, all of this is happening on a stock RH9 machine).
Would I be much better off just renaming the custom function and all
its references?

From what I've been able to piece together, it sounds like resolving
conflicting functions is kind of a crap shoot and that I should just
avoid function name conflicts.

Thanks in advance
eric

 

[Walter Roberson]

I have a program that uses a custom function that, as it happens, has
the same name as a function in the standard library. By custom, I mean
it was something that was written in-house because at the time this
function did not exist in the standard library (as near as I can tell).

In general, how confident can I be that the resulting executable will
use my custom function rather than the libc version of the function?

We had a long argument about this a couple of months ago. Pretty
much everyone else said that such a thing was an error and prohibitted
by the standard. I held out for the position that it wasn't an
error nor prohibitted by the standard, merely that the standard
said the behaviour was undefined.

Eventually I got -one- other person to agree that the standard doesn't
actually declare it to be an error, but they still considered it to be
-effectively- prohibitted. And everyone else stuck with the
position that the standard declares it to be an error. A number
of strawmen were brutally mangled in the course of the discussion,
and it's a good thing for my bodily integrity that I have a thick skin.

(In particular, all of this is happening on a stock RH9 machine).
Would I be much better off just renaming the custom function and all
its references?

If you turn off inlining then *in practice* I would say that it
is plausible you would be able to get it to work on RH9, unless
perhaps the library routine is something essential such as malloc().

From what I've been able to piece together, it sounds like resolving
conflicting functions is kind of a crap shoot and that I should just
avoid function name conflicts.

I haven't used RH much at all, so I cannot answer to that point.

On SGI IRIX with SGI's compilers, it would be quite straight-forward: on
your link command line, just put your implimenting object to the
"right" of your code that needs your custom routine, but to the left of
any system library object or other user object that needs to access
(or define) the official library version.

 

[Roger Leigh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I have a program that uses a custom function that, as it happens, has
the same name as a function in the standard library. By custom, I mean
it was something that was written in-house because at the time this
function did not exist in the standard library (as near as I can tell).

In general, how confident can I be that the resulting executable will
use my custom function rather than the libc version of the function?
(In particular, all of this is happening on a stock RH9 machine).
Would I be much better off just renaming the custom function and all
its references?

The ELF binary format used by GNU/Linux has well-defined name lookup
rules, but are outside the scope of Standard C. Please ask on
comp.os.linux.development.apps.


Thanks,
Roger

- --
Roger Leigh
Printing on GNU/Linux? http://gimp-print.sourceforge.net/
Debian GNU/Linux http://www.debian.org/
GPG Public Key: 0x25BFB848. Please sign and encrypt your mail.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Processed by Mailcrypt 3.5.8 <http://mailcrypt.sourceforge.net/>

iD8DBQFCn2qNVcFcaSW/uEgRAqiEAKDV99BUCZJad0AhbighLd6VdE0DFACfa2gN
t/Kvb4voyPoyFAMFJAJLmfs=
=bKED
-----END PGP SIGNATURE-----

 

[Eric Sosman]

I have a program that uses a custom function that, as it happens, has
the same name as a function in the standard library. By custom, I mean
it was something that was written in-house because at the time this
function did not exist in the standard library (as near as I can tell).

In general, how confident can I be that the resulting executable will
use my custom function rather than the libc version of the function?

"In general," not very. Some systems will use yours,
some systems will use their own, some will use both in a
strange sort of mixture, and some will refuse to link the
program in the first place.

(In particular, all of this is happening on a stock RH9 machine).

Then it's probably possible to get "something reasonable"
to happen, but how you go about it (and how you verify that
you got what you expected) are questions you should ask on a
newsgroup devoted to RH, not here.

Would I be much better off just renaming the custom function and all
its references?

Yes, unequivocally. You'll also ease your maintenance
burden, perhaps by a lot. A programmer who sees a call to
what he thinks is a Standard library function will assume he
knows what the function does; if it actually turns out to do
something different, he will misunderstand what the program
is trying to do and will waste time and effort on blind alleys.

From what I've been able to piece together, it sounds like resolving
conflicting functions is kind of a crap shoot and that I should just
avoid function name conflicts.

That's the best policy, I think. One might be tempted to
use #define to accomplish the renaming, but that would probably
turn out to be at least as disruptive as just doing a wholesale
edit -- and would still leave the "confusion issue" unsolved.

I once tracked down a nasty bug where a large program was
crashing unpredictably inside the memory allocation functions.
The cause turned out to be a realloc() of some memory obtained
from malloc() -- all perfectly legal, and everything should
have worked just fine. It turned out that the whole program
was using #define's to substitute its own implementations of
malloc() and friends, but that one module had been overlooked
when somebody went around inserting them -- maybe the module
hadn't been doing any memory management back then. The effect
of allocating memory with local_malloc_lookalike() and then
trying to resize it with the One True realloc() is best left
to your morbid imagination.

 

[Eric]

Yeah, I think I saw that thread when I first started investigating this
problem. As someone who's looking for a "definitive" answer I found it
quite unsatisfying. I thought I'd try again (I'm now reminded about
something I heard regarding the definition of insanity).

Thanks
eric

 

[Eric]

Cool. That settles it for me then.

Thanks
eric

 

[SM Ryan]

# I have a program that uses a custom function that, as it happens, has
# the same name as a function in the standard library. By custom, I mean
# it was something that was written in-house because at the time this
# function did not exist in the standard library (as near as I can tell).

You might be able to use #defines to trick your way around the issue.
For example if you want to reuse the name "strcpy", you can try a header
with

#undef strcpy
#define strcpy z_strcpy
static T strcpy(.....);

And everywhere you use this header it should magically rewrite calls to
strcpy to z_strcpy.