Extending Wstring and Zstring with UDTs

For other topics related to the FreeBASIC project or its community.
coderJeff
Site Admin
Posts: 3135
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: Extending Wstring and Zstring with UDTs

Postby coderJeff » Jun 30, 2019 21:45

fxm wrote: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
Posts: 9310
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Extending Wstring and Zstring with UDTs

Postby fxm » Jul 01, 2019 5:06

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
Posts: 3307
Joined: Jun 02, 2013 9:27
Location: Switzerland

Re: Extending Wstring and Zstring with UDTs

Postby MrSwiss » Jul 01, 2019 12:19

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
Posts: 9310
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Extending Wstring and Zstring with UDTs

Postby fxm » Jul 01, 2019 13:51

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?
Last edited by fxm on Jul 01, 2019 13:53, edited 1 time in total.
coderJeff
Site Admin
Posts: 3135
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: Extending Wstring and Zstring with UDTs

Postby coderJeff » Jul 01, 2019 13:52

fxm wrote: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
Site Admin
Posts: 3135
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: Extending Wstring and Zstring with UDTs

Postby coderJeff » Jul 01, 2019 14:07

fxm wrote:@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
Posts: 3307
Joined: Jun 02, 2013 9:27
Location: Switzerland

Re: Extending Wstring and Zstring with UDTs

Postby MrSwiss » Jul 01, 2019 14:09

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

fxm wrote: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
Posts: 9310
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Extending Wstring and Zstring with UDTs

Postby fxm » Jul 01, 2019 14:45

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
Posts: 3307
Joined: Jun 02, 2013 9:27
Location: Switzerland

Re: Extending Wstring and Zstring with UDTs

Postby MrSwiss » Jul 01, 2019 15:02

Typical of you: going off, at a tangent (not sticking to the point at issue).
Repeat: ZString Ptr (uninitialized).
fxm
Posts: 9310
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Extending Wstring and Zstring with UDTs

Postby fxm » Jul 01, 2019 15:34

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
Posts: 3307
Joined: Jun 02, 2013 9:27
Location: Switzerland

Re: Extending Wstring and Zstring with UDTs

Postby MrSwiss » Jul 01, 2019 15:40

You are perfectly free, to do as you please ... look it up, in the sources.
fxm
Posts: 9310
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Extending Wstring and Zstring with UDTs

Postby fxm » Jul 01, 2019 16:12

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.
coderJeff
Site Admin
Posts: 3135
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: Extending Wstring and Zstring with UDTs

Postby coderJeff » Jul 01, 2019 16:13

MrSwiss wrote: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
Posts: 9310
Joined: Apr 22, 2009 12:46
Location: Paris suburbs, FRANCE

Re: Extending Wstring and Zstring with UDTs

Postby fxm » Jul 01, 2019 16:19

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.
coderJeff
Site Admin
Posts: 3135
Joined: Nov 04, 2005 14:23
Location: Ontario, Canada
Contact:

Re: Extending Wstring and Zstring with UDTs

Postby coderJeff » Jul 01, 2019 16:32

fxm wrote: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.

Return to “Community Discussion”

Who is online

Users browsing this forum: No registered users and 1 guest