I'm trying to figure out under what circumstances a program can supply
a definition for a library function.  Is it the case that a program
cannot supply a definition for any library function except for those
listed in 17.3.3.4 (new & delete with various signatures)?

In other words (typos not withstanding), is

#include <string.h>

int std::strlen(const char*) { ... }

legal?  What if <string.h> is not included?

(As an aside, what's the 'C' standard have to say about this?)

Thanks,

--
Michael Greenberg                      email: mgreenberg@scr.siemens.com
Siemens Corporate Research             phone: 609-734-3347
755 College Road East                  fax: 609-734-6565
Princeton, NJ 08540

[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

mlg@scr.siemens.com (Michael Greenberg) writes:

>I'm trying to figure out under what circumstances a program can supply
>a definition for a library function.  Is it the case that a program
>cannot supply a definition for any library function except for those
>listed in 17.3.3.4 (new & delete with various signatures)?

That is correct. You cannot extend the "std" namespace, and the names
of the library functions are reserved except as noted.

The reason for the rule is to ensure 3rd-party libraries, and indeed the
implementation-supplied runtime library, can depend on the operation
of the standard functions. If you were allowed to replace them, there
could be no guarantees. (It also allows implementors maximum
freedom in implementing the library, since replacing functions
need not be considered.)

Example: A program used in religious education has a function that
analyzes answers to moral questions via an index and determines the
degree of "sin" involved. If the function were called "sin", that
could create havoc in other parts of the program that attempted to do
trigonometric calculations.

The rule does not mean an implementation must prevent you from
trying to replace library functions. Indeed, it is often
possible to do so for selected functions. You just cannot depend
on being able to do it, particularly in portable code. Such a
program might not compile, might compile but not link, might
link but not run correctly.

>(As an aside, what's the 'C' standard have to say about this?)

No functions in the C library may be replaced. All the names are
reserved.
--
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]

In article <DM2Bv9.C7p@scr.siemens.com> mlg@scr.siemens.com (Michael
Greenberg) writes:

|> I'm trying to figure out under what circumstances a program can supply
|> a definition for a library function.  Is it the case that a program
|> cannot supply a definition for any library function except for those
|> listed in 17.3.3.4 (new & delete with various signatures)?

The only library functions that the user can replace are those where
it says explicitly that they can be replaced: operator new, operator
delete, unexpected and terminate.

 [ Moderator's note: Michael Greenberg is correct: only new and   ]
 [ delete can be replaced.  The user is not allowed to supply     ]
 [ definitions for unexpected() and terminate(), although a       ]
 [ similar effect can be obtained by calling set_unexpected() and ]
 [ set_terminate().  -fjh.                                        ]

|> In other words (typos not withstanding), is

|> #include <string.h>

|> int std::strlen(const char*) { ... }

|> legal?  What if <string.h> is not included?

Illegal, with or without string.h.

|> (As an aside, what's the 'C' standard have to say about this?)

Basically the same thing, except that there are no user replaceable
functions.  The compiler is allowed to know the semantics of all of
the library functions (and the restrictions concerning the semantics
of the replaceable functions), and take advantage of them in its
optimizations.  (The most obvious case: the compiler knows that none
of these functions access any of your global variables, so it may
maintain the global variables in a register accross calls to the
function.  I have already used a C compiler that did this.)

--
James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils, itudes et rialisations en logiciel orienti objet --
                -- A la recherche d'une activiti dans une region francophone
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]