William Ahern <
william@25thandClement.com> writes:
I just read through N2471, a proposal to add signal guards to C and C++:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2471.pdf
One of the stated goals is to be able to catch OOM events in C++ code that
no longer throws C++-style exceptions on allocation failure. See, e.g., sec. 1.1 item 4.
However, the proposal disallows invoking async signal safe functions within guarded code sections. Sec. 3.
Traditionally the "default allocator" in C++ uses malloc, and malloc is not async signal safe. E.g, "on Microsoft Windows, many of the Win32 APIs which appear equivalent to POSIX ones in the list above are NOT async signal safe because they call malloc() e.g. CreateFile()." ibid.
The prohibition on async signal functions in tandem with the expectation
(and goal) for guarded code to use the C++ new operator seems incongruous. I realize that the new operator is technically a black box; strictly speaking malloc being async signal safe is irrelevant to the async signal safety of the C++ new operator (at least from the perspective of the C standard). But it leaves me with a suspicion that some very important aspects of this proposal haven't been clearly thought through. Even the proposal seems to equivocate dynamic memory allocation with async signal safety: "potential dynamic memory allocation equals lack of async signal safety." ibid.
Am I alone? Am I missing something?
Perhaps the best way I might answer this question is to say I
don't have any confidence in the proposal. About the best I can
say for it is they make it clear that they don't like what Posix
does in this area. Almost everything else they say is not clear,
at least not to me. In response to your suspicion that "some
very important aspects of this proposal haven't been clearly
thought through", well, for me, suspicion is too mild a word; I
believe many aspects of this proposal have not been clearly
thought through, and very likely some of the more important
or most important ones are included in that.
Incidentally, the phrasing of the sentence with "equivocate" in
it seems a bit off to me. What I think you mean is the proposal
is confused about the question of whether dynamic memory
allocation is async signal safe. If that is what you mean, I got
it, but it took me several minutes to get there. And if that is
not what you mean then I don't know what you mean. (None of that
affects my reaction to the proposal.)
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)