This patch adds recognition for hex to Val().

Sterling

---------------------------------
Post your free ad now! Yahoo! Canada Personals

Here's a patch (Delphi also accepts uppercased X) and optimization for the patch =) (To be applied to the same code version as your patch)

Regards,
Thomas

In reply to Thomas Schatzl:

Another optimization for your patch is to set a var to length(s) at the beginning of the proc, and use the var instead. It's called often enough that a little time could be shaved off.

---------------------------------
Post your free ad now! Yahoo! Canada Personals

Thomas Schatzl wrote

Sterling Bates schrieb: > This patch adds recognition for hex to Val().

Applied.

What about the extended (?) pascal convention 16#ffff ?

Done. =)

But until asking you to have a look at it, I've some questions:

- for non-64 bit CPUs there's a fpc_val_int64_shortstr and fpc_val_qword_shortstr helper function in sstrings.inc in addition to some note indicating problems with 1.0.10.
Are these two helper functions still needed in 1.9.x? (Since it's a "feature" it will possible not be added until 2.0 anyway, so I'm asking if I could skip these two methods?)
I mean, with 1.9.x compilers the hacks used there should not be necessary... (I think)

- signs for non-base 10 numbers: should they be allowed or not? E.g. Delphi allows -0x1234, -$1234 etc. At the moment this is implemented. The only problem is -$80000000.... (Delphi gives -2147...)

- I implemented this feature according to the ebnf for Extended Pascal (http://www.fh-jena.de/~gmueller/Kurs_halle/pas_extp.html), "extended-number" nonterminal. This allows leading zeros in front of the base specifier; is this ok?
E.g. 0000000012#1234 is the same as 12#1234.
Since the sign is not included in this rule, I simply added it at the front of the number, e.g. -12#1234, not 12#-1234 (which may be possible). Don't have a compiler available, and I think the former is better anyway, but is that ok?

- I fixed some other bugs in the current implementation, especially with edge values (e.g. $ffffffff with Cardinals). Hope this is ok =) =)

Regards,
Thomas

Hello,

And here's the patch, including an example program. I decided to send them anyway because some of the issues raised by myselves below were solved by some further investigation.

There is actually no problem as indicated by the comment "{ high(int64) produces 0 in version 1.0 (JM) }" in 1.0.10 which I consider the base compiler for cycling.
E.g. 1.0.10 returns the correct value for high(int64).

Are these two helper functions still needed in 1.9.x? (Since it's a "feature" it will possible not be added until 2.0 anyway, so I'm asking if I could skip these two methods?)

I prepared the "normal" val() methods to be able to handle 64 bit integers too - it'd work if ValSInt and ValUInt were 64 bit sized (speaking about fpc_Val_SInt_ShortStr, fpc_Val_UInt_ShortStr). Drawback: then 64 bit internal calculations would be done for _every_ val() invocation (also on 32 bit processors).

Compiles and works fine on 1.0.10 too, but doesn't cycle due to other bugs when starting with 1.0.10 (cycling with 1.9.9 is ok).

I did _not_ change the 64 bit integer functions (fpc_val_int64_shortstr, fpc_val_qword_shortstr) at the moment, e.g. they don't support the Extended Pascal notation too. If that is required, I can easily do them too (but since the normal methods already work for 64 bit ints on 32 bits processors...)

- signs for non-base 10 numbers: should they be allowed or not? E.g. Delphi allows -0x1234, -$1234 etc. At the moment this is implemented. The only problem is -$80000000.... (Delphi gives -2147...)

This has been resolved and is completely normal.

Regards,
Thomas

P.S.: Attached zip includes my test suite, maybe it can be useful too.