crunch-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Owen <>
Subject Another Coverity scan?
Date Tue, 19 May 2015 21:54:24 GMT
Hi all, I'd like to run by you all a little bit of analysis I did a while
ago on Crunch ( and wanted
to try again. I've been experimenting again with static analysis, in
particular Coverity, and gave it another pass over the Crunch code.

It turned up a few minor potential issues, and a number of reasonable
touch-ups, so I wanted to propose another omnibus change to zap several of

You can see the current state at but it does require

As a preview, the minor touch-ups are:

- Replace use of old junit.framework.* with org.unit.* for consistency
- Remove some unused imports
- String.getBytes() -> String.getBytes(Charset) to avoid platform dependence
- Remove a few dead stores
- Replace one Map.keySet() + many get()s with Map.entrySet() iteration
- Remove a few @Nullable on method args that can't be (immediately
- Closing some objects in a finally block that are Closable
- Math.abs is technically a bad idea for something that can ==

There are a few changes that might be minor bug fixes:

"maxInputLength > 0 && next.length() > maxInputLength" also needs a check
for next != null, but doesn't the second clause also need parentheses?

The call to skip() doesn't check that the expected number of bytes were

Missing hashCode for equals

options is checked for null but is always dereferenced at the end

baseContext can't be null at this point because of line 192

Not a bug but redundant I think since this occurs inside a block also
guarded by "if (t instance MapReduceTarget) {"

Does some of this sound worth a look at a patch? I've actually got it ready
and can make a JIRA.

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message