Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2004-10

bug report

13 messages · 6 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Chess Player

I write to all 4 bytes of an array, but only the first byte is changed.

The attached short program demonstrates the bug in Free Pascal Compiler version 1.0.11 [2004/05/18] for i386 in a DOS-box under Windoze.

By the way, I attempted to post this bug on the Free Pascal website, but the "Submit bug" button wouldn't work.

Steve Fisher

_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com

Reply by email

Peter Vreman
to Chess Player
Show quoted text 9 lines
I write to all 4 bytes of an array, but only the first byte is changed. The attached short program demonstrates the bug in Free Pascal Compiler version 1.0.11 [2004/05/18] for i386 in a DOS-box under Windoze. By the way, I attempted to post this bug on the Free Pascal website, but the "Submit bug" button wouldn't work.

It is already fixed in 1.9.4

Reply by email

Chess Player

Peter Vreman wrote

It is already fixed in 1.9.4

Compiling with 1.9.4 produces error messages, ending with

error setting exception n�0D
error setting exception n�0E
error setting exception n�0F
error setting exception n�10
error setting exception n�11
61 Lines compiled, 0.3 sec
error setting exception n�00
error setting exception n�01
error setting exception n�03
error setting exception n�04
error setting exception n�05
error setting exception n�06
error setting exception n�07
error setting exception n�08
error setting exception n�09
error setting exception n�0A
error setting exception n�0B
error setting exception n�0C
error setting exception n�0D
error setting exception n�0E
error setting exception n�0F
error setting exception n�10
error setting exception n�11

Despite the plethora of errors, an executable is produced. Running it yields

error setting exception n�10
error setting exception n�11
Buffer: ----
In buffer, changing byte number 0 1 2 3
Buffer should now be "EEEE".
Buffer: EEEE
error setting exception n�00
error setting exception n�01
error setting exception n�03
error setting exception n�04
error setting exception n�05
error setting exception n�06
error setting exception n�07
error setting exception n�08
error setting exception n�09
error setting exception n�0A
error setting exception n�0B
error setting exception n�0C
error setting exception n�0D
error setting exception n�0E
error setting exception n�0F
error setting exception n�10
error setting exception n�11

The bug has been fixed, but now something else is awry.

http://www.freepascal.org states:

Version 1.0.10 is the latest stable version the Free Pascal.

http://www.us.freepascal.org/develop.html states:

Show quoted text 6 lines
Download Daily Update of Release Tree (version 1.0.x) These snapshots contain the latest bug fixes, without any major new feature. This should be more stable than the development snapshots (and even the last official release), but there is still no guarantee that these snapshots are bugfree.

The developers consider 1.9.4 unstable; it is only a beta version. Therefore, I would rather not rely on it.
It is disappointing that the latest snapshot for the stable version of Free Pascal is dated 2004-05-18 and that the fix for this bug has not been applied to 1.0.10 (or 1.0.11).

When the bug became evident to me, I ported the program I was working on to TMT Pascal, where it evolved so much that when I moved it back to Free Pascal (because of support for long filenames) it was no longer affected by the bug. Nevertheless, it is troubling to think that bugs of this sort are lurking in the shadows.

_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com

Reply by email

Jonas Maebe
to Chess Player
Chess Player wrote 7 lines
Compiling with 1.9.4 produces error messages, ending with error setting exception n°0D error setting exception n°0E error setting exception n°0F error setting exception n°10 error setting exception n°11

You are using the Dos IDE under Windows. This is unsupported. In general, the IDE of 1.9.4 is very unstable, because we no longer have anyone working on the IDE (all people that did this do not have time anymore).

Jonas

Reply by email

Peter Vreman
to Chess Player: Peter Vreman wrote Compiling with 1.9.4 produces error messages, ending with error…
Show quoted text 19 lines
http://www.freepascal.org states: >Version 1.0.10 is the latest stable version the Free Pascal. http://www.us.freepascal.org/develop.html states: >Download Daily Update of Release Tree (version 1.0.x) > >These snapshots contain the latest bug fixes, without any major new > feature. >This should be more stable than the development snapshots (and even the > last >official release), but there is still no guarantee that these snapshots > are >bugfree. The developers consider 1.9.4 unstable; it is only a beta version. Therefore, I would rather not rely on it. It is disappointing that the latest snapshot for the stable version of Free Pascal is dated 2004-05-18 and that the fix for this bug has not been applied to 1.0.10 (or 1.0.11).

We don't have the time to backport fixes. Also a lot of the fixes can't be backported to 1.0.x because of flaws in the design of 1.0.x.

The 1.9.4 beta is at least as stable as 1.0.10.

The daily snapshots of 1.9.5 can be more unstable. But in a lot of cases they are as stable as the latest 1.9.x beta release

Reply by email

Tomas Hajny
to Chess Player: Peter Vreman wrote Compiling with 1.9.4 produces error messages, ending with error…

On Mon, 11 Oct 2004 00:10:57 -0700 (PDT), Chess Player wrote

Show quoted text 8 lines
Peter Vreman wrote > It is already fixed in 1.9.4 Compiling with 1.9.4 produces error messages, ending with error setting exception n°0D error setting exception n°0E error setting exception n°0F

.
.

The bug has been fixed, but now something else is awry.

.
.

