Bug reporting thread

General discussion about Visopsys.
nextvolume
Posts: 30
Joined: Sun Sep 01, 2013 7:58 pm

Bug reporting thread

Post by nextvolume »

Hi, I stumbled on a major problem.
The common trick to get the size of a file:

Code: Select all

int sz;
fseek(myFile, 0, SEEK_END);
sz = ftell(myFile);
fseek(myFile, 0, SEEK_SET);
doesn't work, and reports that it is impossible to seek beyond a file.

For now, the most reliable workaround I've found is getting the size of a file by using
internal structure members, in this way:

Code: Select all

sz = myFile->f.size;
this will work, but this isn't portable and internal structure members may change in the future.
Last edited by admin on Thu Jan 23, 2014 12:51 am, edited 1 time in total.
Reason: Change subject and make it sticky
Visopsys@Unhaut - http://unhaut.fav.cc/visopsys
User avatar
andymc
Posts: 590
Joined: Tue Nov 16, 2010 7:20 pm

Re: Issue when getting file size

Post by andymc »

Oops. Hmm, sounds like an error in the file stream code maybe.

I've never tried getting the file size that way - I've always used stat() :oops:

(you can do that in the meantime, I guess, until I fix the bug)
nextvolume
Posts: 30
Joined: Sun Sep 01, 2013 7:58 pm

Re: Issue when getting file size

Post by nextvolume »

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 following example code can reproduce the bug:

Code: Select all

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/api.h>
#include <sys/window.h>

static objectKey win;
static int program_exit = 0;

int main(int argc, char *argv[])
{	
	win = windowNew(multitaskerGetCurrentProcessId(), "Bug Reproducer");

	windowGuiThread();

	while(!program_exit);
	return 0;
}
P.S.: We really need a bug report topic, and this topic could be renamed to be it.
Visopsys@Unhaut - http://unhaut.fav.cc/visopsys
User avatar
andymc
Posts: 590
Joined: Tue Nov 16, 2010 7:20 pm

Bug reporting thread

Post by andymc »

nextvolume wrote:P.S.: We really need a bug report topic, and this topic could be renamed to be it.
Great idea :-)
nextvolume
Posts: 30
Joined: Sun Sep 01, 2013 7:58 pm

Re: Bug reporting thread

Post by nextvolume »

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.
Visopsys@Unhaut - http://unhaut.fav.cc/visopsys
User avatar
andymc
Posts: 590
Joined: Tue Nov 16, 2010 7:20 pm

Re: Bug reporting thread

Post by andymc »

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.
nextvolume
Posts: 30
Joined: Sun Sep 01, 2013 7:58 pm

Re: Bug reporting thread

Post by nextvolume »

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().
Visopsys@Unhaut - http://unhaut.fav.cc/visopsys
User avatar
ap0r
Posts: 105
Joined: Tue Feb 14, 2012 12:40 am

Re: Bug reporting thread

Post by ap0r »

What a huge breaktrough will be once someone ports a C++ compiler to visopsys :) that way you will not need linux to code visopsys programs
Image
Image
User avatar
andymc
Posts: 590
Joined: Tue Nov 16, 2010 7:20 pm

Re: Bug reporting thread

Post by andymc »

It's not too too difficult, I think.

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.

At least that's how I remember the process.
User avatar
ivan
Posts: 18
Joined: Fri Jul 11, 2014 6:18 pm
Contact:

Snake crash

Post by ivan »

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.

Image

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.

Image
Post Reply