Now, I realize the topic of "null-terminated" has been beaten almost to death, but I didn't see anyone refer to my specific situation. If I'm mistaken on this, please point me to the proper thread.
I'm doing B&S 2.2.3, and have two lines that confuse the heck out of me.
First line is from Data File Format, Data section of the assignment:
Data section. Repeat to end of file: 1 byte flag. 00 implies valid record, 0xFF implies deleted record Record containing fields in order specified in schema section, no separators between fields, each field fixed length at maximum specified in schema information.
Which says "fixed field format", which would be padded by spaces.
Second quote, last paragraph in Data File Format:
All text values, and all fields (which are text only), contain only 8 bit characters, null terminated if less than the maximum length for the field.
Which comes to say that strings within fields should be null-terminated if shorter than field width.
Looking with a hex editor at the data file provided by Sun, I do not see any null characters in the record fields -- only spaces.
I'm not sure what to do, other than email Sun. Currently my program applies a null character to a text value with a length shorter than the field width, and pad the rest to enforce the fixed width, such that in a field 10 bytes wide:
'f''o''o''\0'' '' '' '' '' '' '
any help would be appreciated! [ January 04, 2005: Message edited by: Vincent Hernandez ]
I thought this particular point was referred to in the following:
In general, you should not ask your question; rather you should consider the options available and make a decision about how to address the problem yourself.
I considered the following cases: 1. 'f''o''o''\0'' '' '' '' '' '' ' -> "foo" 2. 'f''o''o'''' '' '' '' '' '' ' -> "foo "
Both are valid according to my instructions. My database file used the second case (no null-termination). With relational databases it is very common to pad strings with spaces. With or without the spaces, the name of the hotel/city is "foo". So I made my application to be able to read both.
When you save a record, you have several options available: 1. Case 1 2. Case 2 3. Same as previous/other records 4...
You base your decision on your assumptions. You can assume the instructions rule and you pick 2. Or you can assume that the database file, which is probably made by a legacy tool, is right, and pick 1. Or go for another solution. As long as you defend your choice in your choices document.
Personally, I did not implement any code that wrote/updated any fields that were padded.