This is because you're using the GO32v2 version under Windows 2000 or XP. Unfortunately, Microsoft made the DOS environment in these OS versions too much incompatible to the real DOS, that we can't support running GO32v2 version there. However, using GO32v2 binaries under Win32 systems is inferior to native Win32 binaries ones anyway. This means that the solution is easy - download the Win32 version and use it under your WinNT/2K/XP, whereas you only use GO32v2 under real DOS (or potentially under Win9x as well, because it's much more compatible because of its DOS roots). You can of course continue using GO32v2 binaries under WinNT/2K/XP as well, but then you have to accept that it produces error messages like this and that it can stop working any time (e.g. after you apply the next Windows Service Pack or whatever else). I'm sorry, but there isn't much we can do about it - Microsoft just doesn't want to support DOS applications properly.

Best regards

Tomas

Reply by email

Vincent Snijders
to Peter Vreman: We don't have the time to backport fixes. Also a lot of the fixes can't be backported to…
Peter Vreman wrote 27 lines
>http://www.freepascal.org states: > >>Version 1.0.10 is the latest stable version the Free Pascal. > >http://www.us.freepascal.org/develop.html states: > >>Download Daily Update of Release Tree (version 1.0.x) >> >>These snapshots contain the latest bug fixes, without any major new >>feature. >>This should be more stable than the development snapshots (and even the >>last >>official release), but there is still no guarantee that these snapshots >>are >>bugfree. > >The developers consider 1.9.4 unstable; it is only a beta version. >Therefore, I would rather not rely on it. >It is disappointing that the latest snapshot for the stable version >of Free Pascal is dated 2004-05-18 and that the fix for this bug has >not been applied to 1.0.10 (or 1.0.11). We don't have the time to backport fixes. Also a lot of the fixes can't be backported to 1.0.x because of flaws in the design of 1.0.x. The 1.9.4 beta is at least as stable as 1.0.10.

Maybe you should say that on the web site too.

The daily snapshots of 1.9.5 can be more unstable. But in a lot of cases they are as stable as the latest 1.9.x beta release

Vincent.

Reply by email

Chess Player

I installed version 1.9.4 for windows and compiled my program. It appears to work perfectly, and, amazingly, the size of the executable was reduced from 63k to 23k!

To give the windows version a more rigorous test, I compiled a DOS filter program I wrote as a partial replacement for ANSI.SYS. It failed to display ANSI pictures properly; it seems that BIOS calls don't work. (I can't use the CRT unit because piping can't be used with it.)

So I will use the windows version most of the time and will fall back to the DOS version only when BIOS calls are needed.

Thanks to all of you for your helpful comments.

_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com

Reply by email

Marco van de Voort
to Chess Player
Show quoted text 12 lines
I installed version 1.9.4 for windows and compiled my program. It appears to work perfectly, and, amazingly, the size of the executable was reduced from 63k to 23k! To give the windows version a more rigorous test, I compiled a DOS filter program I wrote as a partial replacement for ANSI.SYS. It failed to display ANSI pictures properly; it seems that BIOS calls don't work. (I can't use the CRT unit because piping can't be used with it.) So I will use the windows version most of the time and will fall back to the DOS version only when BIOS calls are needed.

Did any of the BIOS calls have an address to data as one of the arguments? If so, read the documentation for the GO32V2 unit, most notably copyfromdos/copytodos.

Reply by email

Jonas Maebe
to Chess Player: I installed version 1.9.4 for windows and compiled my program. It appears to work…
Chess Player wrote 5 lines
To give the windows version a more rigorous test, I compiled a DOS filter program I wrote as a partial replacement for ANSI.SYS. It failed to display ANSI pictures properly; it seems that BIOS calls don't work. (I can't use the CRT unit because piping can't be used with it.)

You can indeed probably not call the Bios from Windows programs. You have to use the win32 api.

Jonas

Reply by email

Tomas Hajny
to Jonas Maebe

On Tue, 12 Oct 2004 08:58:09 +0200, Jonas Maebe wrote

Show quoted text 10 lines
On 12 okt 2004, at 07:04, Chess Player wrote: > To give the windows version a more rigorous test, I compiled > a DOS filter program I wrote as a partial replacement for > ANSI.SYS. It failed to display ANSI pictures properly; > it seems that BIOS calls don't work. (I can't use the CRT unit > because piping can't be used with it.) You can indeed probably not call the Bios from Windows programs. You have to use the win32 api.

... or our existing low-level units like "Video", "Keyboard" and "Mouse" as appropriate, which are cross-platform.

Tomas

Reply by email

Chess Player
Did any of the BIOS calls have an address to data as one of the arguments? If so, read the documentation for the GO32V2 unit, most notably copyfromdos/copytodos.

No, a call is made with simple arguments such as the x,y screen position or a color (attribute) and a character to write.

Eventually I may bite the bullet and convert it to use the Video unit.

__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail

Reply by email

Marco van de Voort
to Chess Player
Show quoted text 7 lines
>Did any of the BIOS calls have an address to data as one of the >arguments? >If so, read the documentation for the GO32V2 unit, most notably >copyfromdos/copytodos. No, a call is made with simple arguments such as the x,y screen position or a color (attribute) and a character to write.

I missed the point that you used the windows compiler.

Eventually I may bite the bullet and convert it to use the Video unit.

That is better anyway.

Reply by email