Freebasic 1.20.0 Development

[coderJeff]

@Jeff,

- internal: types containing only STRING*N fields or child types containing only STRING*N fields will initialize to spaces using a memory fill operation, and where other data types are present will induce the creation of an implicit constructor

Maybe simpler to always create at least one implicit constructor whenever a STRING*N field exists ?
(this is the only case of data type where one must fill the byte field with 32 and not 0 like all others)

Yes, you are correct that it will be simpler. I was trying to do 2 things: first was to optimize the initialization, and second to allow scoped types.

For example:

Code: Select all

scope
	type T1
		s as string * 123
	end type

	type T2
		s as string
	end type
	'' error 263: Objects with default [con|de]structors or 
	'' methods are only allowed in the module level in 'end type'
end scope

[coderJeff]

@Jeff,

limit WSTRING*N, ZSTRING*N, STRING*N types to 2^31-1 and show an 'invalid size' error if the size given is less than 1 or greater than the limit

Could you confirm the theoretical limits for a var-len string:
between 0, and 2^31-1 (for 32-bit) or 2^63-1 (for 64-bit) ?

For var-len STRING:

theoretical maximum SIZE, including the implicit null terminating character
32-bit size: >= 0 and <= 2^31-1
64-bit size: >= 0 and <= 2^63-1

therefore theoretical maximum LENGTH, not including the null terminating character
32-bit length: >= 0 and <= 2^31-2
64-bit length: >= 0 and <= 2^63-2

Practical limits will be less. For example, where string is allocated / reallocated where SIZE is requested but SIZE+SIZE*12.5%+1 is actually allocated.

[coderJeff]

Added :
I understand main question is : can string*N returns less than N characters or shall it return always N characters ?
One hand string*N is seen as a "memory slot facilities", versus other hand a "new datatype".
I must admit answer is difficult.

I had it in my mind that new behaviour will be to always return N characters, regardless if the variable / field is padded with spaces or zeros.

Added :
I just realised user maybe can set String*N adding a chr(0) or not while setting, in wich case he/she assume the zstring compliancy or not depending on his/her requirements (in wich case zstring direct access possibility could be a feature).

Yes, user would be responsible for adding chr(0) to allow for zstring compatibility.

Is there any basic variant that supports fixed-length strings, initializes fields to all zero, and pads with spaces on assignment?

So we would have,

Code: Select all

type T1: f as string*10 = any: end type  '' uninitialized
type T2: f as string*10      : end type  '' initialize to string(10,0)
type T3: f as string*10 = "" : end type  '' initialize to space(10)
[code]
After that assignments always pad with spaces.

[fxm]

So we would have,

Code: Select all

type T1: f as string*10 = any: end type  '' uninitialized
type T2: f as string*10      : end type  '' initialize to string(10,0)
type T3: f as string*10 = "" : end type  '' initialize to space(10)

After that assignments always pad with spaces.

I would like that.
This way, only the last syntax requires an implicit constructor.

On the other hand, dynamic arrays could never be pre-filled with spaces

[coderJeff]

Sorry for stepping in--

When try to compile below examples,the recent fbc64.exe version 1.2.0 crashed during compiling under windows 10 64bit,but fbc64 version 1.1 is fine.
https://github.com/jepalza/FB_DOOM_LIKE

I have no idea what happed,so just report here.

Cause is related to bug #798 fbc's recursive AST storage & traversal breaks with huge initializers

And in the doom like source code (textures) we have:

Code: Select all

