|
RDM General Implementation Discussion General Discussion and questions relating to implementing RDM in a product. |
|
Thread Tools | Search this Thread | Display Modes |
|
June 3rd, 2015 | #1 |
Task Group Member
Join Date: Aug 2008
Posts: 379
|
Non-ASCII Characters
When a responder is sent a string (for example DEVICE_LABEL) that contains a non-ASCII or non-printable character what should it do?
I can see several possible approaches: NACK it, accept it as is, filter out the non-printable characters. Any thoughts on the best approach? |
June 4th, 2015 | #2 |
Member
|
My thoughts are more practical than conformal. Technically, I would suggest that it should respond with DATA_OUT_OF_RANGE. Having said, null character terminators are prevalent, and IMO, as a matter of practicality, should be handled as a special case.
In the case that a responder accepts 8 bit characters, then it then becomes non conformant, as it may either modify the data or return the same out of range data. Null values apart, modifying the data is least desirable. NACK the most conformant, accepting as it, the most practical.
__________________
______________________________________________ Hamish Dumbreck |
July 22nd, 2016 | #3 |
Junior Member
Join Date: Jan 2014
Location: Treviso, Italy
Posts: 13
|
Hello, just a simple question about Text fields use.
In CURVE_DESCRIPTION pid and similar ones, can I send a string with always 32 characters and a NULL as a terminator instead of using the actual number of string characters in PDL? Thank you |
July 22nd, 2016 | #4 |
Member
|
A NULL is a character, so 32 + a NULL is not allowed in any situation.
One on the problems created by using a NULL, is that on sending 32 characters, your NULL will be lost which then generates inconsistency. The correct answer is to send the correct string length, without any null termination.
__________________
______________________________________________ Hamish Dumbreck |
July 22nd, 2016 | #5 |
Junior Member
Join Date: Jan 2014
Location: Treviso, Italy
Posts: 13
|
Thank you for quick answer but I suppose I was not clear in my question, so I will report an example:
let's say that I want send the string "QUADRATIC" which has 9 characters. I can send a message with the string "QUADRATIC" and PDL = 9 and it would be certainly ok. Or I could send a message with the string "QUADRATIC",<0x00>,"abcdefghijklmnopqrstuv" and PDL = 32. What about this second choice (see 10.1 of standard)? Thank you |
July 22nd, 2016 | #6 |
Member
|
Corresponding to the Parameter Data Length
Section 10.1 states:
The Parameter Data Length shall accordingly be set to match the actual size of the text string being sent. The statement covering what shall be done in the case that a NULL is encountered, as I often see, does not qualify the use of NULL characters as appropriate. In my responder implimentations, I use null values to determine stored string length when shorter than 32, however, there is no need to return more characters that are available before the first NULL.
__________________
______________________________________________ Hamish Dumbreck |
July 22nd, 2016 | #7 |
Task Group Member
Join Date: Aug 2008
Posts: 379
|
Yes, null termination of strings is allowed.
10.1 says: Text fields shall terminate based on Parameter Data Length, however if a NULL is encountered then that shall also act as a terminator for the text field. So, in your "QUADRATIC",<0x00>,"abcdefghijklmnopqrstuv" example, the receiver should display "QUADRATIC" properly. Personally, I don't like null termination, I think length termination is more in keeping with the spirit of RDM. But given the number of C programmers in the world that are more comfortable with null termination, there's nothing wrong with using it. |
July 22nd, 2016 | #8 |
Member
|
Not sure I'm quite on the same page, the standard, as it is written, may not be entierly expicit.
If as is suggested, null termination is generally acceptable, then I would expect the relevant text to read something akin to Text fields shall either terminate based on Parameter Data Length or when a NULL is encountered. IMO The standard states that string lengths shall be PDL determined, this being the correct approach. It then ads a caveat with the statement however, determining the appropriate treatment, in the case of a null character being encountered. By using PDL length determined strings, there is no doubt that the implimentation will be compliant with the standard.
__________________
______________________________________________ Hamish Dumbreck |
July 22nd, 2016 | #9 |
Administrator
|
I'd say Hamish is more correct here. There are requirements in 10.1 on both the Responder and the Controller.
This first sentence is the requirement for the Responder: <QUOTE> The Parameter Data Length shall accordingly be set to match the actual size of the text string being sent. </QUOTE> That clearly states that a Responder shall set it to the PDL. The next part here is the requirements on a Controller: <QUOTE> Parsing of the string shall be length terminated corresponding to the Parameter Data Length field. Text fields shall terminate based on Parameter Data Length, however if a NULL is encountered then that shall also act as a terminator for the text field. </QUOTE> This clearly states that the controller receiving it shall expect it to be length terminated, but if it does happen to encounter a NULL then that shall also terminate it. This is meant to be more as an exception. Many controllers may handle it fine if you always send as 32 chars and Null terminate, however I'm certain that there will be some that will handle it incorrectly.
__________________
Scott M. Blair RDM Protocol Forums Admin |
July 22nd, 2016 | #10 | ||
Administrator
|
I'd say Hamish is more correct here. There are requirements in 10.1 on both the Responder and the Controller.
This first sentence is the requirement for the Responder: Quote:
The next part here is the requirements on a Controller: Quote:
__________________
Scott M. Blair RDM Protocol Forums Admin |
||
Bookmarks |
Thread Tools | Search this Thread |
Display Modes | |
|
|