git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@osdl.org>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Junio C Hamano <junkio@cox.net>,
	Mike McCormack <mike@codeweavers.com>,
	git@vger.kernel.org
Subject: Re: [PATCH] Add git-imap-send.
Date: Thu, 9 Mar 2006 08:41:16 -0800 (PST)	[thread overview]
Message-ID: <Pine.LNX.4.64.0603090836030.18022@g5.osdl.org> (raw)
In-Reply-To: <Pine.LNX.4.63.0603091227560.20277@wbgn013.biozentrum.uni-wuerzburg.de>



On Thu, 9 Mar 2006, Johannes Schindelin wrote:
> > 
> > > +		if (!memcmp( "imaps:", val, 6 )) {
> > > +			if (!memcmp( "imap:", val, 5 ))
> > 
> > Is val always longer than 5 or 6 bytes here?
> 
> That does not matter, since they are strings, and the memcmp should not 
> look further if they are shorter (because the comparison to '\0' failed 
> already).

No.

It's true that any sane memcmp() will stop when it notices a difference, 
and it's also true that the return value semantics of memcmp() means that 
it has to walk beginning-to-end.

HOWEVER. The key phrase is "_when_ it notices a difference".

It's quite common for optimized memcmp()'s to do things like loading 
several words from both the source and the destinations, and testing them 
together, and only start doing the byte-by-byte comparison when the "big" 
comparison has failed.

So when you do a

	if (!memcmp(string, mystring, mystringlength))
		...

it's entirely possible that it will load bytes from "string" _past_ the 
end of the string because of an unrolled inner loop that does things 
multiple bytes at a time. They won't be used in the eventual result, but 
just the fact that they are loaded from memory can mean that your program 
takes a SIGSEGV, for example, becaue it turns out "string" was just a 
single NUL byte at the end of a page, and there's nothing after it.

IOW, it's a bad optimization.

Use "strncmp()" instead. Yes, it can be slower, exactly because it has to 
check more, but it checks more exactly because memcmp() can cause 
undefined behaviour by running off the end of a string.

		Linus

  parent reply	other threads:[~2006-03-09 16:41 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-06 13:09 [PATCH] Add git-imap-send Mike McCormack
2006-03-09 10:35 ` Junio C Hamano
2006-03-09 11:30   ` Johannes Schindelin
2006-03-09 11:39     ` Andreas Ericsson
2006-03-09 11:44       ` Johannes Schindelin
2006-03-09 13:26         ` Mark Wooding
2006-03-09 13:47           ` Johannes Schindelin
2006-03-10  0:38             ` Mark Wooding
2006-03-09 16:41     ` Linus Torvalds [this message]
2006-03-09 18:09       ` Junio C Hamano
2006-03-09 18:21         ` Linus Torvalds
2006-03-09 18:49           ` Junio C Hamano
2006-03-10  4:58   ` Mike McCormack

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=Pine.LNX.4.64.0603090836030.18022@g5.osdl.org \
    --to=torvalds@osdl.org \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=junkio@cox.net \
    --cc=mike@codeweavers.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 NNTP newsgroup(s).