calling my custom function same as library function

[Deniz Bahar]

Hi,

I would like to call one of my functions the exact name as an existing
C library function (for example K&R2 exercises asks me to make an atof
function). If I don't include the header with the declaration for the
C library function (stdlib.h in this case) then define/declare my own
function with the same name, am I safe? It seems to work on my
compiler, but I wonder if this is portable or even acceptable? thx

[Kenny McCormack]

In article <11**********************@l41g2000cwc.googlegroups .com>,
Deniz Bahar <de*********@gmail.com> wrote:

Hi,

I would like to call one of my functions the exact name as an existing
C library function (for example K&R2 exercises asks me to make an atof
function). If I don't include the header with the declaration for the
C library function (stdlib.h in this case) then define/declare my own
function with the same name, am I safe? It seems to work on my
compiler, but I wonder if this is portable or even acceptable? thx

Yes, but you can't talk about it here.

[Walter Roberson]

In article <11**********************@l41g2000cwc.googlegroups .com>,
Deniz Bahar <de*********@gmail.com> wrote:
:I would like to call one of my functions the exact name as an existing
:C library function (for example K&R2 exercises asks me to make an atof
:function). If I don't include the header with the declaration for the
:C library function (stdlib.h in this case) then define/declare my own
:function with the same name, am I safe?

Library function names are not 'reserved'.

If your function has the same prototype as the existing one, then
there is no problem including the header file. The standard
header files only give the linkage information for the cases where
you -do- use the library function: the header files do not in
any way "bring in" the library functions. When you use the library
functions, it is the linker that puts them into the program address
space, not the header files.

:It seems to work on my
:compiler, but I wonder if this is portable or even acceptable? thx

It is portable to any system I have ever heard of, and it is
often used. It is a fundamental mechanism by which functionality
can be extended, such as for replacing the malloc() function with
one that is more efficient or which provides debugging hooks.

Exact linker details differ, but the general practice is that
the code for the standard C library functions is stored in an
object "library", and that the linker will only pull in references
to those library functions for which it has unsatisfied references.
When you provide your own version of a library function, then code
that calls upon that function will find your definition of that
name and will use that: there will not be any unsatisfied references
to the name and so the linker will not try to reference the library
routine by that name.
There are two major competing linkage paradigms:

- In one of them, the order that the files are named is unimportant: the
linker examines all the user-provided object files, finds all the
definitions and unsatisfied references to routines, and to the greatest
extent possible uses the definitions from -any- of the given object
files. The linker then only pulls in those library routines which
there is a reference to but which were not defined by the user.
This paradigm requires at least two passes over the object files,
once to find out what all is defined in any user-provided file, and the
second time to do the linking.

- In the second linker paradigm, the order of the files is important.
The linker proceeds from left [first on the line] towards the right
[last on the line], accumulating definitions and unsatisfied
references as it goes. At any point, when there is an unsatisfied
reference to a function and a definition of that function is seen,
the definition is used to satisfy the reference. That definition
may reference other functions; if those other functions are defined
in the same object then that definition is used but otherwise a new
unsatisfied reference is created that must be filled by something
further to the right. For such linkers, there is no record kept
of definitions which have -already- been seen: if the first
file defines FOO and the second file calls upon FOO, then the
linker will -not- go back to the first file to find FOO: it will
expect -another- FOO to be defined in a later object. This kind
of linkage is "one pass": it never needs to go back to an existing
file, and never needs to keep track of which file defines which
object [only of which unsatisfied references there are.]
I have not used the first paradigm very much, so I am not sure
how it handles multiple definitions. In the second paradigm, if
you want to define something that pre-empts a library routine,
all you have to do is put its definition further right on the
command line than anything that calls upon that function:
as the linker passes from left to right, it will see your atof()
or whatever and will use that to satisfy any calls to atof()
that were further left; with there no longer being any unsatisfied
calls to atof(), the library object copy of the routine will not
be needed.

