not initialized string should point to ""-constant

[PMV]

As part of the current threads (german forum and here) and because non
of them has requested it jet.

original idea by Nic The Quick: http://www.purebasic.fr/german/viewtopi ... 9&start=20
free translation by me

PureBasic handles null-strings as special cases. But if you are using the pointer
of such a string, you will get a null-pointer-error. Of course, you need to
handle this behavior as a special case, too. Because PureBasic handles a
null-string as an empty string in any other cases, it is much better, that there
are no null-strings. Of course, it would be really bad if PB would allocate
memory for the null-byte for every new string. But why can't it point to a
null-character-constant? If PB would create a null-character-constant and would
point every not initialized string to it, then no string-pointer would return NULL
and still it is not needed to allocate memory for not initialized strings. It could
be, that it is only needed to change the special case value from "null" to
"null-character-constant-pointer", if you understand what i mean

MFG PMV

[Trond]

When assigning a new string, the string manager frees the previous string. Freeing the empty string is a bad idea if everyone points to it.

Code: Select all

Define Empty1.s, Empty2.s, Empty3.s

Empty1 = "Hello" ; String manager inadvertently frees the constant string
Empty3 = Empty2 ; INVALID MEMORY ACCESS

There will be an invalid memory access on the last line, first when trying to read from Empty2 (which was freed when assigning to Empty1), then when trying to free the old string pointed to by Empty3 (which is also the same string that was freed when assigning to Empty1).

Also, each string variable cannot be given a unique empty string because PB allows endlessly recursive procedures:

Code: Select all

Procedure Recursive(I)
  Protected Local.s ; Where does this point after
  If I > 0
    Recursive(I - 1) ; this?
  EndIf
EndProcedure

To make this work requires constant strings to be "special" in some way, which is indeed possible, but it requires redesigning the whole string library and making PB strings more incompatible with C strings.

[TomS]

I'm yet to see an example where the current behaviour of PB causes trouble for the programmer.

I already requested one, and all I got as an answer was "you don't understand the problem".
I think that you (meaning everyone who is complaining all the time) don't understand, that this is PB and you can't expect to find the same behaviour as in whatever language you used before.

[PMV]

When assigning a new string, the string manager frees the previous string. Freeing the empty string is a bad idea if everyone points to it.

Not initialized string has a pointer of zero! There is nothing to be freed. That is the problem.

Code: Select all

Define NullString.s
Debug @NullString ;pointer is null!
Debug Chr(34) + NullString + Chr(34) ; but string-operations are the same as empty strings
Define EmptyString.s=""
Debug @EmtyString ;pointer is not null
Debug Chr(34) + EmptyString + Chr(34) ; normal string-operation as expected

I want to elemniate the NullString. I doesn't want to change the handling
of empty strings. I want, that empty strings are always used as empty
strings. Regardless it is not initialized by the programmer. That is the same
behavior like any other datatyp of purebasic. It is never needed to initialize
a variable because PB initializes any variable with zero, if the programmer
doesn't do it. Strings are not needed to be initialized, too. Like in the code
above. Null-strings are handled like empty-strings. But only As long as you
doesn't use the pointer from it, because it is really null.

null-pointers -> IMA -> the worst case for any programmer
That is not an easygoing problem, because IMAs can have many reasons and
this reason is not documented. And i doesn't want it to be documented,
because where should it be written? The clean-way is to not let it happen.
And i hope i have (translated) a good and easy solution for fred/ freak to
implement it when they can.

Code: Select all

Define Empty1.s, Empty2.s, Empty3.s

Empty1 = "Hello" ; String manager inadvertently frees the constant string
Empty3 = Empty2 ; INVALID MEMORY ACCESS

There will be an invalid memory access on the last line, first when trying to read from Empty2 (which was freed when assigning to Empty1), then when trying to free the old string pointed to by Empty3 (which is also the same string that was freed when assigning to Empty1).

Nope ... there is no error because PB is already handling not initialized
Strings as a special case. Otherwise you would get an IMA on the that line,
because you assign a null-string (not empty) to another null-string.

[skywalk]

I'm yet to see an example where the current behaviour of PB causes trouble for the programmer.

I already requested one, and all I got as an answer was "you don't understand the problem".
I think that you (meaning everyone who is complaining all the time) don't understand, that this is PB and you can't expect to find the same behaviour as in whatever language you used before.

This comes up in different topics like here.
http://www.purebasic.fr/english/viewtop ... 18#p353118
I didn't realize String Variables are not initialized even though they are defined.
Meaning:

Code: Select all

Define.s X      ; <-- X variable cannot be pointed at or referenced in a Procedure
Define.s Y=""   ; <-- Y variable safe to point at

Of course, normal String use works.
Trond and PMV explain it better.

[freak]

I don't see a reason why this needs to be changed. It is working just fine.

Strings are always initially contain an empty string (as far as string functions are concerned). This is the same as any other PB type. How that empty string is represented internally is a different story. Its called lazy initialization: The string is created when something is assigned. This is a perfectly normal concept and there is nothing wrong with it.

[netmaestro]

But if you are using the pointer of such a string, you will get a null-pointer-error.

I won't, because I'm able to grasp this (remarkably simple) concept:

Code: Select all

If @neverseenbefore1$ = #Null And neverseenbefore2$ = #NULL$
  Debug "What was the question again?"
EndIf

This is a perfectly normal concept and there is nothing wrong with it.

Right, imho. Any changes would not bring an improvement.

[skywalk]

