Hi, Matthias, You are right that the .sp file is effectively capturing the length of the character arrays. Therefore, it should be fine for the character arrays to contain nil values. The current design is based on C convention of string and user can input strings through an ASCII file (which can not contain nil value anyway).
It would be fine for a C program to use character arrays (also known as opaque objects or blobs) and have FastBit make a copy of such character arrays. The current API in ibis::tablex uses std::string for the character arrays. It is common to assume nil character terminates the string, even though it is actually possible to interpret nil character differently. One possibility of taking advantage of this feature would be to have a different string type column, say type opaque, to explicitly take the length information instead of relying on the string terminators. Of course, the std::string data structure may not be the most appropriate for this, feel free to propose something else if you have one in mind.. John On 8/3/2009 12:11 PM, Matthias Vallentin wrote: > Hi John, > > On Tue, Jul 07, 2009 at 09:34:30AM -0700, K. John Wu wrote: >> The .sp file is an auxiliary file to store the starting positions of >> the strings in the raw data file. > > I would like to pick up this issue to ask a different question. IIRC, it > is not possible to store strings that contain NUL bytes, i.e., strings > in FastBit are NUL-terminated. However, if the offsets are already > stored in the .sp files, we have a starting position + length and would > be independent of the actual content (which could then contain NUL > bytes). Am I overlooking an central piece? > > Matthias _______________________________________________ FastBit-users mailing list [email protected] https://hpcrdm.lbl.gov/cgi-bin/mailman/listinfo/fastbit-users
