We've found using a header/footer construct in fixedlength2 causes a buffer overflow within go-corelib.

To reproduce, construct an input such as:
<REC_HDR>
<Lots of lines here...
...
...
...
<REC_FTR>

Tracing into go-corelib it looks like there's a default buffer size of 4096, so the input record needs to be greater than that to reproduce.

It looks ilke reader.lineBuf[i] is getting set to a pointer inside the buffer. When the buffer wraps, the lineBuf gets corrupted.

See attached files to reproduce. This occurs (for these data), when r.linesRead is 118 (or shortly thereafter).

I think something like this could fix it, but not sure if it's the optimal solution (this works though...).

This is in: fileformat/flatfile/fixedlength/reader.go

func (r *reader) readLine() error {	for {	// note1: ios.ByteReadLine returns a ln with trailing '\n' (and/or '\r') dropped.	// note2: ios.ByteReadLine won't return io.EOF if ln returned isn't empty.	b, err := ios.ByteReadLine(r.r)	switch {	case err == io.EOF:	return io.EOF	case err != nil:	return ErrInvalidFixedLength(r.fmtErrStr(r.linesRead+1, err.Error()))	}	r.linesRead++	if len(b) > 0 {	// Copy data out of the buffer into our local line buffer	lineCopy := make([]byte, len(b))	_ = copy(lineCopy, b)	r.linesBuf = append(r.linesBuf, line{lineNum: r.linesRead, b: lineCopy})	// This causes buffer overruns to appear in local data:	// r.linesBuf = append(r.linesBuf, line{lineNum: r.linesRead, b: b})	return nil	}	} } 

Cheers,
Paul

schema.txt
data.txt