From owner-freebsd-current@FreeBSD.ORG Wed Sep 29 21:44:02 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A34A116A4CE; Wed, 29 Sep 2004 21:44:02 +0000 (GMT) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 2E3E743D5D; Wed, 29 Sep 2004 21:44:02 +0000 (GMT) (envelope-from scottl@FreeBSD.org) Received: from [192.168.254.11] (junior-wifi.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.12.11/8.12.10) with ESMTP id i8TLilrQ069681; Wed, 29 Sep 2004 15:44:48 -0600 (MDT) (envelope-from scottl@FreeBSD.org) Message-ID: <415B2C4A.6000807@FreeBSD.org> Date: Wed, 29 Sep 2004 15:42:34 -0600 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20040831 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Kris Kennaway 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> In-Reply-To: <20040929205545.GA36631@xor.obsecurity.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, hits=0.0 required=3.8 tests=none autolearn=no version=2.63 X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on pooker.samsco.org cc: freebsd-current@FreeBSD.org cc: re@FreeBSD.org Subject: Re: HEADS-UP: Library version number bumps (revised) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Sep 2004 21:44:02 -0000 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