Ah! I see the problem now. If I'm reading you right, the issue is that the hf_register_info structure is hard-coded at compile time.
Now that I understand your argument, I totally agree that your proposal is the right way to go. Sorry for the confusion, -Devin On Fri, 2002-12-13 at 14:50, Guy Harris wrote: > On Fri, Dec 13, 2002 at 10:33:17AM -0500, Devin Heitmueller wrote: > > Since there are numerous variants of extended > > ASCII, it should be left to the dissector to decide which character set > > they are using. This means that we should add types like > > FT_STRING_ISO8859-1 and FT_STRING_UCS2_LE. > > That's precisely the idea that I said might not work. > > What if a string's character set can only be determined at run time, as > per > > Making the character set a property of the field might not > work - for example, that wouldn't work for OEM character sets > in SMB, as that'd have to be something set by an SMB > preference item at run time. It might work for the Mac > character set in Appletalk, however. > > The alternative I suggested, which also lets the dissector decide what > character set is being used, was > > perhaps have the byte-order argument to > "proto_tree_add_item()" specify, for FT_STRING types, > the character set and, in cases where a multi-byte > character type can come in either byte order, the byte > order; > > add a character set+byte order argument to > "proto_tree_add_string()"? > > Then "proto_tree_add_item()" would perform conversation as necessary: > > If the type (supplied in the field that's currently used only > for byte order) is CHARSET_ISO8859-1, it would convert to UTF-8. > > If it was CHARSET_UCS2|LITTLE_ENDIAN, it would convert to UTF-8. > > If it was CHARSET_UCS2|BIG_ENDIAN, it would convert to UTF-8. > > If it was CHARSET_ASCII, it would convert to UTF-8. > > and so on -- Devin Heitmueller Senior Software Engineer Netilla Networks Inc
