From: John Keeping <john@keeping.me.uk>
To: git@vger.kernel.org
Cc: Junio C Hamano <gitster@pobox.com>, John Keeping <john@keeping.me.uk>
Subject: [PATCH 0/2] Fixes for undefined behaviour
Date: Tue, 2 Apr 2013 20:50:30 +0100 [thread overview]
Message-ID: <cover.1364931627.git.john@keeping.me.uk> (raw)
I've been playing with Clang's undefined behaviour sanitizer, which
points out a few potential issues in Git when running the test suite
(it's a runtime analysis that is compiled in by setting suitable
CFLAGS).
These patches fix one issue that I think we need to worry about and one
that's trivial to fix.
The remaining warnings are:
refs.c:2426:17: runtime error: index -1 out of bounds for type 'char [8192]'
Caused by a loop walking backwards over the reflog which sets its scan
pointer to be one before the start of the buffer in order to break out
of the loop. It seems unlikely that the (stack allocated) buffer will
be at address zero so I don't think any sane compiler will cause us
problems here.
tag.c:104:40: runtime error: member access within null pointer of type
'struct commit'
This does "&lookup_commit(sha1)->object" which ends up being okay
because "object" is the first item in struct commit. I'm not sure
it's worth the churn to change this.
xdiff/xutils.c:308:7: runtime error: load of misaligned address for type
'unsigned long', which requires 8 byte alignment
This is in the XDL_FAST_HASH code, which should only be used on
architectures where this is likely to be reasonably fast. The commit
introducing this code points at an LKML thread[1] discussing a similar
implementation in the kernel, which discusses the impact of the
unaligned access, the conclusion being that it's faster than any
alternative.
[1] https://lkml.org/lkml/2012/3/2/452
John Keeping (2):
diffcore-break: don't divide by zero
bisect: avoid signed integer overflow
bisect.c | 2 +-
diffcore-break.c | 3 ++-
2 files changed, 3 insertions(+), 2 deletions(-)
--
1.8.2.540.gf023cfe
next reply other threads:[~2013-04-02 19:51 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-02 19:50 John Keeping [this message]
2013-04-02 19:50 ` [PATCH 1/2] diffcore-break: don't divide by zero John Keeping
2013-04-02 21:15 ` Junio C Hamano
2013-04-02 21:36 ` John Keeping
2013-04-02 22:41 ` Junio C Hamano
2013-04-03 19:24 ` [PATCH v2] " John Keeping
2013-04-02 19:50 ` [PATCH 2/2] bisect: avoid signed integer overflow John Keeping
2013-04-02 21:09 ` Junio C Hamano
2013-04-03 19:17 ` John Keeping
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=cover.1364931627.git.john@keeping.me.uk \
--to=john@keeping.me.uk \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.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).