Val(x$) works only up to some string length

[Michael Mattias]

Looks more to me like misuse of the Val command.

That may be so, but shouldn't a misuse return an error? Even if it's the 'catchall' "5 Illegal Function Call?"

MCM

[Roger Garstang]

Looks more to me like misuse of the Val command. I had recommended
that it be modified to process -1 and 1- variations of negative
numbers because many reports I process have both, and I was told
it couldn't be implemented because of this very thing...people using Val
the wrong way and it would break their code. I doubt any single
number being converted would be 32,000+ digits. Especially since PB's
numeric variables don't have that much precision. Val DOESN'T Parse
and was never intended to.

Sounds more like the parsing needs to be improved and the values
passed to the Val function one at a time.

------------------
If you aim at nothing...you will hit it.

[This message has been edited by Roger Garstang (edited March 23, 2005).]

[Borje Hagsten]

> and it's taken nine years or so for anyone to notice

Yeah, it's not exactly a show-stopper, I would say. But it's been
reported in now, so expect to see it being fixed well within the
next 9-year period..


------------------
PowerBASIC Staff
------------------
Private web-site: http://www.tolkenxp.com/pb
Free downloads: POFFS, incLean, PBcodec, custom controls and PB samples.

[Michael Mattias]

>Seems to be an Integer limit to string length there, yes

What's really strange, though.. when you reduce %NUM_DIGITS to 100, the function correctly returns the value 1.

.. but when the string is longer..once the VAL function hits the space after the first "1" in the string, it should stop looking anyway; so the length of string seems totally immaterial.

A true mystery:
When string size small, VAL stops looking after first 'group of digits' is terminated
When string size big, VAL makes boo-boo, but does not set error.

If I didn't know better, I'd bet someone missed something when converting the "VAL" RTL from MS-DOS to 32-bit Windows and it's taken nine years or so for anyone to notice.

[Borje Hagsten]

Seems to be an Integer limit to string length there, yes. I'll forward
it to R&D for investigation - thanks! (it's same in the latest compilers)


------------------
PowerBASIC Staff
------------------
Private web-site: http://www.tolkenxp.com/pb
Free downloads: POFFS, incLean, PBcodec, custom controls and PB samples.

[Michael Mattias]

Wring forum, but ggod observation.

Reveals bug in PB/Win 7.02 (no error set).

If you are using a later compiler version, you can run same program and see if it has been fixed.

' test_Val.bas
' compiler: PB/Windows v 7.02
#COMPILE EXE

%NUM_DIGITS  = 10000
FUNCTION PBMAIN() AS LONG
    
    LOCAL Z AS STRING, I AS LONG, E AS LONG, iVAL AS LONG
    
      FOR I = 1 TO  %NUM_DIGITS
          Z = Z & FORMAT$(I) & $SPC
      NEXT
      iVAL = VAL(Z)
      E    = ERRCLEAR
      MSGBOX USING$ ("String  &  Length ###### Val ####.##  Error ###", LEFT$(Z,12), LEN(Z), iVal, E)
      
END FUNCTION

[Dieny du Toit]

The length of tptr$ is just over 37k, and it consists of

1 2 12 7 221 21 5 (etc.)

Val(tptr$) gives a zero. In the bit of code below, the values
are obtained by extracting each space=terminated number into
o$, where it does have a value.

Tptr$=Trim$(Tptr$)+" "
 o$=Left$(tptr$,InStr(tptr$," "))

 While Val(o$)>0
  tpt&=Val(o$)
  m$=refLst$(tpt&)
  Control Set Text ArcDlg&, 1001, Str$(tpt&)+"  "+Left$(m$,36)
  Put$ frf&, m$
  Tptr$=Right$(Tptr$,Len(Tptr$)-InStr(Tptr$, " "))
  Tptr$=Trim$(Tptr$)+" "
  o$=Left$(tptr$,InStr(tptr$," "))
  Wend

Not a problem, but may be of interest.


------------------
[email protected]