Ahem...My questions were on the behavior of an uninitialized defined string.
The manual does not explain this in depth, and for sure I will not be using netmaestro's suggested double checking for nulls( though funny ), when the solution is:

Code: Select all

Define.s X = ""; Ok to point or reference X in Procedures

I just thought the Compiler would do this for me instead of:

Code: Select all

Define.s X     ; lazy initialized, null pointer to X fails in Procedures

[Trond]

When assigning a new string, the string manager frees the previous string. Freeing the empty string is a bad idea if everyone points to it.

Not initialized string has a pointer of zero! There is nothing to be freed. That is the problem.

I know how it currently is. I was just describing how things would break with this change.

[TomS]

Code: Select all

Define.s X = ""; Ok to point or reference X in Procedures

I just thought the Compiler would do this for me instead of:

Code: Select all

Define.s X     ; lazy initialized, null pointer to X fails in Procedures

Nope. When you assign a string (albeit empty), the pointer now has an address.

I think everyone who is peeking and poking recklessly without confirming that the address and size are valid and is then screaming that this is a bug, is ihmo not as experienced as they all claim in the german board...

[PMV]

But if you are using the pointer of such a string, you will get a null-pointer-error.

I won't, because I'm able to grasp this (remarkably simple) concept:

Code: Select all

If @neverseenbefore1$ = #Null And neverseenbefore2$ = #NULL$
  Debug "What was the question again?"
EndIf

Why do we make feature requests or want to eliminate bugs when
there are workarounds?
It is always an improvement, when there is less source of errors.

This is a perfectly normal concept and there is nothing wrong with it.

Your opinion. But sure, this would only be a "small" improvement for the
whole language. And of course, i know it now ... so i can initialize a string if it
is needed and i will not be confused about a null-pointer-string, if i get it in the
future.

I think everyone who is peeking and poking recklessly without confirming that the address and size are valid and is then screaming that this is a bug, is ihmo not as experienced as they all claim in the german board...

That is another story and has nothing to do with this topic.

MFG PMV

[TomS]

Sure it does.
If you don't peek, there's no problem (string operations work with empty strings and null-pointer-strings)
If you confirm that the address is not 0 (which you should always do) than there's no problem.

I agree with your request more than with the other one in the german board, where

Code: Select all

Define n.s
Debug "Hello, "+n

should cause a compiler warning in line 2

But if it's true what Trond is saying, the compiler has to be more selective about freeing memory and that probably requires rewriting (not so small) parts of the string management.
So confirming that the pointer is not pointing to 0, like you do with all other memory management issues, is the way to go here.

[PMV]

I agree with your request more than with the other one in the german board, where

Code: Select all

Define n.s
Debug "Hello, "+n

should cause a compiler warning in line 2

No. I thought someone would not understand my bad english.

I request only this:

Code: Select all

;on empty string is defined somewhere in the executable
DataSection
  EmptyString:
  Data.s ""
EndDataSection
; ----

; now we define new strings
Define.s MyString         ;not initilalized, points to ?EmptyString, not to zero
Define.s MyString2.s =""  ;initialized like is is now
; -----

Debug @MyString     ;should point to ?EmptyString
Debug ?EmptyString  ;pointer for any not initialized string 
Debug @MyString2    ;should point to the initialized string for MyString2

Debug MyString        ;should return the empty string in the DataSection
MyString2 + MyString  ; MyString2 gets the empty string from MyString, so nothing special
Debug MyString2       ;still a empty string
MyString = "blabla"   ;now the string will be initialized as it is now, nothing is freed, only the memory is created for the new string "blabla" because MyString had pointet to ?EmptyString
Debug MyString        ;it is now a normal string with his own memory-block

So confirming that the pointer is not pointing to 0, like you do with all other memory management issues, is the way to go here.

I hope it is not, but if it is ... i can't change it. I only request, if freak/ fred
say no i can not change it as well.

And btw. i doesn't use PokeS() for strings that are managed by PB.
I always use String-Structures. *s.STRING and *s\s = "blabla" in
procedures for ByRef-parameters. I doesn't have used a not
initialized string yet, but if i would ... it would be much better
if i doesn't need to check for zero-pointers.

MFG PMV

[TomS]

I understand you perfectly. Dr Shrek and X0r were the ones.

So this is what X0r is proposing:
A string variable that has no value yet (Define var.s) must not be handled in the same way as a string variable that contains an empty string (Define var.s = ""). This code demonstrates as it should be in their opinion:

Code: Select all

Define var.s
MessageRequester("Title", var) ;Compiler Warning, Programm crashes, "Would you like to send an error report to microsoft?"...

;Only this would be valid 
Define var.s
If @var <> 0
    MessageRequester("Title", var)
Else
    MessageRequester("Title", "")
Endif

This is what DrShrek wanted from the beginning. When you come from languages that are closer to machine language (Dr Shrek definitely ded) you'll find this kind ob behaviour quite dodgy.

Obviously your feature request is exactly the opposite.
String operations with truly empty Strings (currently pointing to 0) should still work in the future, but so should operations in the memory. That's why defined Strings should not point to 0 but to any other constant area in memory.

Finding the request of DrShrek and X0r completely rubbish, I'm more sympathetic to your request.
However, if it's true what Trond is saying, your request can not be realized so easily and may require deeper changes to the compiler functions that currently handle string memory.

But in my opinion it's not asked too much from the programmer to check whether the pointer points to a valid address or to zero as you should always double check before you do fancy memory operations.

[PMV]

but for completion i want to repeat, this idea is from Nic The Quick