On Sun, 26 Feb 2023 15:46:56 +0100
Francois-Xavier Le Bail <devel.fx.leb...@orange.fr> wrote:

[...]
> >> I wonder if there would be any other incurred future maintenance.  
> 
> The proposed patch is:
> 
> diff --git a/pcap-filter.manmisc.in b/pcap-filter.manmisc.in
> index 10aeb42d..864cd238 100644
> --- a/pcap-filter.manmisc.in
> +++ b/pcap-filter.manmisc.in
> @@ -1027,7 +1027,7 @@ The following ICMPv6 type field values are
> available: .BR \%icmp6-multicastrouterterm .
>  .IP
>  The following TCP flags field values are available: \fBtcp-fin\fP,
> -\fBtcp-syn\fP, \fBtcp-rst\fP, \fBtcp-push\fP,
> +\fBtcp-syn\fP, \fBtcp-rst\fP, \fBtcp-psh\fP (or \fBtcp-push\fP),
>  \fBtcp-ack\fP, \fBtcp-urg\fP, \fBtcp-ece\fP,
>  \fBtcp-cwr\fP.
>  .LP
> diff --git a/scanner.l b/scanner.l
> index 85fe395a..7cc39f77 100644
> --- a/scanner.l
> +++ b/scanner.l
> @@ -475,6 +475,7 @@ tcp-fin                     { yylval->h = 0x01;
> return NUM; } tcp-syn                        { yylval->h = 0x02;
> return NUM; } tcp-rst                        { yylval->h = 0x04;
> return NUM; } tcp-push               { yylval->h = 0x08; return NUM; }
> +tcp-psh                        { yylval->h = 0x08; return NUM; }
>  tcp-ack                        { yylval->h = 0x10; return NUM; }
>  tcp-urg                        { yylval->h = 0x20; return NUM; }
>  tcp-ece                        { yylval->h = 0x40; return NUM; }
> 
> (the tcpdump man page will need an update too.)

Obviously, the change would be easy to make.  But what comes to my mind
is next 5 or 10 years of answering the same question: "Why tcp-psh is in
the man page/my new book/stackoverflow/whatever and it works in my
development environment, but some production servers reject the syntax?
These are on a very expensive long term support contract, so everything
is supposed just to work, right?  Right?"

You could argue that there would be a note in the "backward
compatibility" section, but I could argue that only a fraction of users
ever reads any documentation that comes directly with the software.  It
would be better to have some other problems solved before looking at
this discrepancy again.

Specifically, I wonder if it would be practicable to process all
remaining longjmp() backlog in the next few months.  The script reports
35 not yet converted files ranging from 110 to 2755 CLOC each.

-- 
    Denis Ovsienko
_______________________________________________
tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org
To unsubscribe send an email to tcpdump-workers-le...@lists.tcpdump.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

Reply via email to