On Fri, Apr 6, 2012 at 3:32 AM, Vojtech Horky <[email protected]> wrote: > Hi Taylor, > please, next time start a new thread. That way comments to individual > applications would not interleave.
Will do. > I think that you focus too much on the ability to parse structs from C > headers. Complex structures cannot be captured by C structs well and > what you find in a C header are mostly fragments that are hammered > together by the application. A typical example is a USB string > descriptor where first byte denotes string length and is followed by > the actual string. That is impossible to catch in a struct in a > reasonable way. That is why a custom format shall be defined. Yes, I definitely agree that C is unable to handle many types of structures, especially variable length structures. Never the less, I also believe that being able to parse a C header and save it in a libBinaryEditor format will be immensely helpful as the C structures will act as building blocks for more complex structures, as you described. This file can then be edited and variable length structures can be tacked on to C structures or vice versa. The libBinaryEditor will act sort of as the glue. > Probably, an opposite function - convert format to the struct - would > be more useful. The scenario I have in mind is that the developer > first wants to get a feel for the thing and just browses (more or > less) manually existing data and afterwards, starts coding. I'm not sure what you mean by "manually existing data". Do you mean, for example, using the library to view data on a UDF partition, and how it is structured. Then coding? That is definitely a goal of mine for this project, however I will not be able to define every format a developer might want during the scope of this summer. My hope is to provide a framework, so that adding a UDF or USB or TCP descriptor will be a simple task. > For the timeline: I would appreciate if the advanced functionality > would appear earlier. For example, without the variable-length > structures or dynamic offsets (e.g. first byte specifies where the > data starts) it editor would be just a little bit smarter hex viewer. Thanks for that, looking over my proposal, I realized that my priorities were a little out of order. I have moved complex structure handling from week 9 to week 3/4. Also, as for selecting the first by for where the data starts, that is a subgoal of week 4, when the interface is first created. Later, in week 8, that goal refers to being able to type in a byte address and have the library identify which field and structure it belongs to. Also, I realized that some of my goals could probably be compacted, so that I am working on multiple goals in a week, rather than a single goal. The updated timeline reflects this. I have also included 2 weeks for testing the library on various different structures in order to verify the library will be able to handle complex structures in real world applications. If anybody has a unique complex structure used in the real world that they would specifically like this library to read, please let me know about it so I can test the library on it. Right now my tests will deal with the FAT filesystem, UDF filesystem, and USB. > > That is for my first impression. I may add more comments later. > Thanks again for the input. Taylor _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