There are some other tricks to linkers as well, but they tend
to be more implimentation-dependant. One-pass linkers are fairly
common, but you should read the manual pages for the linker you
are using so that you know how it processes definitions.
Redefining a library function is not exceptional for utility
packages, and there is almost always -some- way to do it.
--
Preposterous!! Where would all the calculators go?!

[Jack Klein]

On 27 Feb 2005 17:55:39 -0800, "Deniz Bahar" <de*********@gmail.com>
wrote in comp.lang.c:

Hi,

I would like to call one of my functions the exact name as an existing
C library function (for example K&R2 exercises asks me to make an atof
function). If I don't include the header with the declaration for the
C library function (stdlib.h in this case) then define/declare my own
function with the same name, am I safe? It seems to work on my
compiler, but I wonder if this is portable or even acceptable? thx

According to the C standard, it is neither portable nor acceptable to
use the name of a library function in a context where it has external
linkage.

That means, you can define a function named "atof" if and only if you
define it with the static keyword, which means you can only call it by
name from within the same source file.

Otherwise you generate undefined behavior.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[Jack Klein]

On 28 Feb 2005 02:48:17 GMT, ro******@ibd.nrc-cnrc.gc.ca (Walter
Roberson) wrote in comp.lang.c:

In article <11**********************@l41g2000cwc.googlegroups .com>,
Deniz Bahar <de*********@gmail.com> wrote:
:I would like to call one of my functions the exact name as an existing
:C library function (for example K&R2 exercises asks me to make an atof
:function). If I don't include the header with the declaration for the
:C library function (stdlib.h in this case) then define/declare my own
:function with the same name, am I safe?

Library function names are not 'reserved'.

The C standard disagrees:

"7.1.3 Reserved identifiers
1 Each header declares or defines all identifiers listed in its
associated subclause, and optionally declares or defines identifiers
listed in its associated future library directions subclause and
identifiers which are always reserved either for any use or for use as
file scope identifiers."

....and then, in the itemized list that is also part of paragraph 1:

"All identifiers with external linkage in any of the following
subclauses (including the future library directions) are always
reserved for use as identifiers with external linkage."

....therefore, it is undefined to define your own function with the
same name as any standard library function, unless you use the static
keyword to limit it to internal linkage.

Whether or not this particular instance of undefined behavior "works"
is in the eye of the beholder, since the C standard requireth not.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[Walter Roberson]

In article <ut********************************@4ax.com>,
Jack Klein <ja*******@spamcop.net> wrote:
:According to the C standard, it is neither portable nor acceptable to
:use the name of a library function in a context where it has external
:linkage.

That does not sound right. Every library function has external linkage
relative to the user code.
--
I don't know if there's destiny,
but there's a decision! -- Wim Wenders (WoD)

[Eric Sosman]

Walter Roberson wrote:

In article <11**********************@l41g2000cwc.googlegroups .com>,
Deniz Bahar <de*********@gmail.com> wrote:
:I would like to call one of my functions the exact name as an existing
:C library function (for example K&R2 exercises asks me to make an atof
:function). If I don't include the header with the declaration for the
:C library function (stdlib.h in this case) then define/declare my own
:function with the same name, am I safe?

Library function names are not 'reserved'.
That will come as a surprise to the authors of
Section 7.1.3, paragraph 1, fourth point:

"All identifiers with external linkage in any
of the following subclauses (including the future
library directions) are always reserved for use
as identifiers with external linkage."
[stuff about the way many linkers work]

Even if the linker is able to substitute a user-written
function for an actual library function, there is no guarantee
the program will work. Library functions may have private,
unpublished interfaces with each other, "back doors" into each
others' operations. In some cases this seems the only way to
implement the function: for example, fflush(NULL) needs some
way to find the eligible streams, free() needs a way to tell
malloc() that the memory has become available again, exit()
needs to find all the functions registered with atexit(),
and so on. The nature and number of such interrelationships
varies from one C implementation to the next, and there is no
requirement that they be documented.

As a practical matter it is quite likely that replacing
atof() will work (even though it may well be connected with
strtod() and the *scanf() family in arcane ways). However,
the Standard does not promise it will work -- the Standard,
in fact, forbids the attempt -- and if the program misbehaves
you have no one to blame but yourself.

