Main menu

• kif
  

  • Registered: Oct 30, 2008
  • Last visit: Mar 18, 2009
  • Posts: 10

  Posted: Nov 05, 2008 - 08:39 PM

  Hi
  
  There are an error if not you are using an function result, the following code (cut and somewhat modified from one of my projects) demonstrate :
  
  

  Code

  function Scale(Ix, Iy : longint; VAR Dx, Dy : longint) : extended;

var

wf,

ff,

hf : extended;



begin

wf := ix / dx;

hf := iy / dy;



if (wf > hf) then ff := wf

else ff := hf;



dx := round(ix / ff);

dy := round(iy / ff);



result := ff;

end;



Procedure TForm1.Button1OnClick (Sender: TObject);

var

w,

x,

y : longint;

f : extended;



Begin

for w := 402 to 410 do

begin

x := 500;

y := w;

f := scale(2087,1691,x,y);

memo1.lines.add(inttostr(w) + ' / ' + inttostr(x) + ' / ' + inttostr(y));

end;

memo1.lines.add('**********');

for w := 402 to 410 do

begin

x := 500;

y := w;

scale(2087,1691,x,y);

memo1.lines.add(inttostr(w) + ' / ' + inttostr(x) + ' / ' + inttostr(y));

end;

End;

  
  
  Please observe, the only difference between the two parts of the program is the "f :=" before Scale in the first part, but the result is as follows (first part is the correct one) :
  
  402 / 496 / 402
  403 / 497 / 403
  404 / 499 / 404
  405 / 500 / 405
  406 / 500 / 405
  407 / 500 / 405
  408 / 500 / 405
  409 / 500 / 405
  410 / 500 / 405
  **********
  402 / 496 / 402
  403 / 497 / 403
  404 / 499 / 404
  405 / 500 / 405
  406 / 500 / 405
  407 / 500 / 405
  408 / 500 / 405
  409 / 505 / 409
  410 / 506 / 410
  
  And not only the calculations are affected, I have been hunting many wierd errors before I found out this was the culprit.
  
  Kim Foder

  •  
• pengels
  

  • Registered: Dec 24, 2008
  • Last visit: Feb 05, 2010
  • Posts: 15

  Posted: Feb 26, 2009 - 09:27 PM

  Hi Kim,
  
  first of all: Sorry for my bad English!
  
  I have just tried your code-example and could verify the failure. There are reasons, which leads to this misbehaviour:
  
  1) It is really not a good idea to ignore function-results, because PASCAL does not include this feature! I wonder, why WDSibyl supports this without any warning or error-messages.
  
  2) What happens is the following: each time you call scale whithout getting the result-value, a new value is pushed on the FPU-stack, but is never poped by the program! Since the stack will overflow after six entries, you will get FPU-exceptions while trying the seventh calculation.
  
  3) Unfortunetly WDSibyl supresses all Floatingpoint-Excheptions in the current release. Therfore you get no errormessages, but bad results instead. This should be fixed in the next release! But this will NOT get your code running! You will get an errormessage instead. To do this right, you have allways to get the result of a function-call. Ignoring it, will lead to trouble, at least with floatingpoint results!
  
  @WD: is there any compiler-option available to disable calling functions without getting the result-value? This should then be the default!
  
  Regards Peter

  •  
• kif
  

  • Registered: Oct 30, 2008
  • Last visit: Mar 18, 2009
  • Posts: 10

  Posted: Feb 26, 2009 - 10:22 PM

  Hi Peter
  
  

  Quote

  1) It is really not a good idea to ignore function-results, because PASCAL does not include this feature! I wonder, why WDSibyl supports this without any warning or error-messages.
  

  
  
  A guess would be for WDSibyl to be Delphi compatible, as it is / can be allowed there, this also is the reason I discovered the problem while trying to convert an project from Delphi.
  
  Well it's mostly a bad habit, but it have been the source of many frustrating days debugging !
  
  Kim

  •  
• Mark
  

  • Registered: Feb 07, 2008
  • Last visit: Jan 30, 2011
  • Posts: 19

  Posted: Feb 27, 2009 - 01:33 AM

  
  
  I'm not a compiler expert, nor do I know if we can change the compiler. But...
  
  Is there something wrong with getting the compiler to build code that if a return value is present, you could pop the result into that variable.
  
  But if a return value is not present, should the compiler pop the result into a bit bucket and ignore it?
  
  ==========================
  
  I' m nicht ein Compilerexperte noch weiß ich, wenn wir den Compiler ändern können. Aber…
  
  Gibt es etwas falsch mit dem Veranlassen des Kompilators, Code aufzubauen, der, wenn ein Rückholwert anwesend ist, Sie das Resultat in diese Variable knallen könnte.
  
  Aber, wenn ein Rückholwert nicht anwesend ist, sollte der Compiler das Resultat in eine Spitzenwanne knallen und es ignorieren?
  
  

  Regards,

  •  
•  
•  

Users on-line

• 0 users

This list is based on users active over the last 30 minutes.