>> > The struct bu_vls defines the char * before the string length. While
>> > writing
>> > the import function for the annotation primitive, one has to
>> > initialize(calloc) the char array to a corresponding size but the size
>> > is
>> > defined later. I checked out the case for other primitives for other
>> > structs
>> > as well. In every case the length is defined before the array, hence the
>> > exact space is alloted(malloc or calloc). How to deal with this ? Can
>> > the
>> > organisation of the vls_struct be changed?
>>
>> I don't get it. The order of members in a struct is usually
>> unimportant. Do you have a code example?
>>
>> However, what i can say is that you should deal with a bu_vls only via
>> the bu_vls_~() functions. Never touch the member variables directly.
>> E.g. use bu_vls_cstr() to retrieve the string.
>> And, as an example of how to import and export strings you could look
>> at extrude's sketch_name.
>>
> I already had a look at other primitives import functions, the "char *" is
> allocated memory of length equal to NAMESIZE, i.e. 16 . but the annotation
> label can have a length that the user desires. This is what I was trying to
> do :
>
> https://docs.google.com/document/d/1UaDU9o9G98_qGDLMe2wenU3MPL5WxBs00niFZT6Bk_I/edit?usp=sharing
I think I got it now. The good news is that bu_vls isn't the problem ;)
In version 4 databases the element names were restricted to NAMESIZE
characters. (This restriction isn't true for version 5 databases any
more.) That's why the import routines copy always NAMESIZE characters
from the stream when they expect a string.
You have several options here:
- Ignore version 4 databases and support version 5 databases only.
E.g., the hrt primitive does it.
- Read/write a variable length string from/to a version 4 database
stream (the ptr variable). There you have to determine the length of
the string. I could imagine two solutions for this:
- The bytes of the string are copied to the stream and are
zero-terminated. When reading from the stream you have to read from
it byte by byte until you reach the '\0' byte.
- You write first the length of the string to the stream ("network
long") and then the string itself.
However, I don't know how the side effects with other functions as
g2asc are. Therefore, ignoring version 4 databases is a valid
solution.
> Regarding the dev logs, I updated them on
> https://brlcad.org/wiki/Google_Summer_of_Code/2017 . I'll be updating the
> progress in the previous 2-3 days soon.
Thanks!
Regards,
Daniel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
BRL-CAD Developer mailing list
brlcad-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/brlcad-devel
