XSharpPublic icon indicating copy to clipboard operation
XSharpPublic copied to clipboard

clipper calling convention. ( VO and FP )

Open Karl1155 opened this issue 5 years ago • 3 comments

This code compiles and runs even though the datatype of the return value is declared.

FUNCTION Start() AS VOID

	? ClipTest1() == 0
	? ClipTest2() == NULL_STRING
	? ClipTest3() == NULL_ARRAY	
	? ClipTest4() == NULL_SYMBOL
	? ClipTest5() == NULL_CODEBLOCK	

RETURN


FUNCTION ClipTest1 ( a , b , c  ) AS FLOAT CLIPPER 	 
	
	RETURN NIL // <------
	
FUNCTION ClipTest2 ( a , b , c  ) AS STRING CLIPPER 	 
	RETURN NIL // <------

FUNCTION ClipTest3 ( a , b , c  ) AS ARRAY CLIPPER 	 
	RETURN NIL // <------
	
FUNCTION ClipTest4 ( a , b , c  ) AS SYMBOL CLIPPER 	 
	RETURN NIL // <------
	
FUNCTION ClipTest5 ( a , b , c  ) AS CODEBLOCK CLIPPER 	 
	RETURN NIL // <------

Karl-Heinz

Karl1155 avatar May 22 '20 09:05 Karl1155

Karl-Heinz, Yes, and this is by design.

For the compiler this is the same as

FUNCTION ClipTest1 ( a , b , c  ) AS FLOAT CLIPPER 	
	LOCAL u := NIL  AS USUAL
	RETURN u

There is an implicit conversion from the USUAL type to all of the types that you have specified. So the compiler will generate something like this:

FUNCTION ClipTest1 ( a , b , c  ) AS FLOAT CLIPPER 	 
	RETURN (FLOAT) NIL // <------

At this moment this returns 0, but I tested this in VO and it should produce a (runtime) error.

See https://github.com/X-Sharp/XSharpPublic/blob/main/src/Runtime/XSharp.RT/Types/Usual.prg#L2404

Robert

RobertvanderHulst avatar May 22 '20 10:05 RobertvanderHulst

Robert,

RETURN (FLOAT) NIL // puuh, never thought that something like this is legal.

At first sight i thought VO throws an compile error, but it´s a warning e.g. "converting NIL->STR:51423". And yes at runtime a NIL-> FLOAT throws an DATA TYPE ERROR. The only line that works is:

? ClipTest3() == NULL_ARRAY

But do you agree, that X# should throw a warning like VO does ?

Karl-Heinz

Karl1155 avatar May 22 '20 11:05 Karl1155

Karl-Heinz

"should throw" no. "would be nice if it throws", yes.

The problem is that the code that decides if a conversion from one type to another type is implicitly supported by the language would then also have to take into account if that type is stored in a variable or if that type is defined in a literal.

At this moment the code does not do that. And when we do make that distinction then we have to make sure that the same rules are defined in the runtime and in the compiler. It may be tricky to keep these in sync.

Robert

RobertvanderHulst avatar May 22 '20 11:05 RobertvanderHulst