This only occurs in specific circumstances where the number of bytes to be added
to a t_buffer via the ft_buffer_push_buf function is exactly equal to the number
of free bytes in the current underlying buffer. This does not occur if the
number of bytes to add to the buffer is smaller than that, since we allocate new
space using ft_calloc.
In these circumstances, since no terminating null byte is added, other code may
read past the end of the buffer, causing a buffer overflow.
Using the .debug command, debug mode can be toggled. It starts turned off.
When it is on, each command, before being executed, is debug-printed using the
tree-printing facilities.
You have to call closedir().
I also removed the errno checking to make some space, I don't think it is needed
when looking at the errors returned by these functions.
The Open Group Base Specifications Issue 8 IEEE Std 1003.1-2024 sh — shell, the
standard command language interpreter says:
> When the shell is using standard input and it invokes a command that also uses
> standard input, the shell shall ensure that the standard input file pointer
> points directly after the command it has read when the command begins
> execution. It shall not read ahead in such a manner that any characters
> intended to be read by the invoked command are consumed by the shell (whether
> interpreted by the shell or not) or that characters that are not read by the
> invoked command are not seen by the shell.
We used the default BUFFER_SIZE for get_next_line of 1024, which caused us to
read ahead farther than was allowed by the Open Group Base Specification.
Setting BUFFER_SIZE=1 ensures that we don't read too far ahead, since
get_next_line will always immediatly stop once a newline is found.
This is for me the simplest way to solve this issue.