This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: remote XOpenDisplay in Solaris (SunOS 5.6)


Well, I guess that's why it's good form to prefix function names
with an abbreviation based on the module- or application-name.

In contrast, I was able to get some degree of control (not much)
over Motif's nonsensical stacking order by #define-ing XtManageChild
and XtUnmanageChild to have my own function calls intercept them
before handing them off to these undisciplined (and downright
hostile and obstinate) functions.

----- Original Message -----
From: David Korn <dkorn@pixelpower.com>
To: 'Jerry Miller' <gmiller@cs.sunysb.edu>; <help-gcc@gnu.org>
Sent: Wednesday, February 28, 2001 10:31 AM
Subject: RE: remote XOpenDisplay in Solaris (SunOS 5.6)


> >-----Original Message-----
> >From: Jerry Miller [mailto:gmiller@cs.sunysb.edu]
> >Sent: 28 February 2001 14:07
>
> >That did it!  Thank you!
>
>   Hooray!!
>
> >I hadn't experimented enough with gdb to realize that the
> >"up" command was virtually equivalent to the PL/I tracebacks
> >I used to rely on.  When I discovered that my function
> >putmsg was being called by a shared-library routine, I did a
> >"man putmsg," and sure enough, there was a conflict there!
>
>   There's also the 'bt' command, which lists the entire stack all the way
> back to the program entry point for you.
>
> >Making it a static local function and renaming it for good
> >measure has solved this mysterious problem.
>
>   Argh!  Whoever invented the notion that DSOs could have unresolved
> symbols in them is a maniac who should be shot through the ears.  Despite
> the fact that the price of disk storage has fallen through the floor, it
> is seemingly so important to save a few meg here and there that we have
> arrived in a situation where nobody except the linker can even begin to
> guess what function is actually going to be called by a function call.  It
> might perhaps be not quite so bad if unresolved syms in DSOs could only
> be resolved by syms from other libs, but the thought that a DSO can
contain
> an unresolved reference to a system function that ends up getting linked
to
> your own application is just annoying.  I'm used to systems where you can
> write a function called printf and that's what you'll get when your app.
> calls printf, but I'm just not used to the notion that the C runtime
library
> might suddenly start calling your function instead of it's own.
>
>        DaveK
> --
>  All your base are belong to us!
>
>
> **********************************************************************
> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they
> are addressed. If you have received this email in error please notify
> the system manager.
>
> This footnote also confirms that this email message has been swept by
> MIMEsweeper for the presence of computer viruses.
>
> www.mimesweeper.com
> **********************************************************************
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]