Compiler not check wrong *.x passed to Proc(*.y)

[skywalk]

This error is hard to find.
Maybe this is a Feature Request, but I hoped the compiler would tell me I passed the wrong datatype to a Procedure before running the code.
ASM produces runtime IMA which can be helpful to find problem.
CBE just quits: "The debugged executable quit unexpectedly." Now you are forced to find the C output error log?

Code: Select all

EnableExplicit
Structure structI
  a.i
  b.i
EndStructure
Structure structStr
  a$
  b$
EndStructure
Procedure.i DoStr(*p.structStr)
  ProcedureReturn Val(*p\b$)  ;<-- IMA
EndProcedure
Procedure.i DoI(*p.structI)
  ProcedureReturn *p\b
EndProcedure
Global.i y
Global xstr.structStr
xStr\b$ = "xStr"
Global xi.structI
xI\b = 2
y = DoI(xStr) ;<-- Compiler accepts wrong datatype for parameter.
Debug y
y = DoStr(xI) ;<-- Compiler accepts wrong datatype for parameter.
              ;<-- And generates a run-time IMA.
Debug y
; [14:17:52] Waiting for executable to start...
; [14:17:52] Executable type: Windows - x64  (64bit, Unicode, Thread, Purifier)
; [14:17:52] Executable started.
; [14:17:52] [ERROR] BUG_v6_compiler-not-catch-bad-proc(ptr.wrongtype).pb (Line: 11)
; [14:17:52] [ERROR] Invalid memory access. (read error at address 2)
; [14:17:57] The Program was killed.

[mk-soft]

PB has no management to check the data types of pointers. It can also be an unknown structure from a third party, or it can also overlay data types, which is very helpful.
Only the C backend should also come back with a better error code.

[skywalk]

Yes, if an overlaid structure or structureunion was passed, that is possible.
Regardless, I want to know with a warning that the structures are not identical.

[STARGÅTE]

What is the bug-report in this topic?

Maybe this is a Feature Request, but I hoped the compiler would tell me I passed the wrong datatype to a Procedure before running the code.

Why you then post in Bugs?
The PureBasic compiler only checks for numeric or string data types, because they are handled differently.
There is no error code given, when you pass a float to a integer argument or a pointer to a float argument.
In your case you pass a pointer (no more no less) and the procedure argument wants a pointer (no more no less).

[nsstudios]

ASM produces runtime IMA which can be helpful to find problem. CBE just quits: "The debugged executable quit unexpectedly."

I can't reproduce that, both asm and c backends, 64 and 32 bit report an invalid memory access at line 11 here (Windows 10 22h2).
Perhaps that's something to look into, but according to

Unfortunately the purifier isn't as good with the C backend, as we can't check local variable overflow. The good news is we should now be able to use C specific tools like Valgrind or Purify when compiling in debug mode with symbols.

, the c backend doesn't catch as many errors (maybe I'm just misunderstanding, though).
It would be nice if pb knew about pointer types, but at the very least it should produce ima, because I do agree that it's hard to find a problem if all you get is a crash.
One solution that I thought of would be using SizeOf to verify, but doesn't necessarily help if you have a structure with 8 bytes or another structure with two longs, for example.

[skywalk]

STARGATE - It is a bug in that the CBE compiler gives me nothing but a crash.
All variables including pointers are defined somewhere in the code.
Passing the wrong pointer to a procedure parameter must at least give a warning.
How is that difficult when standard datatypes are not allowed to pass incorrectly?

[STARGÅTE]

Passing the wrong pointer to a procedure parameter must at least give a warning.

No, it doesn't have to! The syntax of the code is valid --> no compiler error. In PureBasic you have a pointer, just a pointer. For PureBasic it is completely irrelevant whats behind the pointer. That's how PureBasic works since version 1.0. The structure definition in the procedure argument is just to have access to specific memory offsets und data formats.
In particular, even passing a structured variable to a procedure is just the short form of: DoI(@xStr) and DoStr(@xI), because you pass not really a structured variable, but just the address.

How is that difficult when standard datatypes are not allowed to pass incorrectly?

It isn't, but it is a request for PureBasic, not a Bug report. Maybe: EnableTypeCheck
But keep in mind, then you have also write something like:
x.f = Float(y.i) instead of x.f = y.i, to avoid a "warning".
Or z.i = Int(Pow(Float(x.i), Float(y.i))) instead of z = Pow(x, y) .

[skywalk]

Wow, my point here is to help others not have to chase down valid syntax which leads to an IMA.
A warning is not a crazy ask.