Sign in Join

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

Mailing lists / fpc-pascal / 2006-01

A simple "exception handling" question

14 messages · 6 people · –

Reply by email Subscribe to this list Your subscription

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

Bob Richards

I must not understand a fundamental concept here. Perhaps someone can point me in the right direction.

{$mode Delphi} //Delphi or objfpc same results
program hextest; // or why can't I trap an exception?
 uses Sysutils,strutils;
 var
  b:byte;
  hex:string;
begin
  Write('Enter a hex String: ');
  ReadLn(hex);
   Try
     b:=Hex2Dec(Hex);
   Except
    On EConvertError do
    Begin
      WriteLn(hex,' is not a valid hex number! Terminating...');
      Halt
    end
   end;
  WriteLn('Hex value ',hex,' is decimal value: ',b)
end.

Upon execution:

$ ./hextest
Enter a hex String: 0A
Hex value 0A is decimal value: 10

Cool!

$ ./hextest
Enter a hex String: FF
Hex value FF is decimal value: 255

Still Cool!

$ ./hextest
Enter a hex String: ZZ
Hex value ZZ is decimal value: 0

Certainly NOT cool!

According to the docs on function "Hex2Dec" in Strutils:

"If S does not contain a valid hexadecimal value, an EConvertError exception will be raised."

So, what profound lack of understanding am I suffering from? Anybody?

Bob

Reply by email

Michalis Kamburelis
to Bob Richards: I must not understand a fundamental concept here. Perhaps someone can point me in the…

Bob Richards wrote:
[...]

Show quoted text 7 lines
According to the docs on function "Hex2Dec" in Strutils: "If S does not contain a valid hexadecimal value, an EConvertError exception will be raised." So, what profound lack of understanding am I suffering from? Anybody?

There's a bug in Hex2Dec implementation -- it returns 0 instead of raising EConvertError. Here's a patch:

Index: strutils.pp
=================================================================== --- strutils.pp (wersja 2298)
+++ strutils.pp (kopia robocza)
@@ -1156,7 +1156,7 @@

      HexStr:='$'+ S
    else
      HexStr:=S;

- Result:=StrTointDef(HexStr,0);
+ Result:=StrToint(HexStr);

  end;
  function Dec2Numb(N: Longint; Len, Base: Byte): string;

Reply by email

Bob Richards
to Michalis Kamburelis
Michalis Kamburelis wrote 17 lines
There's a bug in Hex2Dec implementation -- it returns 0 instead of raising EConvertError. Here's a patch: Index: strutils.pp =================================================================== --- strutils.pp (wersja 2298) +++ strutils.pp (kopia robocza) @@ -1156,7 +1156,7 @@ HexStr:='$'+ S else HexStr:=S; - Result:=StrTointDef(HexStr,0); + Result:=StrToint(HexStr); end; function Dec2Numb(N: Longint; Len, Base: Byte): string; _______________________________________________

First, thanks for the reply; I applied the patch, it applied without a problem, verified the new StrUtils.pp source, all OK as per the patch. Recompiled strutils.ppu. The function still returns a zero on error.

Is there another patch I need as well?
This is fpc 2.0.0 on Linux, but at this level I don't think it should matter.

