Bug

[toml_12953]

The following code causes an error in XP rather than handling the error within FB. The error is, of course caused by "falling into" the subroutine at line 20.

do
a = a + 1
print a
gosub 20
loop until a = 10
sleep

20 print a*2
return

[MichaelW]

A bug in your code.

Code: Select all

dim a as integer
do
    a = a + 1
    print a
    gosub 20
loop until a = 10
sleep

20 print a*2
return

Compiled with –exx:

Code: Select all

Aborting due to runtime error 12 ("segmentation violation" signal) in junk1.bas:
:()

An end statement after sleep will fix the problem. Your code under QB would have the same problem, and the fix would be the same.

[cha0s]

well actually, QB wouldn't crash. I think that's the bug is that fb isn't handling the exception.

[toml_12953]

A bug in your code.

Code: Select all

dim a as integer
do
    a = a + 1
    print a
    gosub 20
loop until a = 10
sleep

20 print a*2
return

Compiled with –exx:

Code: Select all

Aborting due to runtime error 12 ("segmentation violation" signal) in junk1.bas:
:()

An end statement after sleep will fix the problem. Your code under QB would have the same problem, and the fix would be the same.

I know the end statement would fix it. The code was just to illustrate that FB doesn't handle the error as it should. Instead it causes an XP error which it should never do.

Tom Lake

[v1ctor]

The machine stack is used to implement GOSUB RETURN, QB probably uses an user stack, what i won't add, sorry.

[MichaelW]

well actually, QB wouldn't crash. I think that's the bug is that fb isn't handling the exception.

Sorry, I misstated. The code compiled as an EXE would crash, and you would be notified of the problem only if you compiled with the Produce Debug Code option.

[MichaelW]

The code was just to illustrate that FB doesn't handle the error as it should. Instead it causes an XP error which it should never do.

Why should FB handle the error? I, for one, would not want the overhead of a safety net. You run the program, it crashes, you find the problem, and you fix it. Seems very normal to me :)

[toml_12953]

The code was just to illustrate that FB doesn't handle the error as it should. Instead it causes an XP error which it should never do.

Why should FB handle the error? I, for one, would not want the overhead of a safety net. You run the program, it crashes, you find the problem, and you fix it. Seems very normal to me :)

You're probably not a professional BASIC programmer. Those of us who are are used to BASIC taking care of everything as it has since the beginning in 1964. I started programming in BASIC in 1966 and have followed its evolution ever since. I make my living programming nothing but different dialects of it. No well written program should crash the OS (of course no well written OS should crash either but we ARE talking Windows here!). All errors should be handled internally.

[cha0s]

toml, Did you compile with -exx? It should not crash xp, it should just return the "seg violation" error in that case, right?

[v1ctor]

A stack fault shouldn't crash any OS, if it does, move to a modern one - btw, nor DOS crashes with that as FB DOS apps run in DPMI mode, an exception should be shown instead.

[DOS386]

Code: Select all

do
a = a + 1
print a
gosub 20
loop until a = 10
sleep

20 print a*2
return

Does NOT crash for me. Generates a warn when compiling (implicite
variable). When running, generates nonsence numbers (multiplication
does NOT work), but does not crash.

Code: Select all

REM FreeBASIC "BUG" test
dim a as integer
do
  a = a + 1
  print a
  gosub 20
loop until a = 10
sleep

20 print "::";a*2
return

This one DOES crash for me :-D

Windows (illegal activity) and DOS (page fault).

[tunginobi]

Code: Select all

do
a = a + 1
print a
gosub 20
loop until a = 10
sleep

20 print a*2
return

Does NOT crash for me. Generates a warn when compiling (implicite
variable). When running, generates nonsence numbers (multiplication
does NOT work), but does not crash.

Huh? Those numbers aren't nonsense: they make perfect sense.

Code: Select all

1
1 '' 1 * 2
2
4 '' 2 * 2
3
6 '' 3 * 2
  '' And so on...

@toml_12953: Compile with -exx.

[toml_12953]

[quote="tunginobi]

@toml_12953: Compile with -exx.[/quote]

I know that's what is necessary but my point is it shouldn't be necessary to prevent FB from causing a Windows error.

[MichaelW]

It was necessary for applications compiled with QB, PDS, and VBDOS, at a time when the OS was relatively fragile. You start this thread with a piece of code that contains an obvious and intentional error, that FB by default cannot catch, and you complain that this is a flaw in FB. I doubt that many here share your desire to program in a sandbox where you are, by default, protected from yourself, no matter what the overhead involved may be.