unofficial mirror of libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Martin Sebor <msebor@gmail.com>
To: Florian Weimer <fweimer@redhat.com>, "H.J. Lu" <hjl.tools@gmail.com>
Cc: GNU C Library <libc-alpha@sourceware.org>, msebor@redhat.com
Subject: Re: [PATCH] Don't pass NULL pointer to error [BZ #24556]
Date: Thu, 23 May 2019 10:21:17 -0600	[thread overview]
Message-ID: <ff5c5b6e-18a3-ff18-ffc4-31e0ae8aa2de@gmail.com> (raw)
In-Reply-To: <87mujdw54b.fsf@oldenburg2.str.redhat.com>

On 5/23/19 9:41 AM, Florian Weimer wrote:
> * H. J. Lu:
> 
>> On Thu, May 23, 2019 at 8:20 AM Florian Weimer <fweimer@redhat.com> wrote:
>>>
>>> * H. J. Lu:
>>>
>>>> On Thu, May 23, 2019 at 12:02 AM Florian Weimer <fweimer@redhat.com> wrote:
>>>>>
>>>>> * H. J. Lu:
>>>>>
>>>>>> In function ‘error’,
>>>>>>      inlined from ‘do_one_test’ at bench-strstr.c:149:7,
>>>>>>      inlined from ‘do_test’ at bench-strstr.c:201:5,
>>>>>>      inlined from ‘test_main’ at bench-strstr.c:220:2:
>>>>>> ../include/bits/../../misc/bits/error.h:42:5: error: ‘%s’ directive argument is null [-Werror=format-overflow=]
>>>>>>     42 |     __error_alias (__status, __errnum, __format, __va_arg_pack ());
>>>>>>        |     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>>>
>>>>> Isn't this warning wrong for glibc in general (but not for
>>>>> _dl_debug_printf)?
>>>>>
>>>>> I think printing "(null)" for null pointers is a widely-used GNU
>>>>> extension.
>>>>
>>>> Only for limited cases:
>>>>
>>>> [hjl@gnu-cfl-1 tmp]$ cat x.c
>>>> #include <stdio.h>
>>>>
>>>> char *p;
>>>>
>>>> int
>>>> main ()
>>>> {
>>>>    printf("null string:%s\n", p);
>>>>    printf ("%s\n", p);
>>>>    return 0;
>>>> }
>>>> [hjl@gnu-cfl-1 tmp]$ gcc x.c
>>>> [hjl@gnu-cfl-1 tmp]$ ./a.out
>>>> null string:(null)
>>>> Segmentation fault
>>>> [hjl@gnu-cfl-1 tmp]$
>>>
>>> Ah, because GCC transforms printf with "%s\n" to puts?  Hmm.
>>>
>>
>> Yes.
> 
> We document the printf behavior:
> 
> |    If you accidentally pass a null pointer as the argument for a ‘%s’
> | conversion, the GNU C Library prints it as ‘(null)’.  We think this is
> | more useful than crashing.  But it’s not good practice to pass a null
> | argument intentionally.
> 
> So we should perhaps fix puts to behave in the same way.  (puts isn't
> even annotated with __nonnull today.)

There are two transformations that don't handle null pointers: printf
to puts and sprintf to strcpy (or memcpy).  They have been in GCC since
at least 2005, and in Clang since at least 2011.  I'd rather discourage
relying on the Glibc printf extension than remove the transformations
or suppress the warning.

Martin

  reply	other threads:[~2019-05-23 16:21 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-22 22:40 [PATCH] Don't pass NULL pointer to error [BZ #24556] H.J. Lu
2019-05-23  7:02 ` Florian Weimer
2019-05-23 14:57   ` H.J. Lu
2019-05-23 15:20     ` Florian Weimer
2019-05-23 15:28       ` H.J. Lu
2019-05-23 15:41         ` Florian Weimer
2019-05-23 16:21           ` Martin Sebor [this message]
2019-05-23 19:35             ` Paul Eggert
2019-06-17 19:32               ` H.J. Lu
2019-06-18  7:10                 ` Stefan Liebler

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://www.gnu.org/software/libc/involved.html

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

  git send-email \
    --in-reply-to=ff5c5b6e-18a3-ff18-ffc4-31e0ae8aa2de@gmail.com \
    --to=msebor@gmail.com \
    --cc=fweimer@redhat.com \
    --cc=hjl.tools@gmail.com \
    --cc=libc-alpha@sourceware.org \
    --cc=msebor@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).