I need to understand the mechanisms here
If I have queue with one string field
Q1 queue
f string(255)
end
!i can do
Q1=Clip(SomeVariable)
now, today I found that a similar work using a queue with a cstring
Q1 Queue
f cstring(255)
end
Q1 = clip(SomeVariable)
Then the LEN(Q1.F)=255
So, it looks to me that if I assign a value, it only assign that part of memory for the queue, it doesnt actually touch the field. The result in my case was that quite often, when I saved this to a file, I got a few extra characters with complete rubbish at the end of each record, and each line being larger than the actual size of line. The assignment part I get, but how can I write larger part to file than what can be held in the cstring? And why doesnât it happen every time?
I changed to assign to the cstring directly, so problem solved, but questing remains.
Maybe you are assigning so much data that it doesnât have a place left to add the null terminator?
Youâre writing to the entire queue buffer, and not to the field. The queue buffer is a treated as a string. So there is no automatic type conversion to a CSTRING - where a null terminator would be added.
This should work as desired:
Q1.F = clip(SomeVariable)
5 Likes
In my defense, I didnât have my morning caffeine yet 
poke is still supported to. âŚ
Thank you for confirming that the queue buffer works as a string.
I have cstring with /0 in first position.
I end up with cstring without /0 and then the cstring is filled with whatever rubbish not cleared.
Now for the second and third part of my problem: Why doesnât it do that every time and how is it possible to assign more than the limit of characters from the cstring?
See this picture.
The actual variable is defined as cstring(1001).
When assigning to file, I first obtain a reference to the field in the queue passed
Ref &=What(pQ,I) !Get a reference
I append an optional separator, in this case another blank cstring.
Linefeed is added by the ascii driver.
I can happily understand that the entire 1001 characters being assigned, given it has no /0, that makes sense, but where can the rubbish after the string on the image come from?
Can a reference variable points to memory outside the cstrings definition?
My understanding is that a cstring can be thought of as the address of the first character and then a stream of bytes that is terminated when you encounter a null. That said Clarion CSTRINGs have a SIZE() and somewhere hidden from our view the assignment logic should ensure that we donât overflow the SIZE()
For a normal assignment, If your buffer is larger than what you are setting then anything after the null remains unchanged. Thatâs what many people refer to as leaving random values. Or ârubbishâ as you called it. Thatâs also why those bytes feel inconsistent to you.
If you read the documentation for CLEAR youâll see it says âCSTRING variables are set to zero lengthâ which means to me that it just sets the first byte to â<0>â and doesnât care whatâs in the remaining bytes
You could test to see if this assignment alters values past the first â<0>â
Q.1F = CLIP(SomeVariable) & ALL( '<0>', SIZE(Q.1F) - LEN(CLIP(SomeVariable) )
or clarion should prevent overflow so you could write
Q.1F = CLIP(SomeVariable) & ALL('<0>',SIZE(Q.1F))
If those donât alter values past the first null, you might try
Q.1F = ALL('<32>',SIZE(Q.1F))
Q.1F = CLIP(SomeVariable)
1 Like
I undestand that within the limit of size(variable), I could have stuff after the /0. I have done string slizing errors enough to experience that. But my strange characters comes after the maximum size of the cstring, as if sometimes we read futher. If a read on a cstring means that it goes on until it find a /0, then in this case it goes beyond the size, to whatever is in memory at location 1001+X.
Still doesnât make sense that it is unpredicable, should have happended each time. Always the same characters though.