--
Eric Sosman
es*****@acm-dot-org.invalid

[Walter Roberson]

In article <94********************************@4ax.com>,
Jack Klein <ja*******@spamcop.net> wrote:
|On 28 Feb 2005 02:48:17 GMT, ro******@ibd.nrc-cnrc.gc.ca (Walter
|Roberson) wrote in comp.lang.c:

|> Library function names are not 'reserved'.

|The C standard disagrees:

|"7.1.3 Reserved identifiers
|1 Each header declares or defines all identifiers listed in its
|associated subclause, and optionally declares or defines identifiers
|listed in its associated future library directions subclause and
|identifiers which are always reserved either for any use or for use as
|file scope identifiers."

The 'and identifiers which are always reserved' is distinct in that
sentance from the declarations listed and the future directions list.
That sentance does *not* say that the identifiers in headers are
reserved: it says that one of the things that might be in a header
file is a declaration or definition of an identifier that is always
reserved. The part of the sentance about "for any use" is
in contrast to "as file scope identifiers": header files might
contain declarations or definitions for one or both types, or neither.
:...and then, in the itemized list that is also part of paragraph 1:

:"All identifiers with external linkage in any of the following
:subclauses (including the future library directions) are always
:reserved for use as identifiers with external linkage."

Reserving an identifier for external linkage does not reserve it
for implimentation library definition.

:...therefore, it is undefined to define your own function with the
:same name as any standard library function, unless you use the static
:keyword to limit it to internal linkage.

No, the part about being reserved for external linkage that you
quote would preclude using the identifier with internal linkage.
:Whether or not this particular instance of undefined behavior "works"
:is in the eye of the beholder, since the C standard requireth not.

The C standard is, of course, not about to say that if you
define a function with the same name as a library function that
somehow you are going to magically get the library function
behaviour even though your own code would be called. The C standard
cannot make any promises about what is going to happen if you
define your own version of a function -- not because such a thing
is prohibitted, but simply because the C standardization committee
can't know what your version of the routine is going to do.
The OP suggested that he might omit the header file. Any "reserved"
behaviour that you are imputing by way of the initial part of paragraph
1 of 7.1.3 would then be irrelevant. (And I don't agree that
that portion reserves any behaviour.)
--
If a troll and a half can hook a reader and a half in a posting and a half,
how many readers can six trolls hook in six postings?

[Chris Torek]

In article <cv**********@canopus.cc.umanitoba.ca>
Walter Roberson <ro******@ibd.nrc-cnrc.gc.ca> wrote:

Library function names are not 'reserved'.

This is not quite right.

Library function names are reserved for use as external-linkage
identifiers. Hence the following source-file-fragment is valid,
guaranteed C code:

#include <stdio.h>
/* do not include <math.h> */

static int sin(void) {
puts("let he who is without sin() cast the first stone");
}

/* code that calls sin() */

but this one is not:

#include <stdio.h>
/* again, do not include <math.h> */

int tan(void) {
puts("sit in the sun for a few minutes for a nice tan()");
}

/* code that calls tan() */

Among other problems with attempting to override a library function
is the fact that modern C compilers may not actually *call* anything
where you put in a library-function call. For instance, this code:

/* #include <string.h> -- deliberately commented out */
#include <stdlib.h> /* for size_t */

void *memcpy(void *, const void *, size_t);

void f(int *p) {
memcpy(p, "123", 4);
}

produces the following x86 assembly code when run through GCC:

.p2align 2,,3
.globl f
.type f,@function
f:
movl $3355185, (%eax)
ret

(The function f() consists entirely of two instructions, neither
one a call to memcpy(). Compile with "-O -fomit-frame-pointer
-mregparm=3" to obtain this code. Otherwise you will get a little
extra code to deal with stack frames and/or parameter passing.)

(If you make the memcpy() declaration "static", gcc will emit a
call to the [missing] function, as required for Standard C. Of
course, you then have to define your static [internal-linkage]
memcpy() as well.)

