Re: HEADS-UP: Library version number bumps (revised)

Kris Kennaway wrote:
> On Wed, Sep 29, 2004 at 11:37:49AM -0700, Kris Kennaway wrote:
> 
>>On Wed, Sep 29, 2004 at 12:29:58PM -0600, Scott Long wrote:
>>
>>
>>>> libpcap
>>>
>>>From the list below, I wonder if all of the yy* symbols are from yacc.
>>>Would these actually be considered to be part of the public interface?
>>>The only two symbols that aren't in the yy* form look to definitely be
>>>for internal use only.  Can we fix __xuname instead?
>>
>>Perhaps.  There's also the pcap_lval symbol.  I haven't checked
>>whether anything uses it or the yy_*.
> 
> 
> A number of packages link to libpcap and call the yy_* functions:
> 
> ipfm-0.11.5/sbin/ipfm (libpcap.so.2) matches symbols yy_delete_buffer yyrestart yystacksize yy_scan_buffer yy_load_buffer_state yy_create_buffer yyerrflag yysindex yytext yytable yyparse yysslim yydefred yyvsp yyrindex yywrap yyssp yynerrs yyout yyval yyleng yyss yy_flush_buffer yylen yy_scan_string yygindex yy_scan_bytes yyin yydebug yydgoto yycheck yy_switch_to_buffer yy_init_buffer yylex yylhs yyvs yychar
> 
> rid-1.0/sbin/rid (libpcap.so.2) matches symbols yy_delete_buffer yyrestart yystacksize yy_scan_buffer yy_load_buffer_state yy_create_buffer yyerrflag yysindex yytext yytable yyparse yysslim yydefred yyvsp yyrindex yywrap yyssp yynerrs yyout yyval yyleng yyss yy_flush_buffer yylen yy_scan_string yygindex yy_scan_bytes yyin yydebug yydgoto yycheck yy_switch_to_buffer yy_init_buffer yylex yylhs yyvs yychar
> 
> bandwidthd-1.2.1/bandwidthd/bandwidthd (libpcap.so.2) matches symbols yy_delete_buffer yyrestart yy_scan_buffer yy_load_buffer_state yy_create_buffer yytext yyparse yywrap yynerrs yyout yyleng yy_flush_buffer yy_scan_string yy_scan_bytes yyin yy_switch_to_buffer yy_init_buffer yylex yychar
> 
> bro-0.8_1/sbin/bro (libpcap.so.2) matches symbols yynerrs yydebug yychar
> 
> honeyd-0.8b/bin/honeyd (libpcap.so.2) matches symbols yynerrs yychar
> 
> So even if you fix the __xuname reference it looks like they'll still
> be broken.
> 
> Kris

These are all generic names that lex/yacc uses to build its parser code.
All of the packages that you point out use their own private set of
lex/yacc magic.  Looking at 'nm -u ipfm' shows no unresolved symbols
related to yy*.

Scott