On Thu, Nov 21, 2013 at 9:18 AM, <mmann78@xxxxxxxxxxxx> wrote:
> My similar, but less thorough idea was to have the "GUI" (GTK+/Qt/tshark) do
> the proto_* value lookup (of only the protocols it needed) during some
> "initialize" function, just like dissectors grab the "handles" of the other
> dissectors they need in the proto_reg_handoff function.
>
> Could making the proto_* variables public be part of the register.c python
> script?
Either of those might work too.
> -----Original Message-----
> From: Evan Huus <eapache@xxxxxxxxx>
> To: Developer support list for Wireshark <wireshark-dev@xxxxxxxxxxxxx>
> Sent: Thu, Nov 21, 2013 8:48 am
> Subject: Re: [Wireshark-dev] [Wireshark-commits] rev 53473: /trunk/ui/
> /trunk/ui/gtk/: main_menubar.c /trunk/ui/qt/: main_window_slots.cpp
>
>> Do you think that's something
>> I should add for the other dissectors? I know string compares are more
>> expensive than integers, but I don't believe the integers are available.
>> I
>> also don't want to establish precendence and have dissectors think they
>> need
>> the proto_* variable to be public.
>
> I don't see any specific reason to keep the proto_ variables private,
> so I have no objection to making them available. All of the protocols
> involved in this case already have separate header files anyways.
>
> I'm almost tempted to create a separate file just for the proto_
> variables so that any code that needs to manipulate protocol IDs
> doesn't have to include a bunch of different headers, but I think
> that's overkill at this point.
>
>
> ___________________________________________________________________________
> Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
> Archives: http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe