public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "bugdal at aerifal dot cx" <sourceware-bugzilla@sourceware.org>
To: glibc-bugs@sourceware.org
Subject: [Bug libc/16060] New: dprintf fails to be async-signal safe
Date: Thu, 17 Oct 2013 19:31:00 -0000	[thread overview]
Message-ID: <bug-16060-131@http.sourceware.org/bugzilla/> (raw)

https://sourceware.org/bugzilla/show_bug.cgi?id=16060

            Bug ID: 16060
           Summary: dprintf fails to be async-signal safe
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: bugdal at aerifal dot cx
                CC: drepper.fsp at gmail dot com

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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.


             reply	other threads:[~2013-10-17 19:31 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-17 19:31 bugdal at aerifal dot cx [this message]
2014-06-13 12:38 ` [Bug libc/16060] " fweimer at redhat dot com
2014-08-13  4:50 ` f.deldegan at gmail dot com
2015-08-23  1:16 ` [Bug stdio/16060] " jsm28 at gcc dot gnu.org
2020-07-07 14:54 ` cvs-commit at gcc dot gnu.org
2022-08-30  8:23 ` cvs-commit at gcc dot gnu.org
2022-08-30  8:45 ` cvs-commit at gcc dot gnu.org
2022-08-30  9:20 ` cvs-commit at gcc dot gnu.org
2022-08-30 11:07 ` cvs-commit at gcc dot gnu.org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-16060-131@http.sourceware.org/bugzilla/ \
    --to=sourceware-bugzilla@sourceware.org \
    --cc=glibc-bugs@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).