Hi TK,
thanks for offering to help. I now pushed a GCC-portable version of
Tom's stack check to freecom's git:
https://github.com/FDOS/freecom
However if you try to compile it you'll see once you run it that it
says 0 stack left quite quickly. The reason is not the stack (there is
plenty) but the
Hi,
On Fri, Feb 22, 2019 at 7:03 AM Tom Ehlert wrote:
>
> > so in the end the issue is a stack overflow:
>
> after 5 months since this (16 year old) bug was found, there is still
> no official command.com for everybody else to test.
>
> there are also 3 located, and easy fixable bugs in the kerne
Hello Bart Oldeman,
The OW version looked reasonably stable, the GCC version still ran
into some issues if I remember correctly. Hopefully I can get around
uploading a new prerelease sometime this weekend, and make it the real
release if it works ok.
Do let me know if I might be of any help, e
Tom,
you are (in your words) 110% right.
At the time I had fixed the stack offenders but got lost in debugging
adapting your stack-checking patch to other compilers (it actually
checks the heap too, if heap grows to stack).
The OW version looked reasonably stable, the GCC version still ran
into
Hi Bart, (and all the other maintainers)
> so in the end the issue is a stack overflow: filenames on the stack
> overflow into a const buffer used by strtok. I had raised it from 2K
> to 4K back in January but that is not enough.
> Since Blair Campbell's LFN work in 2006 cmd_rename() which calls