(Even if you get a call to a function where you used a Standard C
Library function call, there is no guarantee that the call will be
made in the "usual fashion", or to the name you wrote. But this
tends to be less common than inline expansion of the "known"
function, since the latter has a greater return-on-investment in
most cases.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[Walter Roberson]

In article <pP********************@comcast.com>,
Eric Sosman <es*****@acm-dot-org.invalid> wrote:
: Even if the linker is able to substitute a user-written
:function for an actual library function, there is no guarantee
:the program will work. Library functions may have private,
:unpublished interfaces with each other, "back doors" into each
:others' operations.

That is a good point, which is of concern with "global" linkers
that examine all the files first before choosing which function
to link to. It turns out, though, not to be a problem with
one-pass linkers unless the user explicitly names the relevant
libraries before they name their object file [and even then,
it turns out not to be a problem for the standard library.]

In one pass linkers, if the user's object file defining [say]
malloc() is placed between their other object files and the
[possibly implicit] reference to the standard C library, then
the user's definition will satisfy any malloc() references in
the user's code; the one-pass linker will then "forget" that it
has seen a definition of malloc() and will proceed onwards. When
it then encounters an unsatisfied reference to malloc() inside the
standard libraries, then it will either satisify the reference from
the same library or will look further right for the definition,
just as would normally be the case. That is, absent deliberate
manipulation to cause otherwise, user definitions of library
functions will [for one pass linkers] apply only to the user
code, and the library definition will apply for anything further
right such as the other libraries. One-pass linkers do not
do "global" replacement of function references: only
unsatisfied references to the left of the current object.

I can't speak on what happens in practice with multipass linkers.
I would, though, point out that it would be unusual for
private interfaces to exist in library functions except at file
scope, which would use internal linkage rather than external.

--
How does Usenet function without a fixed point?

[DHOLLINGSWORTH2]

"Kenny McCormack" <ga*****@yin.interaccess.com> wrote in message
news:cv**********@yin.interaccess.com...

In article <11**********************@l41g2000cwc.googlegroups .com>,
Deniz Bahar <de*********@gmail.com> wrote:

Hi,

I would like to call one of my functions the exact name as an existing
C library function (for example K&R2 exercises asks me to make an atof
function). If I don't include the header with the declaration for the
C library function (stdlib.h in this case) then define/declare my own
function with the same name, am I safe? It seems to work on my
compiler, but I wonder if this is portable or even acceptable? thx

Yes, but you can't talk about it here.

He's right this is the You cant do that group. You want the Yes no problem
group.

comp.lang.c++

Dan

[Flash Gordon]

Kenny McCormack wrote:

In article <gd************@brenda.flash-gordon.me.uk>,
Flash Gordon <sp**@flash-gordon.me.uk> wrote:

Kenny McCormack wrote:

In article <h1************@brenda.flash-gordon.me.uk>,
Flash Gordon <sp**@flash-gordon.me.uk> wrote:
...
The initial problem here is that your answer to an ON TOPIC question was
inaccurate. After further discussion about what the standard means you are
allowed to do (which I would consider potentially reasonable even though
I consider your opinion to be wrong) you then went on to how you believe
linkers work which is generally considered OFF TOPIC as a justification as
to why you were right. Jack pointed out that the linker details are off
topic and that more than one person has quoted the parts of the standard
that say you are wrong.

Just remember: According to the bible, pi = 3.0

So, if I say that it is really 3.14159..., I guess that's inaccurate, and
I should be killfiled, right?

Since the bible is off topic here, invoking the bible for what the
correct value of pi is would be off topic since neither the C standard ^^^^^^^^^^^^^^^^^^nor K&R1 incorporate the bible. However, what the C standard says is ON
topic here because this group is for discussing the C language and that
is defined by the C standard (all versions) or, if you are dealing with
stuff that for some strange reason needs to be build using pre-standard
compilers, K&R1.

Bzzzt.

Discussions of topicality are always (by definition) on-topic.
My reference to the bible was by way of analogy in regards to a topicality
discussion.

I never said that asking a question about topicality was off topic. I
said WOULD be off topic, not IS off topic, in response to you asking
about topicality. So you asked a question about topicality and I
answered it. Perhaps you should read a bit more carefully.
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.

[Alan Balmer]

On 28 Feb 2005 17:36:20 GMT, ro******@ibd.nrc-cnrc.gc.ca (Walter
Roberson) wrote:

:Yes, you can. Stop your offensive behavior.

Would my silencing myself result in others becoming politer
Yes, by removing your instances of rudeness and eliminating the need
for rude replies.
and more flexible
about what can be answered in clc ?
Obviously not, since we're trying to tell you that the current level
of flexibility is already suitable. There are thousands of groups in
usenet - how much more flexible can you get? We obviously don't want
everything from those thousands of groups posted here.
If not, then what -would- lead to such
an end?

Badgering those who are attempting to help others is, to put it bluntly,
a form of bullying.
Nonsense. It's simply an attempt to keep topical. If you really wanted
to help others, you would make good suggestions as to where they
should ask their off-topic questions, then go there and answer them,
where they can be supplemented and reviewed by others interested in
the topic.
One does not put an end to a cycle of bullying by
submitting to it.

You can easily avoid any bullying here, by not being here.

BTW, it is in your power to eliminate one more minor but annoying
instance of rudeness - your use of an unorthodox quote character.

--
Al Balmer
Balmer Consulting
re************************@att.net

[Kenny McCormack]

In article <m7************@brenda.flash-gordon.me.uk>,
Flash Gordon <sp**@flash-gordon.me.uk> wrote:
....

I never said that asking a question about topicality was off topic. I
said WOULD be off topic, not IS off topic, in response to you asking
about topicality. So you asked a question about topicality and I
answered it. Perhaps you should read a bit more carefully.

Maybe you should get that stick out of your ass.

[Walter Roberson]

In article <ua********************************@4ax.com>,
Alan Balmer <al******@spamcop.net> wrote:
:BTW, it is in your power to eliminate one more minor but annoying
:instance of rudeness - your use of an unorthodox quote character.

Sorry, which RFC is it that defines the Usenet quote character?
--
Those were borogoves and the momerathsoutgrabe completely mimsy.

[Gordon Burditt]

>I would like to call one of my functions the exact name as an existing

C library function (for example K&R2 exercises asks me to make an atof
function). If I don't include the header with the declaration for the
C library function (stdlib.h in this case) then define/declare my own
function with the same name, am I safe?
No.
It seems to work on my
compiler, but I wonder if this is portable or even acceptable? thx

The problem you typically run into (if there are problems) is that
when you get something out of the library, you get X, Y, and Z
together (not separately), and if you have a replacement X and also
need Y (directly or indirectly), you end up with two different
copies of X loaded and a "multiply defined symbol" error.

Another problem that may come up is that your replacement for X is
also called from library functions, and either your interface for
X is (intentionally) not the same, or your interface for X does not
implement some magic undocumented stuff used internally by the
library.

Gordon L. Burditt

[infobahn]

Walter Roberson wrote:

In article <ua********************************@4ax.com>,
Alan Balmer <al******@spamcop.net> wrote:
:BTW, it is in your power to eliminate one more minor but annoying
:instance of rudeness - your use of an unorthodox quote character.

Sorry, which RFC is it that defines the Usenet quote character?

Be nice. He didn't say that : is "non-standard" (implying a de jure
standard). He said that it's "unorthodox", which it is. Most people
use > rather than : and so > is "orthodox" and : is "unorthodox".
Having said that, he does seem to be using the word "unorthodox" in
a way that doesn't entirely coincide with my dictionary definition.
It is therefore an unorthodox use of the word "unorthodox" (and I
myself am using "unorthodox" in an unorthodox manner, recursively!).

