file-pcapng_darwin_process_event.c I guess it's not as bad as the filenames with a "+" in the names, but would file-darwin.c be enough?
On Sat, Feb 4, 2023 at 10:48 AM Martin Mathieson via Wireshark-dev < wireshark-dev@wireshark.org> wrote: > Please see https://gitlab.com/wireshark/wireshark/-/merge_requests/9688 > > I have yet to port my (genuinely) local block type, but would like to see > if this approach looks OK. > More thought might be needed to stay safe while dealing with block types > that don't have options. > > On Fri, Feb 3, 2023 at 11:01 AM Martin Mathieson < > martin.r.mathie...@googlemail.com> wrote: > >> >> >> On Fri, Feb 3, 2023 at 7:25 AM Guy Harris <ghar...@sonic.net> wrote: >> >>> On Feb 1, 2023, at 12:58 AM, Joakim <oak...@gmail.com> wrote: >>> >>> > if you manage to add a dissector table that would be great! I believe >>> my company too will implement non-standard blocks so it would be very >>> convenient to have it available. >>> >>> Note that what's being discussed here would *only* handle dissecting the >>> non-standard blocks when you're dissecting the structure of the pcapng file >>> the same way that we can dissect the structure of, for example, JPEG files; >>> it won't affect the handling of the block in libwiretap nor will it affect >>> the handling of it in libwireshark when you're reading a pcapng file as a >>> capture file rather than as some type of file whose internal structure is >>> to be dissected. >>> >>> >> Yes, for me - for now, I only want to check the block values that get >> written into the pcapng file - another tool makes use of them. >> >> >>> We already have a plugin mechanism in libwiretap for the first of those >>> (although the interface could, I think, be improved; I'll look at some work >>> I did on that) and a plugin mechanism in libwireshark (currently using the >>> REC_TYPE_FT_SPECIFIC_{EVENT,REPORT} block type, but that might also be >>> improved). >>> >>> However, you might want to look at implementing *custom* blocks, >>> instead. If your company has a Private Enterprise Number: >>> >>> https://en.wikipedia.org/wiki/Private_Enterprise_Number >>> >>> it can use them, and would not have to worry about some other >>> organization using the same block number that you use. >>> >> >> We use 0x80000000 + <our-enterprise-number> for the first local block >> type we have. >> But we then also use the next 4 numbers for other private block types.. >> I don't know if it was considered, but it would have been unnatural to >> squeeze our 5 block types into a single type. >> >> >>> >>> ___________________________________________________________________________ >>> Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> >>> Archives: https://www.wireshark.org/lists/wireshark-dev >>> Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev >>> mailto:wireshark-dev-requ...@wireshark.org >>> ?subject=unsubscribe >>> >> > ___________________________________________________________________________ > Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> > Archives: https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org > ?subject=unsubscribe >
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
