Re: strtok behaviour when uninitialized

[Ondřej Bílka <neleai at seznam dot cz>]

On Sun, Feb 11, 2018 at 02:32:49PM -0500, Zack Weinberg wrote:
> 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.)
>
for copy abort is better, as it isn't clear if programer knew what he
was doing and he should use memmove if he checked that overlap is ok.

Adding that would be relatively easy if there weren't legacy
applications where we supported buggy behaviour. 

For x64 it depends on action, for performance sizes upto 128 bytes are
done as load all src to registers, then write all to register so check
happens only on branch larger than 128 bytes.

I think that aliasing memcpy to memmove (code in nonoverlap case is same)
would be faster but its hard to
qualify as bonus is from smaller instruction cache etc, only problematic
part is branch misprediction in check(on my comp around 30% of larger memmove
calls actually overlap)