tcp_hdr_kind_and_field window COUNT vs. tcp_hdr_option_type window LENGTH

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



After a complete constructing the EBNF of nftables (needed by TextMate, LSP, and Vim syntax highlight), I notice many repeatedly overlaps of syntaxes within the parser_bison.y.

One example of such a overlap pair:


All within the tcp_hdr_option_kind_and_field, the Bison parse tree offers different pathways to the "same?" following `nft` expression:

    tcp option window LENGTH
and
    tcp option window COUNT


For 'tcp options window LENGTH', the Bison pathway is:

  tcp_hdr_option_kind_and_field->tcp_hdr_option_type->WINDOW->LENGTH


For 'tcp option window COUNT', the Bison pathway is:

  tcp_hdr_option_kind_and_field->WINDOW->tcpopt_field_window->COUNT


Is this intentional overlap? Or did I overlook some hidden feature(s) surrounding LENGTH and COUNT?



The Railroad diagram for latest 'tcp_hdr_expr' is only XHTML-viewable via a web browser 'file:///' from your hard drive (GitHub defangs [X]HTML; SVG is too big, PNG is too squishy):

https://github.com/egberts/vim-nftables/blob/master/doc/nftables-railroad-chart.xhtml





[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux