6.11 LTS Syntax check and debugger miss

[tj1010]

Syntax checker and debugger allow anything not a string to to be used regardless of size without showing the user why it doesn't work

This might be a documentation problem where returns aren't shown with a type; in the case there is memory safety in place

Code: Select all

EnableExplicit
Define.b something
something=ExamineDirectory(#PB_Any,GetHomeDirectory(),"*.*")
While NextDirectoryEntry(something)
  Debug DirectoryEntryName(something)
Wend
FinishDirectory(something)

[16:07:22] Waiting for executable to start...
[16:07:22] Executable type: Windows - x64 (64bit, Unicode)
[16:07:22] Executable started.
[16:07:23] [ERROR] Line: 4
[16:07:23] [ERROR] The specified #Directory is not initialised.

Code: Select all

EnableExplicit
Define.d something
something=ExamineDirectory(#PB_Any,GetHomeDirectory(),"*.*")
While NextDirectoryEntry(something)
  Debug DirectoryEntryName(something)
Wend
FinishDirectory(something)

[16:25:42] Waiting for executable to start...
[16:25:42] Executable type: Windows - x64 (64bit, Unicode)
[16:25:42] Executable started.
[16:25:42] The Program execution has finished.

Code: Select all

EnableExplicit
Define tester.b
tester=293847928472
ShowMemoryViewer(@tester,8)

[16:32:19] Waiting for executable to start...
[16:32:19] Executable type: Windows - x64 (64bit, Unicode)
[16:32:19] Executable started.
[16:32:19] The Program execution has finished.

[Demivec]

This might be a documentation problem where returns aren't shown with a type; in the case there is memory safety in place

I may be a little uncertain about the meaning of this quote. If it is referring to the help manual documentation for the ExamineDirector() function then it should be noted that the return types for all functions are documented according to the following quote, emphasis added, from the General Syntax rules of the help file:

Others

- In this guide, all topics are listed in alphabetical order to decrease any search time.

- Return values of commands are always Integer if no other type is specified in the Syntax line of the command description.
- In the PureBasic documentation, the terms "commands" and "functions" are used interchangeably, regardless of whether the function returns a value or not. To learn whether value is returned by a specific command or function, consult the description provided in the command's documentation.

[tj1010]

I was able to create a exe with the wrong type, though. Shouldn't this not make it past checker, compiler, linker, and debugging?

The first example actually shows a function returning not zero and bypassing a branch check based on a 8 byte read of a 4 byte allocation

[Demivec]

I was able to create a exe with the wrong type, though. Shouldn't this not make it past checker, compiler, linker, and debugging?

Logic errors are also not caught or signaled. The bug isn't in the checker, compiler, linker or debugger. IMHO the bug is in front of the computer.

The first example actually shows a function returning not zero and bypassing a branch check based on a 8 byte read of a 4 byte allocation

The function returned a non-zero 4 or 8 byte value depending on whether it was a 32 bit or 64 bit compilation. It bypassed the branch check because the 8 bit value held the non equivalent and incomplete portion of a 32 or 64 bit object number (depending on if it was a 32 bit or 64 bit compilation).

[Fred]

It looks more like a feature request to have another warning when a pointer truncation can occurs (which could be useful indeed)

[User_Russian]

It looks more like a feature request to have another warning when a pointer truncation can occurs

I think that the function of checking the types of variables will be useful.
Because it often happens that types are incompatible, but the compiler does not report this.

Code: Select all

a.a
q.q=1234567890
a = q

Code: Select all

Procedure Test(*Point.POINT)
  ;  Code
EndProcedure

r.RECT
Test(@r)

Code: Select all

EnableExplicit

Procedure.d Test(Param.d)
  Protected x,d ; By mistake, the symbol is a comma instead of a point.
  
  x = Param - 0.2
  
  ProcedureReturn x
EndProcedure


Debug Test(1234.5678) ; The result should be 1234.3678

[Quin]

It looks more like a feature request to have another warning when a pointer truncation can occurs

I think that the function of checking the types of variables will be useful.
Because it often happens that types are incompatible, but the compiler does not report this.

+1000. The number of times I've gotten a really weird bug because of things like this is insane.

[Demivec]

Code: Select all

Procedure Test(*Point.POINT)
  ;  Code
EndProcedure

r.RECT
Test(@r)

I don't think validating pointer types is useful or helpful, at least in enough of the cases i use.

I think the programmer has to start taking some responsibility of their own of what they are doing when using advanced features of the language.

Memory locations can be interpreted differently depending on the structured pointer referencing them. Some structures are extended versions of other structures and both point at the same address and may be assigned to each other. This includes the assignments made as a part of passing parameters. Others are dissimilar and are assigned to each other to purposely interpret the memory differently.

[User_Russian]

I don't think validating pointer types is useful or helpful, at least in enough of the cases i use.

Need to add explicit type conversion.

Code: Select all

Procedure Test(*Point.POINT)
  ;  Code
EndProcedure

r.RECT
Test(ConvertType(@r, *POINT))

I'm not saying that type checking should always be there.
Need a keyword similar to EnableExplicit, but enable type checking.

[Little John]

+100 for this feature request.

Code: Select all

Procedure Test(*Point.POINT)
  ;  Code
EndProcedure

r.RECT
Test(@r)

I don't think validating pointer types is useful or helpful, at least in enough of the cases i use.

For me, validating pointer types would have been very useful in the past, because it would have undisclosed a nasty bug in one of my programs.
And the problem did (still does?) not only exist in some code of mine, but also in code written by other people.

I think the programmer has to start taking some responsibility of their own of what they are doing when using advanced features of the language.

If this were a valid argument, we wouldn't need EnableExplicit and the Purifier and ...
One of our goals is, that our software has as less bugs as possible, no? And since to err is human, we should be happy about each technical aid that helps us to compensate our human deficiencies.

Memory locations can be interpreted differently depending on the structured pointer referencing them. Some structures are extended versions of other structures and both point at the same address and may be assigned to each other. This includes the assignments made as a part of passing parameters. Others are dissimilar and are assigned to each other to purposely interpret the memory differently.

So what? You can e.g. pass a pointer to a StructureUnion as parameter, if that is what you intend. You can also pass a pure pointer as parameter:

Code: Select all

Procedure Test (*myPointer)
  ;  Code
EndProcedure

And when I declare a procedure like this:

Code: Select all

Procedure Test (*point.POINT)
  ;  Code
EndProcedure

then I'm doing it deliberately because this is what I'm intending. Calling this procedure with a pointer to a different type would be a bug in my program, which would currently be hard to find. Of course, any help for finding any bug is appreciated.