Sscanf only supports Extended which is a problem.

[jamie]

I have been using SsanF to translate a string with two parameters separated by a comma to generate two float values.

The problem is that I use DOUBLES and they are not the same between 32bit and 64 bit, one is 10 bytes in 32 bit land while the other is only 8 which is just a double.

 Otherwise, It turns into a cluster of spaghetti code using other methods to split the string and use StrToFloat etc.


 The shortest I have come up with is using a local Extended and then from there define the actual values which are DOUBLEs


 Is there some sort of hidden flag char that is not documented to indicate a DOUBLE or even a single float type?

 Currently I only see "%f" for that.

Code: Pascal  [Select][+][-]

1.  SscanF('123.5,234.8','%f,%f',[@X,@Y]);  
2.  

Here X,Y are doubles and it works ok in 64 bit land because there is no Extended because it gets resplaced by a Double

But to compile that in 32 bit mode crashes with a memory flood.




 

[Thaddy]

sscanf is directly mapped to its C equivalent which will also crash.
Use a double on 64 bit, unless you are not on Windows.
Don't tempt me to add an example.

[PascalDragon]

The problem is that I use DOUBLES and they are not the same between 32bit and 64 bit, one is 10 bytes in 32 bit land while the other is only 8 which is just a double.

The Double type is 8-Byte no matter if it's a 64-bit or 32-bit target. It's only Extended that depends on the platform.

The shortest I have come up with is using a local Extended and then from there define the actual values which are DOUBLEs

That is the correct approach.

Is there some sort of hidden flag char that is not documented to indicate a DOUBLE or even a single float type?

No, there is not, because sscanf is based on the internals of array of const and that only supports Extended as well (though with that it's usually less obvious, because the compiler will silently convert to Extended).

[jamie]

yes I realize the compiler is using an Extended but was wondering if the function had a hidden switch in the format string to
work around that...

 Currently I have used the '%f,%f' which forces Extended but was wondering about this maybe
 '%fd,'%fd' or '%fs,%fs' for double or single types.

 I can write my own sscanf function to do this, I just thought it would be a thought for the future if not now.

[PascalDragon]

yes I realize the compiler is using an Extended but was wondering if the function had a hidden switch in the format string to
work around that...

 Currently I have used the '%f,%f' which forces Extended but was wondering about this maybe
 '%fd,'%fd' or '%fs,%fs' for double or single types.

 I can write my own sscanf function to do this, I just thought it would be a thought for the future if not now.

The function simply can not support non-Extended, because the underlying mechanism used to handle the types does not support non-Extended.

[Thaddy]

There is at least one sscanf implementation for Delphi that also compiles in FPC and supports  all features that the C function supports.
https://torry.net/components/tools/text/scanf-for-delphi
Compiles only for win32, needs small changes. (done, see attachment)
Compile with -Mdelphi and -Rintel.
Will attach fpc version later. It is written by E. Sorokin, so is proper code.
I did not convert the sctutor.dpr. You can obtain the original version from Torry's.

Compile as:
ppcross386  -Twin32  -vq5053- -FuD:\fpcupdeluxe\fpc\units\i386-win32\rtl scanf.pas
or
ppc386  -vq5053- scanf.pas
[edit] attachment removed. see below for new version
 

[Thaddy]

About the above translated code:
I have noticed the currency format does not work, though.
Quite complex to debug.
My mistake. examples.pas contains explicit errors and was not complete.
This version, including examples turned into a complete program, works as expected.

The code is still win32 only. But it is superior to the rtl's sscanf.
I compiled it with:
ppcross386  -CX -XXs -vlw5053-  examples.pas
( 5053 turns of deprecated, the code stems from 2001-2005, we used a version in production )

[Thaddy]

The function simply can not support non-Extended, because the underlying mechanism used to handle the types does not support non-Extended.

That is a pity. I will see if I can make  E. Sorokin's code a bit more cross-platform.
His code may also work on linux multiarch x_86_64/32 and linux32-i386.