| Author |
Message |
DocJC
Joined: 16 Mar 2006
Location: Cleveland, OH
|
|
Posted: 16 March 2006, 14:44 PM Post subject: Possible bug in Chr() ?? |
|
|
Fired up my ZX-24 today, and am still learning... Tied it to an LCD driver and have the serial output working fine. Text and CLS work as expected. Positioning the cursor on Line 2, Position X is sent as: Esc P 2 X. (X=0,1,2...) Making a string and putting it in the Que work for X such that X > 0. If I position to Char Position 0 the LCD Drv doesn't locate it as it should. It does work when tied to a Basic Stamp, etc., so I believe the LCD Drv code is fine. I suspect that Chr(0) doesn't add 0 (decimal) to the string, as I expected it to. If I stuff the Que with Bytes the LCD Drv works fine. Hence I suspect Chr(0) is the issue.
'This version to Position Line 2, Char 0 Works:
'Call PutQueueByte (LCDQue, 27) '27 d
'Call PutQueueByte (LCDQue, 80) '80 d = P
'Call PutQueueByte (LCDQue, 2) 'Line 2 d
'Call PutQueueByte (LCDQue, 0) 'Char Posit 0 d
'This Works for Char position 1, 2, 3..., NOT for 0
'Const LCDL2 as String = (Chr(27) & "P" & Chr(2) & Chr(2)) 'Works, L2, Char Posit 3
'This fails for Char position 0
'Const LCDL2 as String = (Chr(27) & "P" & Chr(2) & Chr(0))
I'm new to the ZX-24 and ZBasic. Perhaps this is my mistake, but I would certainly appreciate your insight. JC |
|
| Back to top |
|
 |
mikep
Joined: 24 Sep 2005
Location: Austin, TX
|
|
Posted: 16 March 2006, 15:21 PM Post subject: |
|
|
Chr(0) appears to create a empty string instead of the expected result. I used StrType and StrAddress to figure this out.
Good job on isolating the problem. I'm sure Don will get this fixed very quickly. |
|
| Back to top |
|
|
dkinzer
Site Admin
Joined: 03 Sep 2005
Location: Portland, OR
|
|
Posted: 16 March 2006, 16:36 PM Post subject: |
|
|
This problem occurs because strings are represented in the compiler as null terminated strings. In retrospect, this method should not have been chosen since it precludes operating on strings containing a null byte.
Fixing the problem will require reworking the internal string representation - a process that needs to be done carefully and the result needs to be tested thoroughly. In the interim, you'll have to avoid creating strings at compile time that contain a null byte.
Note, particularly, that this problem exists only in the compiler. A string created at run-time that contains a null byte will work as expected. |
|
| Back to top |
|
|
DocJC
Joined: 16 Mar 2006
Location: Cleveland, OH
|
|
Posted: 16 March 2006, 17:00 PM Post subject: |
|
|
Thank you both for your prompt replies! We'll work around it for now.
JC |
|
| Back to top |
|
|
spamiam
Joined: 13 Nov 2005
|
|
Posted: 16 March 2006, 17:20 PM Post subject: |
|
|
| dkinzer wrote: | | Fixing the problem will require reworking the internal string representation - a process that needs to be done carefully and the result needs to be tested thoroughly. |
It is certainly a somewhat complicated question, and probably involves some degree of inconvenience both for the user and the operating system writer.
Don is a super expert on this, and knows all the tricks. One trick that I seem to recall is the requirement for the user to add an extra null before the real null character to indicate that it is REALLY a null character rather than a null termination. I suppose a smart compiler could add the extra null. If there is an extra unpaired null character left at the end of a series of them, then it is the null termination.
But I thought that strings had a head that described its length and so on, so it did not need a specific null termination? I guess that not all of them do.
-Tony |
|
| Back to top |
|
|
dkinzer
Site Admin
Joined: 03 Sep 2005
Location: Portland, OR
|
|
Posted: 16 March 2006, 17:37 PM Post subject: |
|
|
| Quote: | | But I thought that strings had a head that described its length and so on, so it did not need a specific null termination? I guess that not all of them do. |
The string representation in the VM comprises the length and the string's characters. However, in the compiler, constant strings are represented in the usual C/C++ way - a null terminated string. In this case, the length is not stored separately as it can be determined by examining the string's characters. That difference in representation is the root cause of the problem reported by DocJC. Note that the problem only occurs when your ZBasic code results in the creation of a string at compile-time that contains a null byte.
The solution to the problem is in the process of being implemented. |
|
| Back to top |
|
|
dkinzer
Site Admin
Joined: 03 Sep 2005
Location: Portland, OR
|
|
Posted: 16 March 2006, 22:05 PM Post subject: |
|
|
| A solution for this problem has been implemented and regression tests are underway. It was not as difficult to resolve as I had feared but the changes were nonetheless quite extensive. Consequently, it may take longer than usual to complete the testing. |
|
| Back to top |
|
|
|
