Extending Wstring and Zstring with UDTs

[coderJeff]

In my codes, I do not check the null Zstring pointers (pz) because their dereferencing (*pz) returns an empty (and valid) Zstring.

I didn't know that. :) That's a cool feature. I see the the Zstring page notes it, so again, good job fxm.

[fxm]

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)

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

[MrSwiss]

No, the return of a (uninitialized) ZString Ptr, is simply invalid ...
(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

[fxm]

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:

Code: Select all

Dim As ZString Ptr  psz = @""

If ( *psz <> "" ) Then Print *psz
'or
If Len( *psz ) Then Print *psz

Sleep

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:

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(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?

[coderJeff]

No, I do not see where it is noted in the documentation?

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...

[coderJeff]

@coderJeff,
What is your opinion, and should I rather (as I think) fill in a bug report?

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.

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 = ???

At the moment, not thinking it's a bug.
- 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

[MrSwiss]

Why a bug report? The test is valid, as written ...
(TRUE if there is "something", FALSE on "uninitialized")

Because to test strings, I never write it in this form, but rather like this:

Which means that you never really test "uninitialized".
(rather: initialized to "nothing", a IMO unsuitable testing-method)

[fxm]

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):

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)

[MrSwiss]

Typical of you: going off, at a tangent (not sticking to the point at issue).
Repeat: ZString Ptr (uninitialized).

[fxm]

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?

[MrSwiss]

You are perfectly free, to do as you please ... look it up, in the sources.

[fxm]

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.

[coderJeff]

Repeat: ZString Ptr (uninitialized).

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.

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.

[fxm]

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.

[coderJeff]

Have you both read my post carefully?

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.

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

So, in this example, in the last scope block, shows what is happening with if *(zstring ptr) then:

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

if statement expects an integer expression, and when *(zstring ptr) is cast as integer, gets the character (byte) value, at the index.

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.