Page 1 of 1
6.11 LTS Syntax check and debugger miss
Posted: Mon Jul 08, 2024 9:04 pm
by 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.
Re: 6.11 LTS Syntax check and debugger miss
Posted: Tue Jul 09, 2024 1:01 am
by Demivec
tj1010 wrote: Mon Jul 08, 2024 9:04 pm
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.
Re: 6.11 LTS Syntax check and debugger miss
Posted: Tue Jul 09, 2024 1:30 am
by 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
Re: 6.11 LTS Syntax check and debugger miss
Posted: Tue Jul 09, 2024 6:05 am
by Demivec
tj1010 wrote: Tue Jul 09, 2024 1:30 am
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).
Re: 6.11 LTS Syntax check and debugger miss
Posted: Tue Jul 09, 2024 10:39 am
by Fred
It looks more like a feature request to have another warning when a pointer truncation can occurs (which could be useful indeed)
Re: 6.11 LTS Syntax check and debugger miss
Posted: Tue Jul 09, 2024 2:34 pm
by User_Russian
Fred wrote: Tue Jul 09, 2024 10:39 am
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
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
Re: 6.11 LTS Syntax check and debugger miss
Posted: Tue Jul 09, 2024 2:36 pm
by Quin
User_Russian wrote: Tue Jul 09, 2024 2:34 pm
Fred wrote: Tue Jul 09, 2024 10:39 am
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.
Re: 6.11 LTS Syntax check and debugger miss
Posted: Wed Jul 10, 2024 12:11 am
by Demivec
User_Russian wrote: Tue Jul 09, 2024 2:34 pm
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.
Re: 6.11 LTS Syntax check and debugger miss
Posted: Wed Jul 10, 2024 11:16 am
by User_Russian
Demivec wrote: Wed Jul 10, 2024 12:11 amI 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.
Re: 6.11 LTS Syntax check and debugger miss
Posted: Wed Jul 10, 2024 3:43 pm
by Little John
+100 for this feature request.
Demivec wrote:
User_Russian wrote: Tue Jul 09, 2024 2:34 pm
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.
Demivec wrote:
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.
Demivec wrote:
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.