This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: strtok behaviour when uninitialized
- From: Zack Weinberg <zackw at panix dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Sun, 11 Feb 2018 14:32:49 -0500
- Subject: Re: strtok behaviour when uninitialized
- Authentication-results: sourceware.org; auth=none
- References: <20180211181954.l5qkzway7zkd3345@salil> <878tbzwetl.fsf@linux-m68k.org> <20180211185345.jqcfijuchzkowkcx@salil> <1518376085.12525.187.camel@sempati.menos4>
On Sun, Feb 11, 2018 at 2:08 PM, Javier Serrano Polo <javier@jasp.net> wrote:
> El dg 11 de 02 de 2018 a les 13:53 -0500, Salil Kapur va escriure:
>> Why keep it undefined?
>
> Undefined behavior means efficiency. The most efficient implementation
> will either crash or not.
With my security hat on, I would like glibc to define as many cases of
undefined behavior as possible -- as prompt, guaranteed crashes.
Defining the behavior as anything else leads to people relying on
whatever the definition is, but leaving it as "whatever the code
happens to do" _also_ leads to people relying on the actual behavior,
plus it leaves room for exploits.
(I'd make an exception for memory copies: I think those should _all_
be defined by us to behave as-if by calling memmove(). Yes, really.
Yes, including memcpy.)
zw