E1.20 RDM (Remote Device Management) Protocol Forums

E1.20 RDM (Remote Device Management) Protocol Forums (http://www.rdmprotocol.org/forums/index.php)
-   RDM General Implementation Discussion (http://www.rdmprotocol.org/forums/forumdisplay.php?f=4)
-   -   Non-ASCII Characters (http://www.rdmprotocol.org/forums/showthread.php?t=1230)

ericthegeek June 3rd, 2015 07:09 PM

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?

hamish June 4th, 2015 01:52 AM

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.

zano_villa July 22nd, 2016 03:15 AM

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

hamish July 22nd, 2016 03:56 AM

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.

zano_villa July 22nd, 2016 05:59 AM

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

hamish July 22nd, 2016 09:29 AM

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.

ericthegeek July 22nd, 2016 10:26 AM

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.

hamish July 22nd, 2016 10:51 AM

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.

sblair July 22nd, 2016 12:35 PM

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.

sblair July 22nd, 2016 12:37 PM

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.

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.

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.


All times are GMT -6. The time now is 01:00 PM.

Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2024, vBulletin Solutions, Inc.