Re: [tcpdump] Truncated strings

[Denis Ovsienko <denis () ovsienko info>]

(moving this to tcpdump-workers)

 ---- On Tue, 08 May 2018 14:41:13 +0100 Francois-Xavier Le Bail <devel.fx.lebail () 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