[tcpdump-workers] [tcpdump] Truncated strings

[Denis Ovsienko]

(moving this to tcpdump-workers)

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