public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libstdc++/39796] New: cin/cout/cerr constructors should run at high priority when possible
@ 2009-04-17 14:26 ian at airs dot com
2009-04-17 15:06 ` [Bug libstdc++/39796] " paolo dot carlini at oracle dot com
` (2 more replies)
0 siblings, 3 replies; 6+ messages in thread
From: ian at airs dot com @ 2009-04-17 14:26 UTC (permalink / raw)
To: gcc-bugs
libstdc++ ensures that cin/cout/cerr are constructed before they are used, but
the scheme fails when using constructor priorities. Constructors with a
priority are run before constructors without a priority, which is the
appropriate behaviour. However, this means that this program:
#include <iostream>
void f1() __attribute__ ((constructor (101)));
void f1() { std::cout << "f1" << std::endl; }
int main() { }
will crash at runtime. f1 will be run at a user level priority, but it will
run before std::cout is initialized.
I suggest that on systems which support constructor priorities, that we arrange
to run ios_base::Init::Init() at a high priority. The destructor should also
be run at a high priority, of course.
--
Summary: cin/cout/cerr constructors should run at high priority
when possible
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ian at airs dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39796
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug libstdc++/39796] cin/cout/cerr constructors should run at high priority when possible
2009-04-17 14:26 [Bug libstdc++/39796] New: " ian at airs dot com
@ 2009-04-17 15:06 ` paolo dot carlini at oracle dot com
2009-04-18 5:40 ` ian at airs dot com
2009-04-21 2:47 ` bkoz at gcc dot gnu dot org
2 siblings, 0 replies; 6+ messages in thread
From: paolo dot carlini at oracle dot com @ 2009-04-17 15:06 UTC (permalink / raw)
To: gcc-bugs
------- Comment #1 from paolo dot carlini at oracle dot com 2009-04-17 15:06 -------
I see. I would be tempted to ask you to propose a fix at once, seems pretty
simple, basically a bit of configury and very few lines of actual code.
However, I wonder if we have something similar elsewhere, I seem to remember
something for the memory allocators, for example, but possibly by now we have
static locals everywhere to avoid completely running into such priority issues.
Another area which probably should be audited is that of locale. What do you
think?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39796
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug libstdc++/39796] cin/cout/cerr constructors should run at high priority when possible
2009-04-17 14:26 [Bug libstdc++/39796] New: " ian at airs dot com
2009-04-17 15:06 ` [Bug libstdc++/39796] " paolo dot carlini at oracle dot com
@ 2009-04-18 5:40 ` ian at airs dot com
2009-04-21 2:47 ` bkoz at gcc dot gnu dot org
2 siblings, 0 replies; 6+ messages in thread
From: ian at airs dot com @ 2009-04-18 5:40 UTC (permalink / raw)
To: gcc-bugs
------- Comment #2 from ian at airs dot com 2009-04-18 05:40 -------
You are much more familiar with the library than I am. I don't know if this
issue arises anywhere else. cin/cout/cerr is sort of an obvious case. It
didn't really occur to me that there might be similar issues elsewhere.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39796
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug libstdc++/39796] cin/cout/cerr constructors should run at high priority when possible
2009-04-17 14:26 [Bug libstdc++/39796] New: " ian at airs dot com
2009-04-17 15:06 ` [Bug libstdc++/39796] " paolo dot carlini at oracle dot com
2009-04-18 5:40 ` ian at airs dot com
@ 2009-04-21 2:47 ` bkoz at gcc dot gnu dot org
2 siblings, 0 replies; 6+ messages in thread
From: bkoz at gcc dot gnu dot org @ 2009-04-21 2:47 UTC (permalink / raw)
To: gcc-bugs
------- Comment #3 from bkoz at gcc dot gnu dot org 2009-04-21 02:46 -------
I consider this undefined behaviour, so enhancement is the correct severity.
People wanting to mess with non-standard init order should probably be taking
steps to insure that libstdc++ is initialized first anyway. Not doing so is
arguably a bug..... especially as it's not hard to do:
ie:
#include <iostream>
void f1() __attribute__ ((constructor (101)));
void f1()
{
std::ios_base::Init i;
std::cout << "f1" << std::endl;
}
int main() { }
But anyway........
libstdc++ is currently not using the first 100 slots reserved for the GNU
implementation as per:
http://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Attributes.html#C_002b_002b-Attributes
No efforts or audit have ever been made as to enshrine a specified init order
for libstd++. Locales, mutexes, and __mt_allocator would all have to be scoped
and modified as code is/was changed. I consider this doable, but probably as
much work in the long run as the efforts for symbol versioning. There may be an
advantage to doing this for size reasons, as then <iostream>'s
// For construction of filebuffers for cout, cin, cerr, clog et. al.
static ios_base::Init __ioinit;
could be killed.
If there was some kind of real advantage, I would be more into this whole idea.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39796
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2023-02-03 19:49 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <bug-39796-4@http.gcc.gnu.org/bugzilla/>
2012-01-03 16:41 ` [Bug libstdc++/39796] cin/cout/cerr constructors should run at high priority when possible redi at gcc dot gnu.org
2022-11-06 16:16 ` cvs-commit at gcc dot gnu.org
2023-02-03 19:49 ` pinskia at gcc dot gnu.org
2009-04-17 14:26 [Bug libstdc++/39796] New: " ian at airs dot com
2009-04-17 15:06 ` [Bug libstdc++/39796] " paolo dot carlini at oracle dot com
2009-04-18 5:40 ` ian at airs dot com
2009-04-21 2:47 ` bkoz at gcc dot gnu dot org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).