How are bug reports against 1.0.x handled? I went through some bugs just for the fun of it and found a lot to close -- however I only tested with the current CVS.

1954 - new TThread makes FHandle PID at all times 1694 - can probably be closed - I don't see how he could get gibberish output but a runtime error I can see, sock2text was broken 2126 - another TThread thing
2683 - select is in winsock
2699 - attached is a patch to fix this
2726 - works for me with current CVS
(rtl a bit older because CVS doesn't compile)
2741 - works for me, "certain telnet clients" seems a bit odd anyway 2759 - attached is a patch of i386 only. However, wouldn't it be more appropriate to handle FPU exceptions than checking all pre-conditions?

All for now, got some other stuff to do.

johannes

Set to fixed.

1694 - can probably be closed - I don't see how he could get gibberish output but a runtime error I can see, sock2text was broken

Set to fixed.

2126 - another TThread thing

Set to fixed.

2683 - select is in winsock

Set to fixed.

2699 - attached is a patch to fix this

Applied, set to fixed.

2726 - works for me with current CVS (rtl a bit older because CVS doesn't compile)

Checked, set to fixed.

2741 - works for me, "certain telnet clients" seems a bit odd anyway

The problem is that some (stupid) telnet clients don't set the terminal size correctly - this results in no values for the TIOCGWINSZ call, and so the screensize is bogus. The suggested fix is to set some sensible default values, which I did.

2759 - attached is a patch of i386 only. However, wouldn't it be more appropriate to handle FPU exceptions than checking all pre-conditions?

If someone knows how to handle these exceptions correctly, yes. Applied the fix, and set to fixed.

Thanks for the patches !

Michael.

Hmm, I thought to fix the fpu exception handling in 1.9.0 some weeks ago, is there still a problem?

Well, its platform dependent. On Windows, you get an exception. On posix, you get SIGFPE (=8). Now, the question is how to handle that signal.
Another possibility would be to mask the FPU exceptions before each operation, reset the control word after the operation and also check if an exception occurred. This will probably be slower because there's more overhead before each FPU call. However, it'll still be far faster than the current solution.
I'll investigate the signal handling issue(s) and see if its possible to handle SIGFPE properly.

johannes

Johannes Berg wrote

I'll investigate the signal handling issue(s) and see if its possible to handle SIGFPE properly.

This is already implemented, at least on linux. So why is there even a check? If I do
writeln(ln(a)) where a:extended=0
then I get a SIGFPE which is handled and converted to a runtime error or exception (depending on having sysutils or not).

johannes

It works on FreeBSD too, and NetBSD partially (double faults are treated slightly different IIRC). This is the notorious "TException4" test.

Marco van de Voort wrote

It works on FreeBSD too, and NetBSD partially (double faults are treated slightly different IIRC). This is the notorious "TException4" test.

Then whats the point in checking all the pre-conditions in all the math functions though?

johannes

Which checks do you mean exactly?

I guess the poster meant that e.g. (-3)^2 is possible in inside real numbers however the default forumula exp(2*ln(-3)) faults on it.

-- Start of PGP signed section.

Dunno. Rangechecking probably.

Johannes Berg wrote

[list of bugs]

More:

2771 - works fine
2492 - works for me if I understand the report correctly 2535 - should imho be closed invalid, you can't really export methods, they have compiler magic with extra parameters and such 2543 - the {$static on} mode provides this if I understand it correctly 2787 - ask the reporter to try again and post compiling code next time, his code has "virtual; override;" which is not really possible

Most of the other compiler bugs I can reproduce or not even try because its on other systems.

johannes

time,

his code has "virtual; override;" which is not really possible

Therefore the compiler should give an error message, instead of compiling merrily on.

Why should he post compiling code?

Vincent.

Because I don't think it illustrates the point if it doesn't compile for some other reason.

johannes

I fixed it already, but forgot to close the report. From tests with delphi i found that virtual;override was not giving an error and added the error also for fpc.

I fixed it already

2492 - works for me if I understand the report correctly

Already fixed with rtti rewrites a long time ago

2535 - should imho be closed invalid, you can't really export methods, they have compiler magic with extra parameters and such

I agree with you, but not everyone agrees here. That is the reason why it is still open

2543 - the {$static on} mode provides this if I understand it correctly

This is not implemented. The bug reports requests implicit calling of static constructors from the unit initialization. Current static features are only used for fields

2787 - ask the reporter to try again and post compiling code next time, his code has "virtual; override;" which is not really possible

Already set to fixed

I agree with you, but not everyone agrees here. That is the reason why it is still open

Just my 2 cents worth:

If you know what you're doing, you can export it:

procedure TMyClass.ExpoFunc;
begin
end;
procedure TMyClass_ExpoFunc(const obj: pointer); export;
begin
  TMyClass(obj).ExpoFunc;
end;

Granted, its more code to write, but its a bit of a safeguard. If you don't know what you're doing exporting a method would be a bad idea.

johannes

Florian Klaempfl wrote

Which checks do you mean exactly?

Actually there are two things.
I originally thought it would be better to just let the FPU execute the instructions and then catch the signal/exception/whatever after the fact.

I guess the poster meant that e.g. (-3)^2 is possible in inside real numbers however the default forumula exp(2*ln(-3)) faults on it.

And thats the other. And I'm an idiot for writing a patch that won't work. Apologies for that. Attached is a patch that really fixes the issue and does that by checking the arguments and doing a transformed calculation.

johannes