Sorry for being dense :-(

Bob

PGP Encrypted E-Mail Prefered Public Key at: http://www.tamara-b.org/~bob/pubkey.asc .

Reply by email

Michalis Kamburelis
to Bob Richards
Bob Richards wrote 27 lines
Michalis Kamburelis wrote: >There's a bug in Hex2Dec implementation -- it returns 0 instead of >raising EConvertError. Here's a patch: > >Index: strutils.pp >=================================================================== >--- strutils.pp (wersja 2298) >+++ strutils.pp (kopia robocza) >@@ -1156,7 +1156,7 @@ > HexStr:='$'+ S > else > HexStr:=S; >- Result:=StrTointDef(HexStr,0); >+ Result:=StrToint(HexStr); > end; > > function Dec2Numb(N: Longint; Len, Base: Byte): string; >_______________________________________________ First, thanks for the reply; I applied the patch, it applied without a problem, verified the new StrUtils.pp source, all OK as per the patch. Recompiled strutils.ppu. The function still returns a zero on error. Is there another patch I need as well?

I'm quite sure that my patch is all you need. I tested it on my system with your test program hextest, and it fixed the situation. So my guess is that you're probably mistakenly using old compiled version of strutils unit instead of the patched one. Check it -- e.g. add some trivial

   Writeln('i am the new version');

inside Hex2Dec implementation and see if your hextest prints this message.

You can also just paste the corrected implementation of Hex2Dec inside your program, this will also fix the bug, without the need to recompile strutils unit.

Of course, ultimately the solution is to wait until this patch will be applied to FPC sources and then use updated FPC version from SVN.

Michalis

Reply by email

Michael Van Canneyt
to Michalis Kamburelis: I'm quite sure that my patch is all you need. I tested it on my system with your test…
Michalis Kamburelis wrote 44 lines
Bob Richards wrote: > Michalis Kamburelis wrote: > > > > There's a bug in Hex2Dec implementation -- it returns 0 instead of > > raising EConvertError. Here's a patch: > > > > Index: strutils.pp > > =================================================================== > > --- strutils.pp (wersja 2298) > > +++ strutils.pp (kopia robocza) > > @@ -1156,7 +1156,7 @@ > > HexStr:='$'+ S > > else > > HexStr:=S; > > - Result:=StrTointDef(HexStr,0); > > + Result:=StrToint(HexStr); > > end; > > > > function Dec2Numb(N: Longint; Len, Base: Byte): string; > > _______________________________________________ > > > First, thanks for the reply; I applied the patch, it applied without a > problem, verified > the new StrUtils.pp source, all OK as per the patch. Recompiled > strutils.ppu. The function > still returns a zero on error. > > Is there another patch I need as well? I'm quite sure that my patch is all you need. I tested it on my system with your test program hextest, and it fixed the situation. So my guess is that you're probably mistakenly using old compiled version of strutils unit instead of the patched one. Check it -- e.g. add some trivial Writeln('i am the new version'); inside Hex2Dec implementation and see if your hextest prints this message. You can also just paste the corrected implementation of Hex2Dec inside your program, this will also fix the bug, without the need to recompile strutils unit. Of course, ultimately the solution is to wait until this patch will be applied to FPC sources and then use updated FPC version from SVN.

Patch is applied.

Michael.

Reply by email

L505
to Marco van de Voort: You are aware of the fact that the .o's belong to units too? Delphi .dcu = fpc .ppu + fpc…
> First, thanks for the reply; I applied the patch, it applied without a problem,

verified

> the new StrUtils.pp source, all OK as per the patch. Recompiled strutils.ppu. The

function

Show quoted text 5 lines
> still returns a zero on error. You are aware of the fact that the .o's belong to units too? Delphi .dcu = fpc .ppu + fpc .o !

And also, in addition to Marco's comment, are you aware that you must copy the files to the correct folder after compiling them, i.e. not just compiling them and leaving them in the actual Source directories. And if you have dual compilers installed on your system of course, make sure you copy to the right folder and not the wrong one. And also, smartlinked units contain .A files in addition to .O and .PPU files

Reply by email

Bob Richards
to Marco van de Voort: You are aware of the fact that the .o's belong to units too? Delphi .dcu = fpc .ppu + fpc…
Marco van de Voort wrote
You are aware of the fact that the .o's belong to units too? Delphi .dcu = fpc .ppu + fpc .o !

Dumb me! Nope! And this was the problem. I just copied the new strutils.ppu file into /usr/lib/fpc/... NOT the strutils.o as well. So when the executable got "linked" it got linked with the wrong (old un-patched) code.

It now works! Thanks.... Guess I will have to pay more attention to the compiler, as I tend to use the compiler as if it were "God", and any problems are obviously mine and mine alone.

Lesson Learned! thank you all very very much.

Is there a list of similar "patches" to bugs? I would like to nip the next one in the bud so to speak. :-)

An Aside: This FPC has allowed me to ressurect so much of my source-code from the early days, of ARPANET, and FIDONET, that it has become a real big asset (not to mention a lot of fun)! I drooled when I saw all the new functions and procedures available.... Nifty stuff! What I have to keep in the back of my mind, is, that this is User-Supported.... and as such will have the occasional "bug".

PGP Encrypted E-Mail Preferred Public Key at: http://www.tamara-b.org/~bob/pubkey.asc .

Reply by email

