Programming > Problems & Solutions

Can't identify next operand

(1/1)

Brian Alvarez:
 Hello Charles, i implemented the double pointer to fix an issue as you suggested like this:


--- Code: ---FUNCTION OPTIONALLYADDFUNC(?ARR_STRINGDATA *sd, LONG *index, STRING **ce) AS LONG

END FUNCTION
--- End code ---

 This fixes all the issues with any variable type, but if i ever invoke the function using a literal string like this:


--- Code: ---OPTIONALLYADDFUNC(sd, index, "0, ")
--- End code ---

 I get this during compilation:


--- Code: ---ERROR: ASSEMBLER:
 ERR: lea eax,"0, "!!  Can't identify next operand '
LINE: 1094
FILE: "main source
--- End code ---

 I know removing the double pointer fixes it but i cant generate different code depending on how it is invoked because a function can be invoked in several ways throgouth the program. Is there another way to avoid this?

 The code compiles fine when it is a function, like this:


--- Code: ---OPTIONALLYADDFUNC(sd, index, TRIM$("0, ", 0, null))
--- End code ---

 So i wonder if this is an issue with Oxygen?

Charles Pegge:
Hi Brian,

Theproblem is passing string literals and string expressions to functions expecting an array block of strings (double pointered).

Currently, this is resolved by passing literals and expressions to a temp string beforehand and passing the temp string, but I'm working on a solution.

JRS:
The literal vs. variable state isn't an easy nut to crack when using them as arguments to procedures. SB converts all string literals to a temp null terminated string before passing them along. Literals are like comments that assume to be code. Pointerless references.

Brian Alvarez:
 Thanks Charles!, i appreciate it. :)

Navigation

[0] Message Index