process_mrtd_table_dump_v2_peer_index_table not filling in "entry"

Issue #3 wontfix
Anonymous created an issue


seems that a revision of the function process_mrtd_table_dump_v2_peer_index_table (in bgpdump_lib.c) has stopped filling in the "entry" parameter that is given as an argument to the function. This leads to the fact that the entry is never filled and subsequently not usable by the calling program (or I might be missing something).

(plus of course you need to return a 1 but that bug has been already reported).



Comments (4)

  1. Rene Wilhelm

    Going back in the revision history, I get the impression this has always been the case; ever since the routine was added in support for the new MRTD Table_dump_v2 format (some 7 years ago). The "entry" argument is not filled, the index is only stored and used internally. By retuning 0 instead of 1, the calling bgpdump_read_next() routine will discard the entry, not pass incomplete data to the user.

    Not sure if we should change it. Drawing from experience and example code (like bgpdump.c) users may have assumed all entries of type BGPDUMP_TYPE_TABLE_DUMP_V2 hold prefix data; they decode entry->body.mrtd_table_dump without checking if the subtype justifies that.

  2. Max Lapan

    As Rene said, bgpdump behaviour is correct -- this function reads peer index table into memory and returns, preventing further processing of this block by returning 0. This is misleading, but code quality is a totally different story :).

  3. Log in to comment