Imported from previous forum
In FAST (Version 1.1) Encoding, [0x00 0x00] = “\0” and [0x00] = Empty String. But when we decoding those values into Application Variables We have to face some difficulties because There is no difference between Null Terminated String and Empty string in programming level.
If you need NULL values for strings, you need to program that logic into your programming level, e.g. by keeping a bit map for all application variables coming from FAST and set bits to zero where you have received a NULL value via FAST and set bits to 1 to indicate that your application variable contains an actual value which is then possibly the empty string.
In FAST (Version 1.1) Encoding, [0x00 0x00] = “\0” and [0x00] = Empty
String. But when we decoding those values into Application Variables We
have to face some difficulties because There is no difference between
Null Terminated String and Empty string in programming level.
In FAST (Version 1.1) Encoding, [0x00 0x00] = “\0” and [0x00] = Empty
String. But when we decoding those values into Application Variables We
have to face some difficulties because There is no difference between
Null Terminated String and Empty string in programming level.
Some programming languages allow strings of 8 bit characters to contain any bit pattern, including a byte of all zeros. Others do not, or at least they make it difficult. One of the beauties of FAST is is doesn’t impose its own restrictions on the data. You should never run into a case where you say “I want to send this information, but FAST won’t let me do it.”
That being said, it is rare to actually need strings containing null bytes, so if you are coding to a single application, you don’t have to worry about the support for null bytes in strings. It’s only if you are producing a general purpose FAST implementation, or if your specific application uses embedded nulls that you would have to handle this case.
Dale
Dale