diff options
author | Jeff King <peff@peff.net> | 2013-03-21 07:05:28 -0400 |
---|---|---|
committer | Junio C Hamano <gitster@pobox.com> | 2013-03-21 14:06:49 -0700 |
commit | b8527d5fa61f4401c38e5992b154d7a323aacbf0 (patch) | |
tree | 7249aa2f9fe90ae50b74eaace9b0c39a6854bfb5 /compat/mkdir.c | |
parent | fast-import: clarify "inline" logic in file_change_m (diff) | |
download | tgif-b8527d5fa61f4401c38e5992b154d7a323aacbf0.tar.xz |
wt-status: fix possible use of uninitialized variable
In wt_status_print_change_data, we accept a change_type flag
that is meant to be either WT_STATUS_UPDATED or
WT_STATUS_CHANGED. We then switch() on this value to set
the local variable "status" for each case, but do not
provide a fallback "default" label to the switch statement.
As a result, the compiler realizes that "status" might be
unset, and complains with a warning. To silence this
warning, we use the "int status = status" trick. This is
correct with the current code, as all callers provide one of
the two expected change_type flags. However, it's also a
maintenance trap, as there is nothing to prevent future
callers from passing another flag, nor to document this
assumption.
Instead of using the "x = x" hack, let's handle the default
case in the switch() statement with a die("BUG"). That tells
the compiler and any readers of the code exactly what the
function's input assumptions are.
We could also convert the flag to an enum, which would
provide a compile-time check on the function input. However,
since these flags are part of a larger enum, that would make
the code unnecessarily complex (we would have to make a new
enum with just the two flags, and then convert it to the old
enum for passing to sub-functions).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Diffstat (limited to 'compat/mkdir.c')
0 files changed, 0 insertions, 0 deletions