public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "pcarlini at suse dot de" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/17038] New: ABI impacting issue in time_put Date: Sun, 15 Aug 2004 19:16:00 -0000 [thread overview] Message-ID: <20040815191648.17038.pcarlini@suse.de> (raw) This is an internal reminder: most probably we have to change _M_put to return an integer, otherwise we'll be never able to succesfully complete the output when the buffer is too small (> 64 chars, currently). These notes in the glibc docs about strftime (and wcsftime) will be useful in dealing correctly with the issue: The SIZE parameter can be used to specify the maximum number of characters to be stored in the array S, including the terminating null character. If the formatted time requires more than SIZE characters, `strftime' returns zero and the contents of the array S are undefined. Otherwise the return value indicates the number of characters placed in the array S, not including the terminating null character. _Warning:_ This convention for the return value which is prescribed in ISO C can lead to problems in some situations. For certain format strings and certain locales the output really can be the empty string and this cannot be discovered by testing the return value only. E.g., in most locales the AM/PM time format is not supported (most of the world uses the 24 hour time representation). In such locales `"%p"' will return the empty string, i.e., the return value is zero. To detect situations like this something similar to the following code should be used: buf[0] = '\1'; len = strftime (buf, bufsize, format, tp); if (len == 0 && buf[0] != '\0') { /* Something went wrong in the strftime call. */ ... } If S is a null pointer, `strftime' does not actually write anything, but instead returns the number of characters it would have written. -- Summary: ABI impacting issue in time_put Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P2 Component: libstdc++ AssignedTo: pcarlini at suse dot de ReportedBy: pcarlini at suse dot de CC: gcc-bugs at gcc dot gnu dot org GCC host triplet: Any http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17038
next reply other threads:[~2004-08-15 19:16 UTC|newest] Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top 2004-08-15 19:16 pcarlini at suse dot de [this message] 2004-08-16 0:01 ` [Bug libstdc++/17038] " pinskia at gcc dot gnu dot org 2004-08-25 23:38 ` cvs-commit at gcc dot gnu dot org 2004-08-27 13:30 ` cvs-commit at gcc dot gnu dot org 2004-08-28 19:23 ` cvs-commit at gcc dot gnu dot org 2004-08-29 0:49 ` pinskia at gcc dot gnu dot org 2004-08-29 8:49 ` pcarlini at suse dot de 2004-12-02 2:11 ` pinskia at gcc dot gnu dot org 2004-12-02 9:29 ` pcarlini at suse dot de 2004-12-08 23:31 ` pcarlini at suse dot de
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=20040815191648.17038.pcarlini@suse.de \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.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: linkBe 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).