Bob Richards
to L505: verified function And also, in addition to Marco's comment, are you aware that you must…
L505 wrote
And also, smartlinked units contain .A files in addition to .O and .PPU files

This brings up another nagging question I have had. If I set SpartLinking ON, my executables are no smaller! Your reply here seems to suggest, that I do not have any of my units compiled with SmartLinking enabled. There are no ".A" files in my source tree.

To enable Smart Linking, do I need to recomplile the sources with some switch allowing SmartLinking to be active? The Docs, imply NO, that this is the default; your reply above implies Yes.

Bob

PGP Encrypted E-Mail Prefered Public Key at: http://www.tamara-b.org/~bob/pubkey.asc .

Reply by email

Jonas Maebe
to Bob Richards
Bob Richards wrote 15 lines
> And also, smartlinked units contain .A files in addition to .O > and .PPU files This brings up another nagging question I have had. If I set SpartLinking ON, my executables are no smaller! Your reply here seems to suggest, that I do not have any of my units compiled with SmartLinking enabled. There are no ".A" files in my source tree. To enable Smart Linking, do I need to recomplile the sources with some switch allowing SmartLinking to be active? The Docs, imply NO, that this is the default; your reply above implies Yes.

To compile a unit so it is smartlinkable afterwards, compile it using the -CX option.

To enable the smartlinking of units compiled as above when you compile your program, use -XX.

In practice, you can always use both -CX and -XX, regardless of whether you're compiling a program or unit.

Jonas

Reply by email

L505
to Bob Richards: This brings up another nagging question I have had. If I set SpartLinking ON, my…
This brings up another nagging question I have had. If I set SpartLinking ON, my executables are no smaller! Your reply here seems to suggest, that I do not have

any of my

units compiled with SmartLinking enabled. There are no ".A" files in my source

tree.

To enable Smart Linking, do I need to recomplile the sources with some switch

allowing

SmartLinking to be active? The Docs, imply NO, that this is the default; your reply

above

Show quoted text 5 lines
implies Yes. Bob

Sometimes with Lazarus you get *no* smartlinked units on Win32.

Which installation/ide are you using for FPC, just FP-IDE or commandline, or Lazarus?

If you do need to recompile your units, use the OPT="-CX" with the "make" command. But you really shouldn't have to do this, unless you are using Lazarus win32 and you want to rebuild the default non-smartlinked shipment.

.A, .O, .ppu files and etc. will be in a special folder called "units", whereas the source code is actually in several directories all over the place. The "units" directory is more like a "build output" directory for storage of the object/binary files.

Example:
C:\pascal\FPC_2.0.2\units\i386-win32\rtl\

This is where my .A files are for Winblows.

Reply by email

L505
> SmartLinking to be active? The Docs, imply NO, that this is the default; your

reply

above > implies Yes. > > Bob

Also, if your exe/elf is still not smaller after you find the .A files, try using the -Ba option which rebuilds all units, incase your old .O files are sticking like molasses.

Reply by email

Bob Richards
to L505: any of my tree. allowing above Sometimes with Lazarus you get *no* smartlinked units on…
L505 wrote
Which installation/ide are you using for FPC, just FP-IDE or commandline, or Lazarus?

Free Pascal Compiler version 2.0.0 [2005/05/15] for i386 I don't use an IDE, I simply use vi to edit source, and then "fpc sourcefile" to produce the executable.

.A, .O, .ppu files and etc. will be in a special folder called "units", whereas the

Yeah I found them in the rtl units directory... along with the .ppu, and .o files. After your first reply, I did a quick "locate *.A" found nothing :-( Of course, on my system they are .a I instantly ASSUMED the lack of .A files, was the reason I couldn't ever smartlink a program. I had been using {$SMARTLINK ON} at the top of the source file, but this NEVER did anything. the -XX was the trick.

So, I recompiled strutils with the patch and with the -CX command line, and I still couldn't find strutils.a HOWEVER, I did find a new libpstrutils.a. Moving that over to /usr/lib/fpc/2.0.0/units/i386-linux/rtl and recompiling my program with the -XX produced a properly working elf, 1/3 the size of the old elf. -XX and -CX are now permanantly in /etc/fpc.cfg VERY NICE, and THANKS all!

I also appreciate your patience with this...

Bob

PGP Encrypted E-Mail Preferred Public Key at: http://www.tamara-b.org/~bob/pubkey.asc .

Reply by email