calling my custom function same as library function

[Flash Gordon]

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.

 

[Eric Sosman]

: 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
thers' 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.]

I think you're missing the point. Let's suppose you decide
to replace malloc(), perhaps the library function that is the
most frequent target of such beyond-the-pale substitution. Are
you stupid enough to replace malloc() alone, without replacing
calloc(), realloc(), and free()? Of course not: you know that
these four functions are a "package," they interoperate with
each other, they manipulate the same undocumented data structures,
and so on. You replace all four functions as an indivisible
unit; you may even go so far as to replace non-Standard functions
like mallinfo() or mallopt() or xmalloc() -- the point is, you
must replace the entire package to have any hope of success.

Ah, but did you remember to replace _io_alloc(), the special
"back door" fopen() and set[v]buf() use to obtain I/O buffers
aligned on page boundaries? Almost certainly not: _io_alloc()
is an implementation-private undocumented function ... which
just happens to depend on the exact details of the undocumented
data structures used by malloc() et al. Drop a different malloc()
into the program, and suddenly your I/O streams start misbehaving
in mysterious ways ...

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.

I'm sure you're describing *something* here, but I can't
make out what it might be. If a linker finds a definition of
function f() in the first module it processes, but then forgets
all about it when processing the second module's references to
f(), you've got a useless linker. C functions can be called
recursively, so the call graph can contain loops: it is not
always possible to place a function definition after all the
references to it.

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. The Standard need not (and does
not) expound on the reasons for the prohibition; it's simply
part of the definition of the language. If you attempt such a
thing (and get away with it), you are not writing "C" but some
other language, "C-with-special-dispensations." And if things
go wrong your recourse is limited, since CWSD has no Standard
you can browbeat the vendor with.

 

[Eric Sosman]

|On 28 Feb 2005 02:48:17 GMT, (e-mail address removed)-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
> :[...]
:...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.

Perhaps a look at the Rationale might give a hint as to the
intended reading:

7.1.3 Reserved identifiers
To give implementors maximum latitude in packing library
functions into files, all external identifiers defined
by the library are reserved in a hosted environment. This
means, in effect, that no user-supplied external names
may match library names, /not even if the user function
has the same specification./ [...]

The Rationale is non-normative, of course. Nonetheless, it sheds
light on how the authors of the Standard meant their words to be
understood. Just as the courts consider not only the text of a
law but also its legislative history, readers of the Standard can
find useful guidance in the Rationale.

 

[Walter Roberson]

:Let's suppose you decide to replace malloc()

A standard which prohibits you from doing so will be often
violated, of necessity.

The purpose of standardizing functions is not to lock the user
in and prohibit them from using other implimentations.

: However, all this speculation about mechanisms is beside the
oint, 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.

 

[Martin Ambuhl]

:Linkers are completely off-topic here.

Let me save you some trouble:

I will be posting on matters which are widely considered "off-topic".
If you don't want to read those messages, feel free to killfile me.

Why not just post in appropriate newsgroups? Your deciding to purposely
engage in anti-social behavior is curious.

I have noticed that some people in this newsgroup (I don't particularily
recall you being one of them) react to questions they consider to be
"off-topic" with what I can only term rudeness.

There is no such thing as rudeness to people who knowingly post
off-topic. They -- and we now know that you are among them -- are
engaging in among the most rude behavior possible on usenet; they are
the scum of the earth.

I can't do anything about
those people,

Yes, you can. Stop your offensive behavior.

 

[Alan Balmer]

(regarding writing functions with the same name as standard library
functions.)

blah, blah, blah
blah, blah, blah
blah, blah, blah

I.e., as I said originally: Yes, you can do it and everybody does it.

Read the thread on libel and slander ;-)

I don't do it, nobody who works for me does it (not more than once, at
any rate), and I strongly recommend that the OP not do it.

 

[Kenny McCormack]

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.

 

[Flash Gordon]

:Let's suppose you decide to replace malloc()

A standard which prohibits you from doing so will be often
violated, of necessity.

I've never had to violate it. I've just switched to an implementation
that provided extra debug if I've needed to (such as running under
Valgrind) or used my own wrapper functions (e.g. ffmalloc) which do the
extra stuff I want and call the real malloc with the application written
to always call ffmalloc.

The purpose of standardizing functions is not to lock the user
in and prohibit them from using other implimentations.

The standard does not *prevent* an implementation from providing a way
to replace standard functions. However, the mechanism for doing so will
be highly system dependant and there is no guarantee that all systems
can provide such a mechanism.

: However, all this speculation about mechanisms is beside the
oint, 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.

Saying that the identifiers were reserved looked reasonable to me.

 

[Walter Roberson]

:> I will be posting on matters which are widely considered "off-topic".

:There is no such thing as rudeness to people who knowingly post
ff-topic. They -- and we now know that you are among them -- are
:engaging in among the most rude behavior possible on usenet; they are
:the scum of the earth.

What you know is that I have different ideas about what is "on-topic"
and relevant than what the majority so consider. The way the newsgroup
is commonly used now is not in accordance with its original statement
of purpose from when it was a news.* group. That means that the purpose
and topicality of the group evolves over time -- but it doesn't do so
if everyone submits to the current norm that goes something like "A question
which is cannot be answered within the C89 or C99 standard is a scum question
deserving of nothing other than derision and vague answers that there might
be another newsgroup -somewhere- that holds the answer [and if not, tough luck]."

:> I can't do anything about
:> those people,

:Yes, you can. Stop your offensive behavior.

