Bug 16060 - dprintf fails to be async-signal safe
Summary: dprintf fails to be async-signal safe
Status: NEW
Alias: None
Product: glibc
Classification: Unclassified
Component: stdio (show other bugs)
Version: unspecified
: P2 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-10-17 19:31 UTC by Rich Felker
Modified: 2016-06-03 15:21 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:
fweimer: security-


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Rich Felker 2013-10-17 19:31:27 UTC
This is NOT a conformance bug, as POSIX does not require dprintf to be AS-safe or even mention it as an option. However, Roland McGrath has stated on libc-alpha that, as the original inventor of this interface, he intended it to be AS-safe and in general not to have unnecessary failure cases. At present, dprintf fails to be AS-safe for at least the following reasons:

1. It adds and removes the temporary FILE structure it creates to/from the global open streams list, requiring a lock. This operation is entirely unnecessary and nonsensical (and also documented in bug #12847).

2. The printf core uses malloc in various places (wide string conversion, i18n %n$ arguments, ...). Fixing these uses is less trivial, and may not matter to the most common usage cases for dprintf which are unlikely to hit the code paths that use malloc, but they are bugs in themselves anyway (unnecessary failure cases for the entire printf family) which should be fixed.

There may also be other AS-safety issues I am unaware of.