'' array size is 27180
Dim Shared As Byte T_NUMBERS(...)  = { _
  0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, _

The change could have been from *any* work done on fbc compiler. Because initializer list is solved through recursion, a change to any of fbc's internal procedures used by initializer handling can affect how much stack space is used and therefore affect how many calls are possible before the stack is ultimately exhausted and crashes fbc, thus the current limiting factor on length of initializer lists.

By the way,I am really wondering,wehere the language has decided that it will NOT add semantic macro system or even generics(template stuffs)?

This sounds like a variant of a "Will freebasic ever have feature X?" kind of question. So, I have no answer.

[coderJeff]

Compatibility between old/new STRING*N (apart from remaining bugs)

I will keep pushing forward to solve the bugs you posted and continue with the idea of initializing and padding spaces.

But this is also interesting to me:

When upgrading existing codes (to also compile and run with fbc version 1.20.0), the largest number of modifications is when printing, or comparing strings to each other.
To ignore the padding spaces added at the end of any STRING*N, one must apply RTRIM() on each STRING*N variable in the expression.

It is a big job !
I started doing this on a 5000 line code that uses a lot of STRING*N arrays.
One really have to go through the code line by line (that is how I found the two bugs above), but everything is not yet operational !

Ah, so there is some code base that exists using string*(n-1) expecting zstring*n behaviour.

I am curious, do you know the original motivation for utilizing string*(n-1) over zstring*n?

[fxm]

I am curious, do you know the original motivation for utilizing string*(n-1) over zstring*n?

Very old code (in several modules) that I originally wrote in Quick Basic, and which I then easily (this time) transposed into FreeBasic.
But I think that transposing all to ZSTRING*(N+1) or STRING will be even more tedious !
In any case, continuing with always the STRING*N variables will allow me to properly debug the modifications made to these fix-len strings.
I will wait for these bugs to be fixed before continuing.

[PeterHu]

Are you sure of the working version ? with Version 1.10.1 (2023-12-24), I get the crash.
Edit : also with Version 1.10.0 (2023-05-14),

Sorry,no,all 64 bit fbc v1.09,1.10,1.2.0 failed to compile,only 32bit version works.
It should be a careless mistake that I forgot to change 32bit output to 64 bit output in the IDE when I do changed compiler version from 32 bit to 64bit.

[PeterHu]

This sounds like a variant of a "Will freebasic ever have feature X?" kind of question. So, I have no answer.

Well noted with thanks.

[jevans4949]

Thinking around the issue of converting existing code, I suppose that code that depends on the existing STRING*n construct would proabaly work by changing DIMs to ZSTRING*n most of the time.

[fxm]

Thinking around the issue of converting existing code, I suppose that code that depends on the existing STRING*n construct would proabaly work by changing DIMs to ZSTRING*n most of the time.

Yes, but the compatibility that exists between a STRING*N and a STRING no longer exists between a ZSTRING*N and a STRING, particularly for passing by reference:
'procedure(Byref As String)' : a passed ZSTRING*N argument is not modified, while a passed STRING*N argument is modified.

@Jeff,
Maybe a compiler warning message is missing here:
(Z|W)STRING*N argument not compatible with a BYREF AS STRING parameter, but only with a BYVAL AS STRING parameter.

[jevans4949]

Thinking around the issue of converting existing code, I suppose that code that depends on the existing STRING*n construct would proabaly work by changing DIMs to ZSTRING*n most of the time.

Yes, but the compatibility that exists between a STRING*N and a STRING no longer exists between a ZSTRING*N and a STRING, particularly for passing by reference:
'procedure(Byref As String)' : a passed ZSTRING*N argument is not modified, while a passed STRING*N argument is modified.

@Jeff,
Maybe a compiler warning message is missing here:
(Z|W)STRING*N argument not compatible with a BYREF AS STRING parameter, but only with a BYVAL AS STRING parameter.

... which maybe makes a case for the "new" STRING*n being given a different name, as I suggested when I first commented on this issue.

[fxm]

... which maybe makes a case for the "new" STRING*n being given a different name, as I suggested when I first commented on this issue.

I will be able to give my opinion when I have been able to update my code of 5000 lines which uses a lot of STRING*N (simple variables and arrays) with files I/O and prints + graphic drawings.
I will come back to this code when bugs #1 and #2 are fixed.

[coderJeff]

Maybe a compiler warning message is missing here:
(Z|W)STRING*N argument not compatible with a BYREF AS STRING parameter, but only with a BYVAL AS STRING parameter.

... which maybe makes a case for the "new" STRING*n being given a different name, as I suggested when I first commented on this issue.

zstring*n and wstring*n arguments could be made compatible with 'byref as string' parameters, but it's currently disabled in the compiler.

I see dkl has considered these behaviours before as well: Copy back for z/wstrings can't be done safely

But, that comment from dkl is only half correct.
zstring*n / wstring*n arguments passed to a byref as string parameter could be copied back safely, because the length is known.
dereferenced string pointer type arguments passed to a byref as string parameter can't be copied back safely, because the length is unknown.

[coderJeff]

I will come back to this code when bugs #1 and #2 are fixed.

I have fixes for bug #1 and #2 which I should be able to push out today.

I started to explore enabling copyback for string*n and zstring*n passed to byref as string. And got side tracked by already existing and unsafe combinations of implicit string conversions that current and older fbc versions allow but can easily lead to a program crash, overwriting past the end of allocated buffers. So I'd like to get an understanding of some issues there before pushing next changes.

For example, just by brute force trying every combination that fbc allows (perhaps as a novice programmer would try), can induce a crash with this:

Code: Select all

sub proc( byref s as wstring )
	s = "byref as wstring" '' crash, assignment is longer than temporary
end sub

dim s as string = "value"
proc( s ) '' creates temporary wstring 6 wchars long, incl. zero terminator

But if we ensure that our starting buffer is large enough to handle the assignment, here's the expected changes for VARIABLES if string*n and zstring*n and wstring*n passed to byref as string is allowed to be modified:

Code: Select all

dim s as string
dim f as string * 20
dim z as zstring * 20
dim w as wstring * 20

#macro reset_values
	s = "no copyback"
	f = "no copyback"
	z = "no copyback"
	w = "no copyback"
#endmacro

sub p1( byref s as string )
	s = "copyback   "
end sub

reset_values
''                    fbc-1.10.1    fbc-1.20.0
p1( s ): print s   '' copyback      copyback  
p1( f ): print f   '' copyback      copyback
p1( z ): print z   '' no copyback   copyback  <<<<
p1( w ): print w   '' no copyback   copyback  <<<<
print

sub p2( byref s as zstring )
	s = "copyback   "
end sub

reset_values
''                    fbc-1.10.1    fbc-1.20.0
p2( s ): print s   '' copyback      copyback
p2( f ): print f   '' copyback      copyback
p2( z ): print z   '' copyback      copyback
p2( w ): print w   '' no copyback   no copyback
print

sub p3( byref s as wstring )
	s = "copyback   "
end sub

reset_values
''                    fbc-1.10.1    fbc-1.20.0
p3( s ): print s   '' no copyback   no copyback
p3( f ): print f   '' no copyback   no copyback
p3( z ): print z   '' no copyback   no copyback          
p3( w ): print w   '' copyback      copyback
print