This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Slightly better way to __USE_MALLOC


On Wed, Oct 09, 2002 at 06:27:17PM -0500, Loren James Rittle wrote:
> 
> Hi Brad,
> 
> A patch that rid us entirely of an ABI-affecting macro would be
> perfect but you already noted that your patch wasn't perfect... ;-)

Hehe :)

> However, I am afraid that you didn't test well enough the various
> cases which exist.  Please try compiling your posted test case at -O2
> (and of course removing the c++config check I added, and as you
> propose to do with your patch).  The program is linkable without an
> error yet there is a mismatch between memory allocation
> implementations.  I will post a multi-file test case which blows up
> when compiled in a mismatched manner, if it will help you fully
> understand the broader issue.

You are compiling some objects with the macro and some without, I
presume.  If you could post it (or send it to me directly), I'll see
what I can do about it.  I actually spent some time trying to inject
different unresolved symbols into all objects compiled under either
circumstance and make them present only in the library compiled under
the same circumstances.  I stopped, however, when I (mistakenly?)
realized that the allocator templates instances themselves (in
stl-inst.cc) would serve that purpose.  I must be missing something
more exotic :(

> The check was added due to user reports of non-detectable errors (of
> course, we had to figure out what the root issue was since it wasn't
> obvious at first).  I really don't want to make it easy for users to
> build a program with a non-detectable (at build-time) error.

I completely agree with this and, as I said, I tried to achieve this.

> All that said, please continue to work on this problem, if you can.
> Don't worry about the form the patch needs to be in to commit; I can
> help with all that cleanup later.

Ok, thanks!  I'll see what I can work out in the mean time.

-- 
------------------------------------------------------------------
Brad Spencer - spencer@infointeractive.com - "It's quite nice..."
Systems Architect | InfoInterActive Corp. | A Canadian AOL Company


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