By the way, I have found another reproducible bug.
If one creates a window, calls windowGuiThread() but without making the window visible beforehand, and terminates the program (for example by pressing Ctrl+C in the shell), Visopsys may crash.
The implementation of strlen() in Visopsys has a subtle behavior; if the function goes farther than a number of characters (by default 4096) it returns and reports an out-of-boundaries error. While not strictly a bug report, this behavior is not standard, and I think it might be desirable to not limit the distance at which strlen() can go into the string.. also because a lot of software uses strlen() on big buffers, especially simple parsers.
nextvolume wrote:The implementation of strlen() in Visopsys has a subtle behavior; if the function goes farther than a number of characters (by default 4096) it returns and reports an out-of-boundaries error. While not strictly a bug report, this behavior is not standard, and I think it might be desirable to not limit the distance at which strlen() can go into the string.. also because a lot of software uses strlen() on big buffers, especially simple parsers.
You're right, it's true. I'm torn, though. It's easy for a programmer to forget to terminate a string, and I thought this seemed like a reasonable fail-safe. Basically, I set what was intended to be a system-wide maximum string length. It's used for various things, and hopefully makes things a bit less crash-prone.
I guess the question is, is being compliant with the standard C library definition the right thing to do, even when the function is inherently unsafe?
I'm open to changing it though, if people feel strongly about this.
In my humble opinion, the benefits gained from switching to standard behavior for strlen() outweigh the shortcomings; it makes porting existing software much easier.
A solution is keeping but renaming the current strlen() implementation to something like stringGetLength().
First you would need to create a cross-compiler of GCC that can compile Visopsys programs without all the special command-line arguments (so that it uses the correct include files and libraries, etc).
Second step is then to compile that GCC with itself, and voila: you have a native GCC for Visopsys.
Hi, I getting a error while playing the Snake game. After a few games, when I started again, it show me an exception alert
at address 00000000. At this moment I had minimized two Programs and one File Browser windows.
Then I closed the Snake game, and I went to the Windows menu for close the minimized apps, then I get another crash at address 00000002.