Why does this GPF?

[Simon Morgan]

The following code compiled with PB/Win 8.04 and run under XP Home generates a GPF: TestCall.exe has encountered a problem and needs to close. We are sorry for the inconvenience.

It's something to do with the BYVAL in the call to the function. Take that away and it works fine, or add BYVALs to both parameters in the Function header and it works OK. Taking away most of the 'innards' of the function also cures the problem! What's going on or what have I overlooked?

FUNCTION SplitLines(S AS STRING,MaxC AS LONG) AS STRING 
 'insert $CRLFs in place of spaces to make lines no longer than MaxC
  LOCAL SL(),S1, S2 AS STRING, L, I,J AS LONG
  L=PARSECOUNT(S,$CRLF) 
  DIM SL(1:L)
  PARSE S,SL(),$CRLF
  FOR J=1 TO L
    S2=RTRIM$(SL(J)) : S1=""
    DO WHILE LEN(S2)>MaxC
      I=INSTR(-1,LEFT$(S2,MaxC)," ")
      IF I=0 THEN I=INSTR(-1,LEFT$(S2,MaxC),ANY $DQ+",-_/\")
      IF I=0 THEN I=MaxC
      IF S1<>"" THEN S1=S1+$CRLF
      S1=S1+RTRIM$(LEFT$(S2,I))
      S2=MID$(S2,I+1)
    LOOP
    IF S1<>"" THEN SL(J)=S1+$CRLF+S2  
  NEXT J
  FUNCTION=JOIN$(SL(),$CRLF)
END FUNCTION 

FUNCTION PBMAIN
  LOCAL TBLine AS STRING, ComLen AS LONG 
  ComLen=12  
  TBLine="AAAAAAA BBBBBBBB CCCCCCCC DDDDDDD EEEEEEE"
  MSGBOX SplitLines(TBLine, BYVAL ComLen)
END FUNCTION

[Chris Holbrook]

My guess is that splitlines is expecting to get the parameter by reference. If you want to put BYVAL on the call, put it on the function header too, then it should work.

May I commend to you the use of the ? statement and of the internal debugger? I'm sure you could sort it quite quickly using these. %MB_TASKMODAL is usefule with the ? statement.

[Simon Morgan]

Well the debugger tells me that I get a Memory access violation at the point in the function where I first use the passed parameter MaxC (DO WHILE LEN(S2)>MaxC).

I had already found that repeating the BYVAL in the Function header cured the problem, but this should not be necessary. The same function should be capable of sometimes receiving its parameters BYREF (the default) and sometimes BYVAL depending upon the requirements of the calling code.

In this example it doesn't matter because the parameters are not changed within the function, but it is a convenience that works in other situations to pass to a function a parameter that normally gets changed by it BYVAL to avoid the variable in the calling procedure getting altered.

[Bob Zale]

The same function should be capable of sometimes receiving its parameters BYREF (the default) and sometimes BYVAL depending upon the requirements of the calling code.

That simply isn't true. It's one or the other. The code in the function must know how to access the parameter, and it can't possibly be both. It would be a physical impossibility. Chris' evaluation and suggestion is correct.

Best regards,

Bob Zale
PowerBASIC Inc.

[Simon Morgan]

Thanks, Bob. Mea culpa. I should have read the help file more carefully:

When you pass parameters from the calling code with an explicit BYVAL, you effectively switch off the compilers type-checking for that parameter. This can be useful in cases where the called code is expecting a BYREF parameter, and you wish to pass an address of another data type that would trigger a compile-time error without the BYVAL method.

I must have been thinking of BYCOPY as a way to avoid a variable in the calling code from being changed.

[Michael Mattias]

The help file STILL qualifies the 'switch off type-checking' with effectively?

It's not 'effectively' off, it's not 'virtually' off, it's OFF! That's what OVERRIDE means!

[Bob Zale]

Which effectively adds a nice virtual touch, don't you think?

[Michael Mattias]

I didn't realize you were such a sensitive and caring guy...I'm virtually touched.