Yes... this seems the most reasonable way forward. Thanks Anders!
2010/1/20 Anders Broman <[email protected]>: > > > Hi, > how a bout creating individual fuctions that do the type checking etc and > then call a common routine? > /Anders > -----Original Message----- > From: [email protected] on behalf of Gerasimos Dimitriadis > Sent: Wed 1/20/2010 12:21 PM > To: [email protected] > Subject: [Wireshark-dev] Question on format_value variant > ofproto_tree_add_bits_item function (Take 2) > > Hi all, > > I am writing again my question, because admittedly it was not very > clear what I was asking in the previous email :-[ > > I want to create a _format_value variant(s) of the > proto_tree_add_bits_item function. The easiest way to do so is to > create a single function that takes a void * pointer of the value and > then reads from that address a guint32, a gint32, a float etc > depending on the type of the provided header field. > > The above is the most compact way of implementing such functionality, > but on the other hand no type checking is possible and also this > scheme is inflexible regarding the provided values (you cannot give a > pointer to uint8 if the function expects a pointer to uint32 --- even > worse: you can, but you shouldn't; the compiler will not say anything > about it.). > > The alternative would be to create dedicated functions per header > field type: one for adding bits as uint, one for bits as float etc. > > My thoughts are that adding a function per header field type is the > most robust one, but the temptation of exporting just one function > that can deal with all of them is big! > > So, I want to ask (especially the core team members): Is it acceptable > in general for functions to be more dangerous than usual? > > Best regards, > > Gerasimos > > PS: I tried sending this email from my work (intracom.gr) account, but > the list seems to silently discarding it. Any ideas why this happens? > ___________________________________________________________________________ > Sent via: Wireshark-dev mailing list <[email protected]> > Archives: http://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:[email protected]?subject=unsubscribe > > > ___________________________________________________________________________ > Sent via: Wireshark-dev mailing list <[email protected]> > Archives: http://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:[email protected]?subject=unsubscribe > ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
