barty/D4J-Repair huggingface dataset:
File: src/main/java/org/apache/commons/compress/archivers/tar/TarArchiveEntry.java
Issue: PAX header entry name ending with / causes problems
There seems to be a problem when a PAX header entry (link flag is 'x') has a name ending with "/". The TarArchiveEntry.isDirectory() check ends up returning true because of the trailing slash which means no content can be read from the entry. PAX header parsing effectively finds nothing and the stream is not advanced; this leaves the stream in a bad state as the next entry's header is actually read from the header contents.
If the name is modified to remove the trailing slash when the link flag indicates a PAX header everything seems to work fine. That would be one potential fix in parseTarHeader. Changing isDirectory to return false if isPaxHeader is true (before the trailing "/" check) would probably also fix the issue (though I can't verify that in the debugger like I can with changing the name).
So far I have only seen this when using Docker to save images that contain a yum database. For example:

docker pull centos:latest && docker save centos:latest | tar x --include "*/layer.tar"

Will produce at least one "layer.tar" that exhibits this issue. If I come across a smaller TAR for testing I will attach it.

Buggy code:
public boolean isDirectory() {
    if (file != null) {
        return file.isDirectory();
    }

    if (linkFlag == LF_DIR) {
        return true;
    }

    if (getName().endsWith("/")) {
        return true;
    }

    return false;
}

Fixed code:
public boolean isDirectory() {
    if (file != null) {
        return file.isDirectory();
    }

    if (linkFlag == LF_DIR) {
        return true;
    }

    if (!isPaxHeader() && !isGlobalPaxHeader() && getName().endsWith("/")) {
        return true;
    }

    return false;
}
File: src/main/java/org/apache/commons/compress/utils/ArchiveUtils.java
Issue: Defective .zip-archive produces problematic error message
A truncated .zip-File produces an java.io.EOFException conatining a hughe amount of byte[]-data in the error-message - leading to beeps and crippeling workload in an potential console-logger.



Buggy code:
public static String sanitize(String s) {
        final char[] chars = s.toCharArray();
        final int len = chars.length;
        final StringBuilder sb = new StringBuilder();
        for (int i = 0; i < len; i++) {
            final char c = chars[i];
            if (!Character.isISOControl(c)) {
                Character.UnicodeBlock block = Character.UnicodeBlock.of(c);
                if (block != null && block != Character.UnicodeBlock.SPECIALS) {
                    sb.append(c);
                    continue;
                }
            }
            sb.append('?');
        }
        return sb.toString();
    }

Fixed code:
public static String sanitize(String s) {
        final char[] cs = s.toCharArray();
        final char[] chars = cs.length <= MAX_SANITIZED_NAME_LENGTH ? cs : Arrays.copyOf(cs, MAX_SANITIZED_NAME_LENGTH);
        if (cs.length > MAX_SANITIZED_NAME_LENGTH) {
            for (int i = MAX_SANITIZED_NAME_LENGTH - 3; i < MAX_SANITIZED_NAME_LENGTH; i++) {
                chars[i] = '.';
            }
        }
        final int len = chars.length;
        final StringBuilder sb = new StringBuilder();
        for (int i = 0; i < len; i++) {
            final char c = chars[i];
            if (!Character.isISOControl(c)) {
                Character.UnicodeBlock block = Character.UnicodeBlock.of(c);
                if (block != null && block != Character.UnicodeBlock.SPECIALS) {
                    sb.append(c);
                    continue;
                }
            }
            sb.append('?');
        }
        return sb.toString();
    }
File: src/main/java/org/apache/commons/compress/utils/ChecksumCalculatingInputStream.java
Issue: NullPointerException defect in ChecksumCalculatingInputStream#getValue()
NullPointerException defect in ChecksumCalculatingInputStream#getValue() detected as stated in pull request 33: https://github.com/apache/commons-compress/pull/33
Furthermore the following test describes the problem:

    @Test(expected = NullPointerException.class) //I assume this behaviour to be a bug or at least a defect.
    public void testGetValueThrowsNullPointerException() {

        ChecksumCalculatingInputStream checksumCalculatingInputStream = new ChecksumCalculatingInputStream(null,null);

        checksumCalculatingInputStream.getValue();

    }

Buggy code:
public ChecksumCalculatingInputStream(final Checksum checksum, final InputStream in) {



    this.checksum = checksum;
    this.in = in;
}

Fixed code:
public ChecksumCalculatingInputStream(final Checksum checksum, final InputStream in) {

    if ( checksum == null ){
        throw new NullPointerException("Parameter checksum must not be null");
    }

    if ( in == null ){
        throw new NullPointerException("Parameter in must not be null");
    }

    this.checksum = checksum;
    this.in = in;
}
File: src/main/java/org/apache/commons/compress/archivers/tar/TarUtils.java
Issue: TarUtils.formatLongOctalOrBinaryBytes never uses result of formatLongBinary
if the length < 9, formatLongBinary is executed, then overwritten by the results of formatBigIntegerBinary. 
If the results are not ignored, a unit test would fail.
Also, do the binary hacks  need to support negative numbers?

Buggy code:
public static int formatLongOctalOrBinaryBytes(
    final long value, final byte[] buf, final int offset, final int length) {

    // Check whether we are dealing with UID/GID or SIZE field
    final long maxAsOctalChar = length == TarConstants.UIDLEN ? TarConstants.MAXID : TarConstants.MAXSIZE;

    final boolean negative = value < 0;
    if (!negative && value <= maxAsOctalChar) { // OK to store as octal chars
        return formatLongOctalBytes(value, buf, offset, length);
    }

    if (length < 9) {
        formatLongBinary(value, buf, offset, length, negative);
    }
    formatBigIntegerBinary(value, buf, offset, length, negative);

    buf[offset] = (byte) (negative ? 0xff : 0x80);
    return offset + length;
}

Fixed code:
public static int formatLongOctalOrBinaryBytes(
    final long value, final byte[] buf, final int offset, final int length) {

    // Check whether we are dealing with UID/GID or SIZE field
    final long maxAsOctalChar = length == TarConstants.UIDLEN ? TarConstants.MAXID : TarConstants.MAXSIZE;

    final boolean negative = value < 0;
    if (!negative && value <= maxAsOctalChar) { // OK to store as octal chars
        return formatLongOctalBytes(value, buf, offset, length);
    }

    if (length < 9) {
        formatLongBinary(value, buf, offset, length, negative);
    } else {
        formatBigIntegerBinary(value, buf, offset, length, negative);
    }

    buf[offset] = (byte) (negative ? 0xff : 0x80);
    return offset + length;
}
File: src/main/java/org/apache/commons/compress/archivers/zip/X5455_ExtendedTimestamp.java
Issue: Tests failing under jdk 9 : one reflection issue, one change to ZipEntry related issue
X5455_ExtendedTimestampTest is failing under JDK 9 , due to what appears to be a bogus value returned from getTime().  It seems like the test failure might be due to the changes introduced for this: 
https://bugs.openjdk.java.net/browse/JDK-8073497
Tests were run using intelliJ TestRunner, using the openjdk9 build from the tip of the jdk9 tree (not dev).  I believe that this is at most one commit away from what will be the RC (which was delayed at the last minute due to two issues, one of which was javadoc related, and the other hotspot.

Buggy code:
private static ZipLong unixTimeToZipLong(long l) {
    final long TWO_TO_32 = 0x100000000L;
    if (l >= TWO_TO_32) {
        throw new IllegalArgumentException("X5455 timestamps must fit in a signed 32 bit integer: " + l);
    }
    return new ZipLong(l);
}

Fixed code:
private static ZipLong unixTimeToZipLong(long l) {
    if (l < Integer.MIN_VALUE || l > Integer.MAX_VALUE) {
        throw new IllegalArgumentException("X5455 timestamps must fit in a signed 32 bit integer: " + l);
    }
    return new ZipLong(l);
}
File: src/main/java/org/apache/commons/compress/archivers/tar/TarUtils.java
Issue: TarUtils.parseName does not properly handle characters outside the range 0-127
if a tarfile contains files with special characters, the names of the tar entries are wrong.
example:
correct name: 0302-0601-3±±±F06±W220±ZB±LALALA±±±±±±±±±±CAN±±DC±±±04±060302±MOE.model
name resolved by TarUtils.parseName: 0302-0101-3ﾱﾱﾱF06ﾱW220ﾱZBﾱHECKMODULﾱﾱﾱﾱﾱﾱﾱﾱﾱﾱECEﾱﾱDCﾱﾱﾱ07ﾱ060302ﾱDOERN.model
please use: 
result.append(new String(new byte[] 
{ buffer[i] }
));
instead of: 
result.append((char) buffer[i]);
to solve this encoding problem.

Buggy code:
public static String parseName(byte[] buffer, final int offset, final int length) {
    StringBuffer result = new StringBuffer(length);
    int          end = offset + length;

    for (int i = offset; i < end; ++i) {
        if (buffer[i] == 0) {
            break;
        }
        result.append((char) buffer[i]);
    }

    return result.toString();
}

Fixed code:
public static String parseName(byte[] buffer, final int offset, final int length) {
    StringBuffer result = new StringBuffer(length);
    int          end = offset + length;

    for (int i = offset; i < end; ++i) {
        byte b = buffer[i];
        if (b == 0) { // Trailing null
            break;
        }
        result.append((char) (b & 0xFF)); // Allow for sign-extension
    }

    return result.toString();
}
File: src/main/java/org/apache/commons/compress/archivers/tar/TarUtils.java
Issue: TarArchiveEntry.parseTarHeader() includes the trailing space/NUL when parsing the octal size
TarArchiveEntry.parseTarHeader() includes the trailing space/NUL when parsing the octal size.
Although the size field in the header is 12 bytes, the last byte is supposed to be space or NUL - i.e. only 11 octal digits are allowed for the size.

Buggy code:
public static long parseOctal(final byte[] buffer, final int offset, final int length) {
    long    result = 0;
    boolean stillPadding = true;
    int     end = offset + length;
    int     start = offset;

    for (int i = start; i < end; i++){
        final byte currentByte = buffer[i];
        if (currentByte == 0) {
            break;
        }

    // Skip leading spaces
        if (currentByte == (byte) ' ' || currentByte == '0') {
            if (stillPadding) {
               continue;
        }
            if (currentByte == (byte) ' ') {
            break;
            }
        }

    // Must have trailing NUL or space
    // May have additional NUL or space

        stillPadding = false;
        // CheckStyle:MagicNumber OFF
        if (currentByte < '0' || currentByte > '7'){
            throw new IllegalArgumentException(
                    exceptionMessage(buffer, offset, length, start, currentByte));
        }
        result = (result << 3) + (currentByte - '0'); // convert from ASCII
        // CheckStyle:MagicNumber ON
    }

    return result;
}

Fixed code:
public static long parseOctal(final byte[] buffer, final int offset, final int length) {
    long    result = 0;
    int     end = offset + length;
    int     start = offset;

    if (length < 2){
        throw new IllegalArgumentException("Length "+length+" must be at least 2");
    }

    boolean allNUL = true;
    for (int i = start; i < end; i++){
        if (buffer[i] != 0){
            allNUL = false;
            break;
        }
    }
    if (allNUL) {
        return 0L;
    }

    // Skip leading spaces
    while (start < end){
        if (buffer[start] == ' '){
            start++;
        } else {
            break;
        }
    }

    // Must have trailing NUL or space
    byte trailer;
    trailer = buffer[end-1];
    if (trailer == 0 || trailer == ' '){
        end--;
    } else {
        throw new IllegalArgumentException(
                exceptionMessage(buffer, offset, length, end-1, trailer));
    }
    // May have additional NUL or space
    trailer = buffer[end-1];
    if (trailer == 0 || trailer == ' '){
        end--;
    }

    for ( ;start < end; start++) {
        final byte currentByte = buffer[start];
        // CheckStyle:MagicNumber OFF
        if (currentByte < '0' || currentByte > '7'){
            throw new IllegalArgumentException(
                    exceptionMessage(buffer, offset, length, start, currentByte));
        }
        result = (result << 3) + (currentByte - '0'); // convert from ASCII
        // CheckStyle:MagicNumber ON
    }

    return result;
}
File: src/main/java/org/apache/commons/csv/ExtendedBufferedReader.java
Issue: ExtendedBufferReader does not handle EOL consistently
ExtendedBufferReader checks for '\n' (LF) in the read() methods, incrementing linecount when found.
However, the readLine() method calls BufferedReader.readLine() which treats CR, LF and CRLF equally (and drops them).
If the code is to be flexible in what it accepts, the class should also allow for CR alone as a line terminator.
It should work if the code increments the line counter for CR, and for LF if the previous character was not CR.

Buggy code:
public int read() throws IOException {
    int current = super.read();
    if (current == '\n') {
        lineCounter++;
    }
    lastChar = current;
    return lastChar;
}

Fixed code:
public int read() throws IOException {
    int current = super.read();
    if (current == '\r' || (current == '\n' && lastChar != '\r')) {
        lineCounter++;
    }
    lastChar = current;
    return lastChar;
}
File: src/main/java/org/apache/commons/csv/CSVPrinter.java
Issue: CSVFormat#withHeader doesn't work with CSVPrinter
In the current version CSVFormat#withHeader is only used by CSVParser. It would be nice if CSVPrinter also supported it. Ideally, the following line of code

CSVPrinter csvPrinter
  = CSVFormat.TDF
    .withHeader("x")
    .print(Files.newBufferedWriter(Paths.get("data.csv")));
csvPrinter.printRecord(42);
csvPrinter.close();

should produce

x
42

If you're alright with the idea of automatically inserting headers, I can attach a patch.

Buggy code:
public CSVPrinter(final Appendable out, final CSVFormat format) throws IOException {
    Assertions.notNull(out, "out");
    Assertions.notNull(format, "format");

    this.out = out;
    this.format = format;
    this.format.validate();
    // TODO: Is it a good idea to do this here instead of on the first call to a print method?
    // It seems a pain to have to track whether the header has already been printed or not.
}

Fixed code:
public CSVPrinter(final Appendable out, final CSVFormat format) throws IOException {
    Assertions.notNull(out, "out");
    Assertions.notNull(format, "format");

    this.out = out;
    this.format = format;
    this.format.validate();
    // TODO: Is it a good idea to do this here instead of on the first call to a print method?
    // It seems a pain to have to track whether the header has already been printed or not.
    if (format.getHeader() != null) {
        this.printRecord((Object[]) format.getHeader());
    }
}
File: src/main/java/org/apache/commons/csv/CSVRecord.java
Issue: CSVRecord does not verify that the length of the header mapping matches the number of values
CSVRecord does not verify that the size of the header mapping matches the number of values. The following test will produce a ArrayOutOfBoundsException:

@Test
public void testInvalidHeaderTooLong() throws Exception {
   final CSVParser parser = new CSVParser("a,b", CSVFormat.newBuilder().withHeader("A", "B", "C").build());
   final CSVRecord record = parser.iterator().next();
   record.get("C");
}

Buggy code:
public String get(final String name) {
    if (mapping == null) {
        throw new IllegalStateException(
                "No header mapping was specified, the record values can't be accessed by name");
    }
    final Integer index = mapping.get(name);
        return index != null ? values[index.intValue()] : null;
}

Fixed code:
public String get(final String name) {
    if (mapping == null) {
        throw new IllegalStateException(
                "No header mapping was specified, the record values can't be accessed by name");
    }
    final Integer index = mapping.get(name);
    try {
        return index != null ? values[index.intValue()] : null;
    } catch (ArrayIndexOutOfBoundsException e) {
        throw new IllegalArgumentException(
                String.format(
                        "Index for header '%s' is %d but CSVRecord only has %d values!",
                        name, index.intValue(), values.length));
    }
}
File: src/main/java/org/apache/commons/csv/Lexer.java
Issue: Unescape handling needs rethinking
The current escape parsing converts <esc><char> to plain <char> if the <char> is not one of the special characters to be escaped.
This can affect unicode escapes if the <esc> character is backslash.
One way round this is to specifically check for <char> == 'u', but it seems wrong to only do this for 'u'.
Another solution would be to leave <esc><char> as is unless the <char> is one of the special characters.
There are several possible ways to treat unrecognised escapes:

treat it as if the escape char had not been present (current behaviour)
leave the escape char as is
throw an exception

Buggy code:
int readEscape() throws IOException {
    // the escape char has just been read (normally a backslash)
    final int c = in.read();
    switch (c) {
    case 'r':
        return CR;
    case 'n':
        return LF;
    case 't':
        return TAB;
    case 'b':
        return BACKSPACE;
    case 'f':
        return FF;
    case CR:
    case LF:
    case FF: // TODO is this correct?
    case TAB: // TODO is this correct? Do tabs need to be escaped?
    case BACKSPACE: // TODO is this correct?
        return c;
    case END_OF_STREAM:
        throw new IOException("EOF whilst processing escape sequence");
    default:
        // Now check for meta-characters
            return c;
        // indicate unexpected char - available from in.getLastChar()
    }
}

Fixed code:
int readEscape() throws IOException {
    // the escape char has just been read (normally a backslash)
    final int c = in.read();
    switch (c) {
    case 'r':
        return CR;
    case 'n':
        return LF;
    case 't':
        return TAB;
    case 'b':
        return BACKSPACE;
    case 'f':
        return FF;
    case CR:
    case LF:
    case FF: // TODO is this correct?
    case TAB: // TODO is this correct? Do tabs need to be escaped?
    case BACKSPACE: // TODO is this correct?
        return c;
    case END_OF_STREAM:
        throw new IOException("EOF whilst processing escape sequence");
    default:
        // Now check for meta-characters
        if (isDelimiter(c) || isEscape(c) || isQuoteChar(c) || isCommentStart(c)) {
            return c;
        }
        // indicate unexpected char - available from in.getLastChar()
        return END_OF_STREAM;
    }
}
File: src/main/java/org/apache/commons/csv/CSVParser.java
Issue: CSVParser: getHeaderMap throws NPE
title nearly says it all  
Given a CSVParser parser, the following line throws an NPE:

Map<String, Integer> header = parser.getHeaderMap();

Stacktrace: 

Caused by: java.lang.NullPointerException
at java.util.HashMap.<init>(HashMap.java:318)
at java.util.LinkedHashMap.<init>(LinkedHashMap.java:212)
at org.apache.commons.csv.CSVParser.getHeaderMap(CSVParser.java:288)

happens if the format doesn't have a headerMap.
to fix, check if the parser's headerMap is null before trying to create the returned map:

public Map<String, Integer> getHeaderMap() {
    return this.headerMap != null ?
       new LinkedHashMap<String, Integer>(this.headerMap)
       : null;
}

Buggy code:
public Map<String, Integer> getHeaderMap() {
    return new LinkedHashMap<String, Integer>(this.headerMap);
}

Fixed code:
public Map<String, Integer> getHeaderMap() {
    return this.headerMap == null ? null : new LinkedHashMap<String, Integer>(this.headerMap);
}
File: src/main/java/org/apache/commons/csv/CSVPrinter.java
Issue: CSVFormat.format allways append null
When I now call
CSVFormat.newFormat(';').withSkipHeaderRecord(true).withHeader("H1","H2").format("A","B")
I get the output A;Bnull
The expected output would be 
A;B

Buggy code:
public void println() throws IOException {
    final String recordSeparator = format.getRecordSeparator();
        out.append(recordSeparator);
    newRecord = true;
}

Fixed code:
public void println() throws IOException {
    final String recordSeparator = format.getRecordSeparator();
    if (recordSeparator != null) {
        out.append(recordSeparator);
    }
    newRecord = true;
}
File: src/main/java/org/apache/commons/csv/CSVRecord.java
Issue: CSVRecord.toMap() fails if row length shorter than header length
Similar to CSV-96, if .toMap() is called on a record that has fewer fields than we have header columns we'll get an ArrayOutOfBoundsException.

@Test
public void testToMapWhenHeaderTooLong() throws Exception {
   final CSVParser parser = new CSVParser("a,b", CSVFormat.newBuilder().withHeader("A", "B", "C").build());
   final CSVRecord record = parser.iterator().next();
   record.toMap();
}

Buggy code:
<M extends Map<String, String>> M putIn(final M map) {
    for (final Entry<String, Integer> entry : mapping.entrySet()) {
        final int col = entry.getValue().intValue();
            map.put(entry.getKey(), values[col]);
    }
    return map;
}

Fixed code:
<M extends Map<String, String>> M putIn(final M map) {
    for (final Entry<String, Integer> entry : mapping.entrySet()) {
        final int col = entry.getValue().intValue();
        if (col < values.length) {
            map.put(entry.getKey(), values[col]);
        }
    }
    return map;
}