Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 29 Sep 2004 15:42:34 -0600
From:      Scott Long <scottl@FreeBSD.org>
To:        Kris Kennaway <kris@obsecurity.org>
Cc:        re@FreeBSD.org
Subject:   Re: HEADS-UP: Library version number bumps (revised)
Message-ID:  <415B2C4A.6000807@FreeBSD.org>
In-Reply-To: <20040929205545.GA36631@xor.obsecurity.org>
References:  <20040929030546.GE16305@electra.cse.Buffalo.EDU> <20040929092710.GA59303@cat.robbins.dropbear.id.au> <20040929123100.GA600@electra.cse.Buffalo.EDU> <20040929135217.GA16594@saltmine.radix.net> <20040929164422.GA9262@xor.obsecurity.org> <20040929171619.GC26065@saltmine.radix.net> <20040929172721.GA12793@xor.obsecurity.org> <20040929180703.GA16806@xor.obsecurity.org> <415AFF26.8010603@FreeBSD.org> <20040929183749.GA29571@xor.obsecurity.org> <20040929205545.GA36631@xor.obsecurity.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?415B2C4A.6000807>