Nevertheless, his - and my - use of "unorthodox" certainly has the
saving grace that it is commonplace; the dictionary inevitably lags
behind modern usage, and "unorthodox" has already acquired in common
parlance the meaning which Mr Balmer appeared to intend. Therefore
his unorthodox use of "unorthodox" isn't quite as unorthodox now as
it would have been considered many years ago. It has become orthodox.

Or something.

In any case, it would make newsreader writers' jobs much easier if
there /were/ a Usenet standard for quoting, and > is as close as
we're going to get to a standard, so it makes sense to use it.

ObC: imagine you're writing a C program to re-flow Usenet text
to keep your reply (and the text which it quotes) within N
columns, whilst correctly retaining attributions and associating
them with the correct text. Can you devise a mechanism for
automatically identifying which characters at the beginning of
a line should be regarded as quote characters?

(10 marks. Write on only one side of the newsgroup. No copying.)

[Lawrence Kirby]

On Mon, 28 Feb 2005 16:12:09 +0000, Walter Roberson wrote:

In article <So********************@comcast.com>,
Eric Sosman <es*****@acm-dot-org.invalid> wrote:
:Let's suppose you decide to replace malloc()

A standard which prohibits you from doing so will be often
violated, of necessity.
The standard doesn't prohibit you from doing this, it simply ceases to
make any guarantees about the behaviour of your program if you do. It
doesn't guarantee that an implementation will allow you to do this. For
example trying to replace memcpy() would be tricky with many
implementations that (legitimately) generate inline code for it rather
than a library call.
The purpose of standardizing functions is not to lock the user
in and prohibit them from using other implimentations.
It is better to look at this from a different angle. If you want to change
the implementation then fine, but keep that change separate from your user
program code. You program can keep to the standard but you separately take
on the responsibility of an implementor to maintain a valid
implementation. Of course if you break it that's your problem, not the
problem of those who wrote the implementation originally.
: However, all this speculation about mechanisms is beside the
:point, which is that the C Standard forbids the programmer from
:using any of the library function names for his own externally-
:linked objects and functions.

