It hasn't become loose at all. But with pointers it shows more leniency.dodicat wrote:Pascal is known for being very strictly typed. I am surprised it has become so loose.
methods of accessing bytes by pointer
Re: methods of accessing bytes by pointer
Re: methods of accessing bytes by pointer
Not that I can think of right now. But if something comes to minid, I'll let you know.fxm wrote:Apart from my last update of the ZSTRING page, do you think there is still information missing in the documentation (related to your thinking around this thread)?Munair wrote:But this thread gave me a lot of additional insight with issues not found in the documentation, which was very helpful.
Re: methods of accessing bytes by pointer
...
Last edited by dodicat on Dec 12, 2017 13:37, edited 1 time in total.
Re: methods of accessing bytes by pointer
fxm wrote:In order to make calling the C runtime functions very easy, any string type argument may be directly passed to a procedure referring to a parameter declared as '[const] zstring [const] ptr'. The compiler performs itself an automatic conversion (without warning message) between string and '[const] zstring [const] ptr'.
In the documentation text, capacity to ignore const-ness is not precised because it is considered as a bug:C Standard Library Functions page wrote:Note: In order to make calling the C runtime functions very easy, any string type argument may be directly passed to a procedure referring to a parameter declared as 'zstring ptr'. The compiler performs itself an automatic conversion (without warning message) between string and 'zstring ptr'.
#734 Passing String argument to Zstring Ptr parameter ignores Constness
Re: methods of accessing bytes by pointer
I like the feature that any string type argument may be directly passed to a procedure referring to a parameter declared as 'zstring ptr'. Given the current pointer restriction in FB, I would indeed consider it a bug (non-consistent behaviour).fxm wrote:fxm wrote:In order to make calling the C runtime functions very easy, any string type argument may be directly passed to a procedure referring to a parameter declared as '[const] zstring [const] ptr'. The compiler performs itself an automatic conversion (without warning message) between string and '[const] zstring [const] ptr'.In the documentation text, capacity to ignore const-ness is not precised because it is considered as a bug:C Standard Library Functions page wrote:Note: In order to make calling the C runtime functions very easy, any string type argument may be directly passed to a procedure referring to a parameter declared as 'zstring ptr'. The compiler performs itself an automatic conversion (without warning message) between string and 'zstring ptr'.
#734 Passing String argument to Zstring Ptr parameter ignores Constness
Re: methods of accessing bytes by pointer
On closer look at the bug report, it would be much simpler to do away with constness on pointers. Pointers are meant to access memory directly, as opposed to regular data types. So my suggestion would be to disallow the const clause as soon as the declaration is a pointer/ptr:
Code: Select all
dim s1 as const zstring * 10 ' ok
dim s2 as const zstring ptr 'const not allowed because pointer
Re: methods of accessing bytes by pointer
I like typed programming languages (this reduces the number of errors that are not detected by the compiler):
- I always correct the code to cancel all the compile warning messages.
- Often, this reveals variable declaration faults, and rarely I use explicit casting to solve a warning.
- But even in that case, I have at least analyzed the problem before casting a variable as ultimate solution.
So at worst I would agree that this type of error on the pointers (bad const-ness on data pointed at pointer assignment level) becomes a warning of high level, but that's all.
- I always correct the code to cancel all the compile warning messages.
- Often, this reveals variable declaration faults, and rarely I use explicit casting to solve a warning.
- But even in that case, I have at least analyzed the problem before casting a variable as ultimate solution.
So at worst I would agree that this type of error on the pointers (bad const-ness on data pointed at pointer assignment level) becomes a warning of high level, but that's all.
Re: methods of accessing bytes by pointer
Remark about:
If 'PChar' is a 'ZSTRING PTR',
Warning: 'CONST PChar' in not a 'CONST ZSTRING PTR' but a 'ZSTRING CONST PTR'
Code: Select all
Type PChar As Zstring Ptr
Type CPChar As Const Pchar
Warning: 'CONST PChar' in not a 'CONST ZSTRING PTR' but a 'ZSTRING CONST PTR'
Re: methods of accessing bytes by pointer
The question would then be whether FreeBASIC should be more like C than like QuickBASIC. Why mimic C behaviour whereas most syntax is QuickBASIC? FreeBASIC should have an identity of its own, rather than applying rules because C (or another language) does the same thing.
QuickBASIC supported memory access (varptr, varseg, sadd) but there was no const restriction. So what would be the benefit? To prevent writing to the memory area of a const variable? If a programmer decides to do that, it's a choice. FreeBASIC also allows UBYTE = &h80 without any protest (it is up to the programmer to check this). At best, the compiler might give a hint (when chosen to) to let the programmer know what's going on.
There are a lot of other situations I can think of that would result in segmentation errors. Restricting pointers doesn't prevent that. It only honors a definition, nothing more. There's nothing crucial or beneficial to it. Meanwhile I will settle for two pointer types. ;-)
QuickBASIC supported memory access (varptr, varseg, sadd) but there was no const restriction. So what would be the benefit? To prevent writing to the memory area of a const variable? If a programmer decides to do that, it's a choice. FreeBASIC also allows UBYTE = &h80 without any protest (it is up to the programmer to check this). At best, the compiler might give a hint (when chosen to) to let the programmer know what's going on.
There are a lot of other situations I can think of that would result in segmentation errors. Restricting pointers doesn't prevent that. It only honors a definition, nothing more. There's nothing crucial or beneficial to it. Meanwhile I will settle for two pointer types. ;-)
Re: methods of accessing bytes by pointer
I was talking about CONST ZSTRING PTR. See my example above. it is the reason why I declared PCCHAR (Pointer to Constant CHaracter, not constant pointer).fxm wrote:Remark about:If 'PChar' is a 'ZSTRING PTR',Code: Select all
Type PChar As Zstring Ptr Type CPChar As Const Pchar
Warning: 'CONST PChar' in not a 'CONST ZSTRING PTR' but a 'ZSTRING CONST PTR'
I did not declare CPCHAR for that very reason!
Last edited by Munair on Dec 10, 2017 11:17, edited 2 times in total.
Re: methods of accessing bytes by pointer
Code: Select all
TYPE PCHAR AS ZSTRING PTR ' pointer to character
TYPE PCCHAR AS CONST ZSTRING PTR ' pointer to constant character
TYPE CPCHAR AS ZSTRING CONST PTR ' constant pointer to character
TYPE CPCCHAR AS CONST ZSTRING CONST PTR ' constant pointer to constant character
Re: methods of accessing bytes by pointer
I agree with you that there are already plenty of implicit conversions (between built in datatypes) that I consider illegal. Why add more?Munair wrote:FreeBASIC also allows UBYTE = &h80 without any protest (it is up to the programmer to check this). At best, the compiler might give a hint (when chosen to) to let the programmer know what's going on.
Re: methods of accessing bytes by pointer
It shouldn't be an implicit conversion. Simply uncouple the pointer-const relationship. ;-) Getting rid of the current illegal implicit conversions would be a great thing by the way.fxm wrote:I agree with you that there are already plenty of implicit conversions (between built in datatypes) that I consider illegal. Why add more?Munair wrote:FreeBASIC also allows UBYTE = &h80 without any protest (it is up to the programmer to check this). At best, the compiler might give a hint (when chosen to) to let the programmer know what's going on.
Re: methods of accessing bytes by pointer
:-(Munair wrote:It shouldn't be an implicit conversion. Simply uncouple the pointer-const relationship.
Let the user be able to define 'Const DataType Ptr' pointers if he wants (including also the 3 configurations of the 'Const' qualifier in the pointer type)!
:-(Munair wrote:Getting rid of the current illegal implicit conversions would be a great thing by the way.
But this is going to break a lot of existing codes!
-
- Posts: 564
- Joined: Sep 27, 2016 18:20
- Location: Valencia, Spain
Re: methods of accessing bytes by pointer
> FreeBASIC also allows UBYTE = &h80 without any protest
Guess you mean BYTE...
> Simply uncouple the pointer-const relationship.
Isn't it easier just don't use const?
Guess you mean BYTE...
> Simply uncouple the pointer-const relationship.
Isn't it easier just don't use const?