Falling out the bottom of a procedure

1

I came across some weird behaviour today.

If we have a program like

  PROGRAM
  INCLUDE('StringTheory.inc'),ONCE
  MAP
testIt   PROCEDURE(STRING p),LONG 
  END
st stringTheory
  CODE
  MESSAGE('entering...')
  message('test 1: ' & testit('xxx'))
  message('test 2: ' & testit(''))
  message('test 3: ' & testit('   ')) ! 3 spaces - testit returns 3
  RETURN

testIt procedure(String p) !,long
  code
  if p then return 1.

I would have hoped for a compile error as if a blank string is passed to test1 then it doesn’t return a value, but just falls out the bottom. I didn’t see an error or any warnings either.

however testing indicates it returns the length/size of the passed string.

I didn’t expect that!

is this documented anywhere?

perhaps it is just something strange in my setup (using C11 13505) - curious to see if others can confirm it.

2

This is not documented because it is not truth.

If there is no RETURN on some branch of function’ body, and execution was routed to this branch, returned result is random - it depends from value of the EAX register if result type is integer numeric. If result type is STRING, missed RETURN can cause the fault of the string stack. If result type is REAL, returned result is random - it depends from values on the thread stack at the call time.

In your case the EAX register contained the size of the actual parameter’s string size.

3

There was an article on CMag authored by Gordon Smith on the topic. IIRC at the time of writing your code would always GPF or shutdown.

His suggestion was to always add an Explicit RETURN, then type your code above it. In your case it would cause a compile error without returning a value from a function. An implicit final Return, like you have, does not error.

The explicit RETURN also provides a line to set a debug breakpoint so you can step out of a procedure. Same with always having an explicit EXIT on a routine can help in debug.

4

thanks Alexey - I perhaps should have phrased it “testing indicates in this case it returns the length/size of the passed string” which would have been more accurate given EAX register contents will vary as you indicated.

I still think a compile error would be better.

5

Thanks Carl I will have a look for the article. At least a GPF would be obvious and not a silent miss. But a compile error would be even better!

6

Hi Alexey,

Would you consider the lack of a compiler warning/error when a typed procedure has a reachable path with no RETURN value to be a compiler bug, or would you consider it expected behaviour?

Mark