I will review the exact wording of the standard at my earliest
opportunity. The portions that have been quoted here did not contain
such a prohibition.

The standard has a set of rules and specifies the behaviour of programs
that stick to them. If your program doesn't the standard can't be used to
predict what your program will do.

Lawrence

[Deniz Bahar]

Jack Klein wrote:

According to the C standard, it is neither portable nor acceptable to
use the name of a library function in a context where it has external
linkage.

That means, you can define a function named "atof" if and only if you
define it with the static keyword, which means you can only call it by name from within the same source file.

Otherwise you generate undefined behavior.

Do you think it is advisable for me to make a header
(mylibraryreplacements.h) and have static definitions in them and
include them in the source files that need it?

Like:

mylibraryreplacements.h
=======================
#ifndef _MYLIBRARYREPLACEMENTS_H
#define _MYLIBRARYREPLACEMENTS_H

static double atof(char *){/*body*/}
static int atoi(char *){/*body*/}
static void* malloc(size_t size){/*body*/}

#endif

Is this a "poor" technique?

[Gordon Burditt]

>Do you think it is advisable for me to make a header

(mylibraryreplacements.h) and have static definitions in them and
include them in the source files that need it?
I think it would be an extremely bad idea to do this for functions
that need static or global data which OUGHT TO be shared but won't be.
atof() and atoi(), fine, except you will have multiple copies of
the code in your executables.

malloc(), *NOT FINE*. You didn't include a matching free() in
there. Expect all heck to break loose when you try to free()
something allocated from a different pool than it was originally
malloc()ed from. This is a problem even if you were careful to
ensure that every piece of your program that uses malloc() includes
your header file.

Like:

mylibraryreplacements.h
=======================
#ifndef _MYLIBRARYREPLACEMENTS_H
#define _MYLIBRARYREPLACEMENTS_H

static double atof(char *){/*body*/}
static int atoi(char *){/*body*/}
static void* malloc(size_t size){/*body*/}

#endif

Is this a "poor" technique?

You end up with multiple copies of code, unnecessarily. There are
lots of potential problems when each copy of malloc() is using its
own pool of memory and someone free()s using a different instance
of malloc() than what it was allocated with.

Gordon L. Burditt