I didn't know that. :) That's a cool feature. I see the the Zstring page notes it, so again, good job fxm.fxm wrote: In my codes, I do not check the null Zstring pointers (pz) because their dereferencing (*pz) returns an empty (and valid) Zstring.
Extending Wstring and Zstring with UDTs
Re: Extending Wstring and Zstring with UDTs
Re: Extending Wstring and Zstring with UDTs
No, I do not see where it is noted in the documentation?
But in my opinion it is an interesting specificity that really deserves to be specified (as for example 'Deallocate(null_pointer)').
(idem for a Wstring pointer)
But in my opinion it is an interesting specificity that really deserves to be specified (as for example 'Deallocate(null_pointer)').
(idem for a Wstring pointer)
Code: Select all
Dim As Zstring Ptr pz = 0
Print "'" & *pz & "'", Len(*pz), Sizeof(*pz)
Dim As Wstring Ptr pw = 0
Print "'" & *pw & "'", Len(*pw), Sizeof(*pw)
Sleep
Code: Select all
'' 0 1
'' 0 2
Re: Extending Wstring and Zstring with UDTs
No, the return of a (uninitialized) ZString Ptr, is simply invalid ...
(as expected)
(as expected)
Code: Select all
' ZString_PTR_tst001.bas -- (c) 2019-07-01, MrSwiss
'
' compile: -s console -exx -w pedantic
'
Dim As ZString Ptr psz
If *psz Then Print *psz ' Aborting due to runtime error 7 (null pointer access)
Sleep
Re: Extending Wstring and Zstring with UDTs
Yes you are right. That aborts.
That's the only thing I had not tried! ...
Because to test strings, I never write it in this form, but rather like this:which works
I also think that 'If *psz Then ...' should always induce a compilation error (so whatever the 'psz' pointer value), as this does for any string (empty or not) without dereferencing:C:\...\FBIDETEMP.bas(4) error 24: Invalid data types, found 'Then' in 'If z Then Print z'
C:\...\FBIDETEMP.bas(5) error 24: Invalid data types, found 'Then' in 'If s Then Print s'
@coderJeff,
What is your opinion, and should I rather (as I think) fill in a bug report?
That's the only thing I had not tried! ...
Because to test strings, I never write it in this form, but rather like this:
Code: Select all
Dim As ZString Ptr psz = @""
If ( *psz <> "" ) Then Print *psz
'or
If Len( *psz ) Then Print *psz
Sleep
I also think that 'If *psz Then ...' should always induce a compilation error (so whatever the 'psz' pointer value), as this does for any string (empty or not) without dereferencing:
Code: Select all
Dim As Zstring * 1 z
Dim As String s
If z Then Print z
If s Then Print s
Sleep
C:\...\FBIDETEMP.bas(5) error 24: Invalid data types, found 'Then' in 'If s Then Print s'
@coderJeff,
What is your opinion, and should I rather (as I think) fill in a bug report?
Last edited by fxm on Jul 01, 2019 13:53, edited 1 time in total.
Re: Extending Wstring and Zstring with UDTs
I don't either. lol, I must be losing my mind. Not sure what I read, but made sense to me at the time. Maybe I was celebrating a little too heavily this Canada Day weekend...fxm wrote:No, I do not see where it is noted in the documentation?
Re: Extending Wstring and Zstring with UDTs
It seems like the feature is mostly OK. You've only just pointed it out to me, so can't really say what the desired behaviour is with certainty.fxm wrote:@coderJeff,
What is your opinion, and should I rather (as I think) fill in a bug report?
Overall, it's the fbc runtime library that understands that *cptr(zstring ptr, 0) should be regarded as a null string. fbc (compiler) ultimately is passing around a null pointer under the hood, so no actual deref is ever done.
Code: Select all
dim z as zstring ptr = 0
dim s as string = "Hello"
print s '' s = "Hello"
s = *z :print s '' s = ""
s = "A" & *z :print s '' s = "A"
s = *z & "B" :print s '' s = "B"
s = z[0] :print s '' s = ""
s = z[1] '' run time segfault, no null ptr check here
print s '' s = ???
- z[n] is just alternative for *(z+n), and I don't see how we could do null pointer check on the pointer math
- where we are actually looking for a deref value, as in "if *psz then ..." I think we should expect the null pointer check there.
- I think "if *psz then ..." also valid, due the dual nature of zstrings. See https://github.com/freebasic/fbc/issues/111 which I also answered in https://freebasic.net/forum/viewtopic.p ... 85#p254085
Re: Extending Wstring and Zstring with UDTs
Why a bug report? The test is valid, as written ...
(TRUE if there is "something", FALSE on "uninitialized")
(rather: initialized to "nothing", a IMO unsuitable testing-method)
(TRUE if there is "something", FALSE on "uninitialized")
Which means that you never really test "uninitialized".fxm wrote:Because to test strings, I never write it in this form, but rather like this:
(rather: initialized to "nothing", a IMO unsuitable testing-method)
Re: Extending Wstring and Zstring with UDTs
Have you both read my post carefully?
My last questioning is more general and concerns the parser (so regardless of any pointer value) which rejects lines 7, 8, 11 but not line 10 (same for a Wstring):
My last questioning is more general and concerns the parser (so regardless of any pointer value) which rejects lines 7, 8, 11 but not line 10 (same for a Wstring):
Code: Select all
Dim As Zstring * 10 z = "FreeBASIC"
Dim As Zstring Ptr pz = @z
Dim As String s = "FreeBASIC"
Dim As String Ptr ps = @s
If z Then Print z '' error 24: Invalid data types
If s Then Print s '' error 24: Invalid data types
If *pz Then Print z '' works
If *ps Then Print s '' error 24: Invalid data types
- (example above with non null pointers)
Re: Extending Wstring and Zstring with UDTs
Typical of you: going off, at a tangent (not sticking to the point at issue).
Repeat: ZString Ptr (uninitialized).
Repeat: ZString Ptr (uninitialized).
Re: Extending Wstring and Zstring with UDTs
I do not go to the tangent.
I take into account the problem more completely than you and in the logical order:
- What happens at the parsing step?
- What happens at the code compilation step?
- What happens at the execution step?
I take into account the problem more completely than you and in the logical order:
- What happens at the parsing step?
- What happens at the code compilation step?
- What happens at the execution step?
Re: Extending Wstring and Zstring with UDTs
You are perfectly free, to do as you please ... look it up, in the sources.
Re: Extending Wstring and Zstring with UDTs
My feeling is that 'If any_string Then ...' should always be refused at the compilation step, and there should not be any exceptions like currently for the Zstring/Wstring pointers dereferenced.
Last edited by fxm on Jul 01, 2019 16:14, edited 1 time in total.
Re: Extending Wstring and Zstring with UDTs
I don't think that is what this is about. zstring ptr is initialized, to zero (0), and has some behaviours not well documented. Uninitialized would be dim pz as zstring ptr = any.MrSwiss wrote:Repeat: ZString Ptr (uninitialized).
It's been helpful that fxm, very consistently, brings the perspective of a skilled and and knowledgeable user to the community. I think we have made a pretty good team over last couple years to solve some compiler issues. fxm providing the user point of view, and myself providing the developer point of view.
Re: Extending Wstring and Zstring with UDTs
fxm wrote:My feeling is that 'If any_string Then ...' should always be refused at the compilation step, and there should not be any exceptions like currently for the Zstring/Wstring pointers dereferenced.
Re: Extending Wstring and Zstring with UDTs
I have, I think. As I mentioned, zstring ptr can behave like a string or like an array of bytes depending on usage and context.fxm wrote:Have you both read my post carefully?
Code: Select all
Dim As Zstring * 10 z = "FreeBASIC"
Dim As Zstring Ptr pz = @z
Dim As String s = "FreeBASIC"
Dim As String Ptr ps = @s
print z '' print the string
print pz '' print the address
print *pz '' print the string
print s '' print the string
print ps '' print the address
print *ps '' print the string
Code: Select all
Dim As Zstring * 10 z = "FreeBASIC"
Dim As Zstring Ptr pz = @z
scope
'' OK - (zstring*n)[index]
dim b0 as byte = z[0]
dim b1 as byte = z[1]
print b0, b1 '' 70, 114
end scope
scope
'' OK - (zstring ptr)[index]
dim b0 as byte = pz[0]
dim b1 as byte = pz[1]
print b0, b1 '' 70, 114
end scope
scope
'' OK - implicit cbyte(*(zstring ptr + offset))
dim b0 as byte = *pz
dim b1 as byte = *(pz+1)
print b0, b1 '' 70, 114
end scope
In the case of if ([fixed]string) then there is no implicit cast, or conversion applied to get an integer expression to check on the conditional.
Same for any conditional with do, while, etc, or even passing *(zstring ptr) to a procedure parameter accepting an integer type.
So, I don't think of it as a bug. A zstring ptr has many similar properties to the char * type in C.