|
Bugzilla – Full Text Bug Listing |
| Summary: | gcc / libstdc++ allocator | ||
|---|---|---|---|
| Product: | [openSUSE] SUSE Linux 10.1 | Reporter: | Dirk Mueller <dmueller> |
| Component: | Basesystem | Assignee: | Michael Matz <matz> |
| Status: | RESOLVED WONTFIX | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | development-gcc |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | Other | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
|
Description
Dirk Mueller
2005-10-24 05:29:47 UTC
(In reply to comment #0) > did we think about this? It is not an option, according to our policy wrt binary compatibility: we even have a PR about this, libstdc++/21072, which includes a straightforward testcase: basically you cannot allocate with an allocator and deallocate with a different one. Those distributions broke binary compatibility. We want to do that? Also, in retrospect, we are "lucky" because that allocator is still not stable (see libstdc++/22309, 23591, 24469) and is affected by most of the usual problems of pooled allocators - e.g., memory is not released until the exit of the program - we discussed that on the list and we don't want it by default if only because of this. ok, then, I guess. |