There is no real contradiction, I think. The field values are null-terminated as far as their length is less than the maximum field length. As the space (ASCII 32) is a normal character, if field values are right-padded with it till the field length, it's normal rather normal that you don't find nulls at the end.
Example: Given a field length of 3 (the nulls are represented by 0):
"abc":no null at the end "ab0"ne null "ab ":no null at the end "a00": two nulls
I personally decided to do as Anthony.
Phil. [ August 28, 2004: Message edited by: Philippe Maquet ]
The reason for the "null terminated" issue is the statement about the file being read/written by an existing legacy application. This sort of implies that the legacy application is written in C or C++ using asciz null terminated strings.
People, please search the forum first before posting question. This problem has been discussed MANY times and already solved... You are usually not the first one solving some issue.
Joined: Jun 06, 2007
Thanks people for kindly warning... But my intention was to give some clue not answer....
Joined: Feb 04, 2004
Originally posted by Muhammad Shafique: If the record length is fixed then field/attribute termination with null does make sense since we shouldn't add characters after the null (not even spaces). There is no concept of null after null.
I had similar text and simply ignored it!
This is not strictly true as it could mean padding in full with as many "0" bytes as is nescessary couldn't it? It is meerly to fill space to the end of the record after all. I do agree that that soultion would not be in the true sprit of what a null terminted string is supposed to be tho.