Hello, Vojtech, Vojtech Horky on 2012-07-29: > 2012/7/29 Sean Bartell <[email protected]>: > > I've finished implementing parameters in Bithenge. You can see the > > possibilities in the new example file[0]. Parameters make it possible to > Good job. I have tried it and it works :-). Though I was confused a > bit where the .len (in pascal_string) came from. In my opinion, the > original version of the file [1] was more intuitive. On the other > hand, it shows that Bithenge supports "nesting". Very nice.
Yeah, it's a contrived example just to make sure all of my code was tested. > > handle fields of known length as well as length fields followed by data. > > However, many cases are not yet possible; for instance, USB descriptors > > can't use the length field because it includes its own length. This will > > be possible once scripts can get arbitrary subblobs. > I am not sure I follow. I thought that these subblobs would be useful > when the data contains some kind of pointers in them (e.g. that actual > data are at given offset). But here you have a bit different > situation, IMHO. If the descriptor is of unknown type (e.g. some > vendor specific), you want to skip next (.bLength - 2) bytes and > decode next descriptor. (Obviously, if you know the descriptor type, > you ignore the .bLength field.) I do not see how subblobs would help > you. What have I missed? First, when you know the descriptor type, I would still use the length field to get the right amount of data and then decode it. Your way is essentially equivalent, though. Second, I'm hoping to make all sorts of seeking possible with subblobs, so you could say "read a uint32le into .len, then go back and read .len raw bytes" to skip the unknown descriptor. I implemented "if" today, but documentation, examples, and "switch" will have to wait for tomorrow. Thanks, Sean _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
