Bug reporting thread

General discussion about Visopsys. We'll create more specific forums if the number of posts justifies that.
nextvolume
Posts: 30
Joined: Sun Sep 01, 2013 7:58 pm

Bug reporting thread

Post by nextvolume » Mon Jan 20, 2014 10:21 pm

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: 499
Joined: Tue Nov 16, 2010 7:20 pm

Re: Issue when getting file size

Post by andymc » Mon Jan 20, 2014 11:59 pm

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 » Wed Jan 22, 2014 2:39 pm

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: 499
Joined: Tue Nov 16, 2010 7:20 pm

Bug reporting thread

Post by andymc » Thu Jan 23, 2014 12:44 am

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 » Fri Jan 24, 2014 7:57 pm

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: 499
Joined: Tue Nov 16, 2010 7:20 pm

Re: Bug reporting thread

Post by andymc » Sat Jan 25, 2014 12:45 am

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 » Sat Jan 25, 2014 11:11 pm

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 » Sat Jan 25, 2014 11:38 pm

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: 499
Joined: Tue Nov 16, 2010 7:20 pm

Re: Bug reporting thread

Post by andymc » Sun Feb 02, 2014 5:42 pm

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 » Sat Jul 12, 2014 4:49 pm

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