(moving this to tcpdump-workers)
---- On Tue, 08 May 2018 14:41:13 +0100 Francois-Xavier Le Bail
<devel.fx.leb...@orange.fr> wrote ----
> On 02/05/2018 14:28, Francois-Xavier Le Bail wrote:
> > After the longjmp change, most of the truncated messages will be based on
> > ndo->ndo_protocol field (like: ND_PRINT("[|%s]", ndo->ndo_protocol) in Guy
> > proposal).
> >
> > To harmonize with other truncated prints, based or not on "tstr" strings,
> > I think we need to update
> > them with a new function like:
> >
> > /* Print the truncated string based on ndo_protocol */
> > void nd_print_trunc(netdissect_options *ndo)
> > {
> > ND_PRINT("[|%s]", ndo->ndo_protocol);
> > }
> >
> > And replace:
> > ND_PRINT("%s", tstr) -> nd_print_trunc(ndo)
> > ND_PRINT("\n\t[|EAP]"); -> nd_print_trunc(ndo)
> >
> > In some cases, an old printing in uppercase will go lowercase.
> > In some cases, we will remove some '\n' or '\t' not essential.
>
> I work on this and I commit HEAD~3..HEAD for first steps.
>
> But, it seems we could have site effects with this process.
>
> e.g.:
> proto1_print(...)
> {
> ndo->ndo_protocol = "proto1";
> ...
> proto2_print(...);
> ...
> }
>
> proto2_print(...)
> {
> ndo->ndo_protocol = "proto2";
> ...
> }
>
> If proto2_print, a "final protocol" (don't call another function with
> ndo_protocol assignment), need
> to print truncated string with/without longjmp process: no problem.
>
> If no truncated case occurs in proto2_print, after return, the proto1_print
> function take the
> control and if truncated case occurs in proto1_print it will print
> "[|proto2]".
>
> Thus after all calls of function with ndo_protocol assignment, we will need
> a ndo_protocol re-assign
> like:
>
> proto1_print(...)
> {
> ndo->ndo_protocol = "proto1";
> ...
> proto2_print(...);
> ndo->ndo_protocol = "proto1";
> ...
> }
>
> It can bring errors (forgetting...).
>
> Could we do things differently ?
With things done this way it looks like this issue could happen, although it
would result in incorrect labeling, not incorrect behaviour.
A possible solution could be some stack structure and a macro to call the next
function, which macro would take care to update the stack before and after the
function call. But to me such a solution looks more complicated than the
problem, I would rather proof-read the source code once and leave it to work.
--
Denis Ovsienko
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
