🚀 go-pugleaf

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