verbose terminate() on by default

[Gabriel Dos Reis]

Alexandre Oliva <aoliva@redhat.com> writes:

| On Dec 23, 2002, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
| 
| > Alexandre Oliva <aoliva@redhat.com> writes:
| > | On Dec 23, 2002, Phil Edwards <phil@jaj.com> wrote:
| > | 
| > | > On Mon, Dec 23, 2002 at 02:06:47PM -0200, Alexandre Oliva wrote:
| > | >> 
| > | >> Dynamic linking is not always available on embedded systems, where
| > | >> code size matters the most.  The verbose implementation may bring in a
| > | >> lot of stuff that the developer may have tried hard to avoid using.
| > | 
| > | > Yeah, we should do something special with freestanding environments.
| > | 
| > | Embedded != freestanding.  Not having fprintf is one thing, preferring
| > | not to use it is an entirely different matter.
| 
| > Then it is *its* responsability to set the default handler to suit its
| > needs.  
| 
| Precisely, but this won't prevent the then-unused junk from taking up
| space, in case the program references anything else from the same
| module so as to bring it in.

If thge program doesn't reference __verbose_terminate_handler, then it
won't be brought in.  If it references it, then it is because it needs
it. 

| I.e., my program calls unexpected, so
| the module in which the variables that point to the unexpected and the
| terminate handlers is brought in.  Since this module references the
| verbose terminate, this function and everything it needs is brought
| into the executable, even though the definition of the terminate
| handler is overridden in the main program.  There's no way to avoid it.

Sure there is.  What are we talking about?  About speculative embedded
system that doesn't want __verbose_terminate_handler or about real
world application?

-- Gaby