Would my silencing myself result in others becoming politer and more flexible
about what can be answered in clc ? 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. One does not put an end to a cycle of bullying by
submitting to it.

 

[Walter Roberson]

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

: Perhaps a look at the Rationale might give a hint as to the
:intended reading:

: 7.1.3 Reserved identifiers
: To give implementors maximum latitude in packing library
: functions into files, all external identifiers defined
: by the library are reserved in a hosted environment. This
: means, in effect, that no user-supplied external names
: may match library names, /not even if the user function
: has the same specification./ [...]

Thanks, Eric, that is a useful paragraph.

:The Rationale is non-normative, of course. Nonetheless, it sheds
:light on how the authors of the Standard meant their words to be
:understood. Just as the courts consider not only the text of a
:law but also its legislative history, readers of the Standard can
:find useful guidance in the Rationale.

Yes, I see what you mean.

I do not yet agree that the standard itself says that the attempt is
prohibitted [as opposed to saying YMMV], but I will have another
look at the wording of the standard itself, and of the Rationale,
and possibly my interpretation will change.

 

[Eric Sosman]

:Let's suppose you decide to replace malloc()

A standard which prohibits you from doing so will be often
violated, of necessity.

Agreed. I've already mentioned malloc() et al. as the
library functions most often replaced, usually for debugging.
I myself have replaced the entire *printf() family for
performance reasons, and once found it necessary to replace
sqrt() to avoid a bug in the library's version.

However good your reason or compelling your need, though,
once you've done such a thing the Standard no longer governs
the behavior of your program. The Standard cannot send you
to jail for misbehaving, but it can and does withhold its
guarantees: it declines to describe the behavior of a program
that violates its preconditions. `extern double malloc;' has
the same effect as `extern void stdout();' -- each removes its
program from the set of programs whose behavior the Standard
describes, and all bets are off.

The purpose of standardizing functions is not to lock the user
in and prohibit them from using other implimentations.

Its purpose is to describe a language and library, in
such a way that a programmer can use them and be confident
of the program's behavior. The programmer can, for example,
use `asm' and `fortran' and `new' as identifiers without
worrying that some C implementation somewhere will claim
they are keywords; implementations are forbidden to invade
the programmer's name space.

Equally, programmers are forbidden to muck about with
the implementation; the implementors need room to work in
as well. The programmer who strays into the implementation's
name space is out of bounds. He may escape unharmed -- he
may even gain some benefit -- but if the border guards shoot
him on sight he has no grounds for complaint.

 

[CBFalconer]

.... snip ...

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.

I think you are confused about the linker action. A multipass
linker will read all the object modules and resolve their addresses
on the first pass, and then resolve all references on the second
pass. This is much like the normal operation of an assembler.

A single pass linker will input code modules and prepare its own
internal list of fixups required, while recording the addresses of
defined modules. When a module is defined the existing fixups are
performed. How to get at the already linked code to perform that
fixup may be a problem.

However the linker treats libraries differently in that it does not
load a module, or record its address, unless it is needed to
resolve some existing reference. Thus the library loading order
becomes important, and even the module order within that library,
for single pass linkers.

 

[CBFalconer]

Let me save you some trouble:

I will be posting on matters which are widely considered "off-topic".
If you don't want to read those messages, feel free to killfile me.

I have noticed that some people in this newsgroup (I don't
particularily recall you being one of them) react to questions they
consider to be "off-topic" with what I can only term rudeness. I
can't do anything about those people, but I can instead choose to
provide answers that are a bit more useful. Some people have
essentially said "If you don't like the way answers are given here,
feel free to give your own answers" -- so I am.

That is not the point. I have recently been guilty of posting
off-topic material in this very thread in response to your
misapprehension of some points. The point is that any of this is
likely to go uncorrected, because this group specializes in the C
language proper, and not in ancilliary matters. There are other
groups with people with more knowledge of linkers than either you
or I, and those are groups suitable for this matter. In such a
group erroneous articles will rapidly get corrected, here they will
often not be even noticed as erroneous.

So you are not helping anybody by posting off-topic material, you
are more likely to simply spread even more FUD. At the same time
you are doing harm to the concentrated theme of this particular
newsgroup. There is nothing rude in saying "we don't know, but try
down the road". There is something very rude in saying "I don't
care, I will just bull my way in here anyhow" and wasting
bandwidth.

 

[Richard Harter]

Why not just post in appropriate newsgroups? Your deciding to purposely
engage in anti-social behavior is curious.


There is no such thing as rudeness to people who knowingly post
off-topic. They -- and we now know that you are among them -- are
engaging in among the most rude behavior possible on usenet; they are
the scum of the earth.

Pot. Kettle. Your posting is by far ruder, cruder, and more
anti-social than anything Roberson has posted.

Yes, you can. Stop your offensive behavior.

Please stop yours.


Richard Harter, (e-mail address removed)
http://home.tiac.net/~cri, http://www.varinoma.com
All my life I wanted to be someone;
I guess I should have been more specific.

 

[Keith Thompson]

You're funny. Keep it up.

You're not. Don't.

 

[Keith Thompson]

I do not yet agree that the standard itself says that the attempt is
prohibitted [as opposed to saying YMMV], but I will have another
look at the wording of the standard itself, and of the Rationale,
and possibly my interpretation will change.

It's not exactly prohibited, just as dereferencing a null pointer is
not prohibited. In both cases, the implementation is not required
either to diagnose it as an error or to behave in any predictable
fashion.

 

[Flash Gordon]

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.

 

[Alan Balmer]

: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.

 

[Kenny McCormack]

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]

: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?