bug-gnulib@gnu.org mirror (unofficial)
 help / color / mirror / Atom feed
From: Bruno Haible <bruno@clisp.org>
To: Assaf Gordon <assafgordon@gmail.com>
Cc: Florian Weimer <fweimer@redhat.com>, bug-gnulib@gnu.org
Subject: Re: new module suggestion: fprintftime-check
Date: Sat, 29 Dec 2018 07:08:12 +0100	[thread overview]
Message-ID: <3472199.bSzxmTJ3n3@omega> (raw)
In-Reply-To: <a90c465a-d7a3-e394-5a3f-d7488be9ab6c@gmail.com>

[CCing Florian Weimer.
Florian, the thread started at
https://lists.gnu.org/archive/html/bug-gnulib/2018-12/msg00149.html ]

Assaf Gordon wrote:
> The comment even says:
>        /* Unknown format; output the format, including the '%',
>           since this is most likely the right thing to do if a
>           multibyte string has been misparsed.  */
> 
> This has been the case since 1996 when strftime.c was imported from libc
> (gnulib commit afabd949).
> 
> I suspect that changing this behavior would be a disruptive
> backwards-incompatible change (but other opinions are welcomed).

The "security" and "robustness" aspects of software have gained importance
over the last 22 years, also in domain of glibc.

Florian, Assaf discovered that glibc processing of time format strings
(strftime) operates according to the garbage-in - garbage-out principle,
that is, an invalid format string does not get reported to the caller
but instead produces output that is "most likely the right thing".

Is this still considered the adequate processing, from a glibc point of
view?

Bruno



  reply	other threads:[~2018-12-29  6:08 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-28 10:49 new module suggestion: fprintftime-check Assaf Gordon
2018-12-28 16:34 ` Bruno Haible
2018-12-28 20:09   ` Assaf Gordon
2018-12-29  6:08     ` Bruno Haible [this message]
2018-12-29 15:21       ` Assaf Gordon
2019-01-02  8:03       ` Florian Weimer
2019-01-05 10:40         ` Bruno Haible
2019-01-05 12:43           ` Florian Weimer
2018-12-29 17:22     ` Paul Eggert
2018-12-29 17:48       ` Ben Pfaff
2018-12-31  1:40         ` Paul Eggert
2019-01-05 10:37           ` preferring ptrdiff_t to size_t Bruno Haible

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

  List information: https://lists.gnu.org/mailman/listinfo/bug-gnulib

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

  git send-email \
    --in-reply-to=3472199.bSzxmTJ3n3@omega \
    --to=bruno@clisp.org \
    --cc=assafgordon@gmail.com \
    --cc=bug-gnulib@gnu.org \
    --cc=fweimer@redhat.com \
    /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).