Re: svn commit: r362333 - in head: contrib/flex contrib/flex/src usr.bin/lex usr.bin/lex/lib
On Sat, Feb 13, 2021 at 02:39:56AM -0500, Jung-uk Kim wrote:
> On 21. 2. 13., Jung-uk Kim wrote:
> > On 21. 2. 12., Mark Johnston wrote:
> >> On Thu, Jun 18, 2020 at 06:09:16PM +, Jung-uk Kim wrote:
> >>> Author: jkim
> >>> Date: Thu Jun 18 18:09:16 2020
> >>> New Revision: 362333
> >>> URL: https://svnweb.freebsd.org/changeset/base/362333
> >>>
> >>> Log:
> >>> MFV:r362286
> >>>
> >>> Merge flex 2.6.4.
> >>
> >> This seems to have introduced a regression: input() now returns 0
> >> instead of EOF to indicate that the end of input was reached. This has
> >> been reported in a few places:
> >>
> >> https://github.com/westes/flex/issues/448
> >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911415
> >>
> >> It breaks the scanner used by libdtrace, and as a result dtrace is
> >> unable to resolve some probe argument types:
> >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253440
> >>
> >> I have a small patch to libdtrace which works around this. The upstream
> >> commit that introduced the change is fairly old at this point, and
> >> upstream seems somewhat unresponsive, so I'm not sure it'll get
> >> reverted. Some other scanners in the tree look like they'd be affected,
> >> like crypto/heimdal/lib/asn1/lex.l or
> >> sys/contrib/dev/acpica/compiler/aslsupport.l, so I'm wondering if we
> >> should revert this particular change for 13.0. Certainly we should fix
> >> the DTrace bug one way or another for 13.0.
> >
> > I think it does not make much sense and we should revert the upstream
> > change. Does the attached patch work for you?
The original patch fixes it, the updated one does not since libdtrace
sets -l in LFLAGS. :)
Removing it causes a build failure but it is trivial to resolve. I am
running some tests now to see if anything regressed.
> Now I believe the author wanted Lex compatibility. Maybe we should do
> the attached patch instead?
Is it common to use the base system's flex for ports and out-of-tree
code generally? I have no real idea. I'd be worried about configure
scripts that use the flex version to determine whether or not to apply a
workaround for this change. I also note that Debian does not seem to
have patched this.
Looking through consumers in the tree (all *.l files), the following
scanners could be affected:
- libdtrace
- contrib/com_err/lex.l
- contrib/ipfilter/iplang/iplang_l.l
- does not appear to be built
- crypto/heimdal/lib/asn1/lex.l
- crypto/heimdal/lib/com_err/lex.l
- crypto/heimdal/lib/hx509/sel-lex.l
- crypto/heimdal/lib/sl/slc-lex.l
- sys/contrib/dev/acpica/compiler/aslsupport.l
- sys/contrib/dev/acpica/compiler/prparser.l
It would not be too difficult to patch them, and I think in most cases
the problem is not very severe and is only triggered by invalid input.
For instance, asn1_compile enters an infinite loop if the input file
contains an unterminated comment.
So for 13.0 I am kind of inclined to just patch consumers. If you think
we should revert the change in flex, I'm ok with that too and will
remove the use of -l in libdtrace.
> diff --git a/contrib/flex/src/flex.skl b/contrib/flex/src/flex.skl
> index 242645f53245..c23b944ea473 100644
> --- a/contrib/flex/src/flex.skl
> +++ b/contrib/flex/src/flex.skl
> @@ -1863,7 +1863,11 @@ m4_ifdef( [[M4_YY_USE_LINENO]],
> case EOB_ACT_END_OF_FILE:
> {
> if ( yywrap( M4_YY_CALL_ONLY_ARG ) )
> +#ifdef YY_FLEX_LEX_COMPAT
> return 0;
> +#else
> + return EOF;
> +#endif
>
> if ( !
> YY_G(yy_did_buffer_switch_on_eof) )
> YY_NEW_FILE;
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r362333 - in head: contrib/flex contrib/flex/src usr.bin/lex usr.bin/lex/lib
On 21. 2. 13., Jung-uk Kim wrote:
> On 21. 2. 12., Mark Johnston wrote:
>> On Thu, Jun 18, 2020 at 06:09:16PM +, Jung-uk Kim wrote:
>>> Author: jkim
>>> Date: Thu Jun 18 18:09:16 2020
>>> New Revision: 362333
>>> URL: https://svnweb.freebsd.org/changeset/base/362333
>>>
>>> Log:
>>> MFV: r362286
>>>
>>> Merge flex 2.6.4.
>>
>> This seems to have introduced a regression: input() now returns 0
>> instead of EOF to indicate that the end of input was reached. This has
>> been reported in a few places:
>>
>> https://github.com/westes/flex/issues/448
>> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911415
>>
>> It breaks the scanner used by libdtrace, and as a result dtrace is
>> unable to resolve some probe argument types:
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253440
>>
>> I have a small patch to libdtrace which works around this. The upstream
>> commit that introduced the change is fairly old at this point, and
>> upstream seems somewhat unresponsive, so I'm not sure it'll get
>> reverted. Some other scanners in the tree look like they'd be affected,
>> like crypto/heimdal/lib/asn1/lex.l or
>> sys/contrib/dev/acpica/compiler/aslsupport.l, so I'm wondering if we
>> should revert this particular change for 13.0. Certainly we should fix
>> the DTrace bug one way or another for 13.0.
>
> I think it does not make much sense and we should revert the upstream
> change. Does the attached patch work for you?
Now I believe the author wanted Lex compatibility. Maybe we should do
the attached patch instead?
Jung-uk Kim
diff --git a/contrib/flex/src/flex.skl b/contrib/flex/src/flex.skl
index 242645f53245..c23b944ea473 100644
--- a/contrib/flex/src/flex.skl
+++ b/contrib/flex/src/flex.skl
@@ -1863,7 +1863,11 @@ m4_ifdef( [[M4_YY_USE_LINENO]],
case EOB_ACT_END_OF_FILE:
{
if ( yywrap( M4_YY_CALL_ONLY_ARG ) )
+#ifdef YY_FLEX_LEX_COMPAT
return 0;
+#else
+ return EOF;
+#endif
if ( ! YY_G(yy_did_buffer_switch_on_eof) )
YY_NEW_FILE;
OpenPGP_signature
Description: OpenPGP digital signature
Re: svn commit: r362333 - in head: contrib/flex contrib/flex/src usr.bin/lex usr.bin/lex/lib
On 21. 2. 12., Mark Johnston wrote:
> On Thu, Jun 18, 2020 at 06:09:16PM +, Jung-uk Kim wrote:
>> Author: jkim
>> Date: Thu Jun 18 18:09:16 2020
>> New Revision: 362333
>> URL: https://svnweb.freebsd.org/changeset/base/362333
>>
>> Log:
>> MFV: r362286
>>
>> Merge flex 2.6.4.
>
> This seems to have introduced a regression: input() now returns 0
> instead of EOF to indicate that the end of input was reached. This has
> been reported in a few places:
>
> https://github.com/westes/flex/issues/448
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911415
>
> It breaks the scanner used by libdtrace, and as a result dtrace is
> unable to resolve some probe argument types:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253440
>
> I have a small patch to libdtrace which works around this. The upstream
> commit that introduced the change is fairly old at this point, and
> upstream seems somewhat unresponsive, so I'm not sure it'll get
> reverted. Some other scanners in the tree look like they'd be affected,
> like crypto/heimdal/lib/asn1/lex.l or
> sys/contrib/dev/acpica/compiler/aslsupport.l, so I'm wondering if we
> should revert this particular change for 13.0. Certainly we should fix
> the DTrace bug one way or another for 13.0.
I think it does not make much sense and we should revert the upstream
change. Does the attached patch work for you?
Jung-uk Kim
diff --git a/contrib/flex/src/flex.skl b/contrib/flex/src/flex.skl
index 242645f53245..b0f1b2ad297c 100644
--- a/contrib/flex/src/flex.skl
+++ b/contrib/flex/src/flex.skl
@@ -1863,7 +1863,7 @@ m4_ifdef( [[M4_YY_USE_LINENO]],
case EOB_ACT_END_OF_FILE:
{
if ( yywrap( M4_YY_CALL_ONLY_ARG ) )
- return 0;
+ return EOF;
if ( ! YY_G(yy_did_buffer_switch_on_eof) )
YY_NEW_FILE;
OpenPGP_signature
Description: OpenPGP digital signature
Re: svn commit: r362333 - in head: contrib/flex contrib/flex/src usr.bin/lex usr.bin/lex/lib
On Thu, Jun 18, 2020 at 06:09:16PM +, Jung-uk Kim wrote: > Author: jkim > Date: Thu Jun 18 18:09:16 2020 > New Revision: 362333 > URL: https://svnweb.freebsd.org/changeset/base/362333 > > Log: > MFV:r362286 > > Merge flex 2.6.4. This seems to have introduced a regression: input() now returns 0 instead of EOF to indicate that the end of input was reached. This has been reported in a few places: https://github.com/westes/flex/issues/448 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=911415 It breaks the scanner used by libdtrace, and as a result dtrace is unable to resolve some probe argument types: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=253440 I have a small patch to libdtrace which works around this. The upstream commit that introduced the change is fairly old at this point, and upstream seems somewhat unresponsive, so I'm not sure it'll get reverted. Some other scanners in the tree look like they'd be affected, like crypto/heimdal/lib/asn1/lex.l or sys/contrib/dev/acpica/compiler/aslsupport.l, so I'm wondering if we should revert this particular change for 13.0. Certainly we should fix the DTrace bug one way or another for 13.0. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r362333 - in head: contrib/flex contrib/flex/src usr.bin/lex usr.bin/lex/lib
On Wed, Jun 24, 2020 at 12:09:03PM +0200, Dimitry Andric wrote:
> On 24 Jun 2020, at 02:41, Kyle Evans wrote:
> >
> > On Thu, Jun 18, 2020 at 1:09 PM Jung-uk Kim wrote:
> >>
> >> Author: jkim
> >> Date: Thu Jun 18 18:09:16 2020
> >> New Revision: 362333
> >> URL: https://svnweb.freebsd.org/changeset/base/362333
> >>
> >> Log:
> >> MFV: r362286
> >>
> >> Merge flex 2.6.4.
> >>
> >
> > Hi,
> >
> > I'm looking at getting amd64 world buildable again by gcc6; this seems
> > to give it some gas:
> >
> > /usr/src/contrib/flex/src/main.c: In function 'check_options':
> > /usr/src/contrib/flex/src/main.c:347:14: error: assignment discards
> > 'const' qualifier from pointer target type
> > [-Werror=discarded-qualifiers]
> > if ((slash = strrchr(M4, '/')) != NULL) {
> >
> > The following trivial patch seems to make gcc6 happy again.
>
> This is a strange one. As gcc6 has been removed from ports, I had to
> resort to an older 12-STABLE box which still had it, but no matter what
> I try, I cannot get the warning that is being produced by the CI system.
> What does it do differently?
>
> Also, the warning is indeed bogus, as strrchr() returns a non-const char
> pointer. As I can't reproduce it, I also can't verify which gcc version
> fixes the bogus warning.
The warning is correct if you have a C++-aware string.h. It will provide
two overloads for strrchr, which return the constness of the argument.
So if you give it a const char *, it returns a const char *; if you give
it a char *, it returns a char *.
Joerg
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r362333 - in head: contrib/flex contrib/flex/src usr.bin/lex usr.bin/lex/lib
On Wed, Jun 24, 2020 at 5:09 AM Dimitry Andric wrote:
>
> On 24 Jun 2020, at 02:41, Kyle Evans wrote:
> >
> > On Thu, Jun 18, 2020 at 1:09 PM Jung-uk Kim wrote:
> >>
> >> Author: jkim
> >> Date: Thu Jun 18 18:09:16 2020
> >> New Revision: 362333
> >> URL: https://svnweb.freebsd.org/changeset/base/362333
> >>
> >> Log:
> >> MFV: r362286
> >>
> >> Merge flex 2.6.4.
> >>
> >
> > Hi,
> >
> > I'm looking at getting amd64 world buildable again by gcc6; this seems
> > to give it some gas:
> >
> > /usr/src/contrib/flex/src/main.c: In function 'check_options':
> > /usr/src/contrib/flex/src/main.c:347:14: error: assignment discards
> > 'const' qualifier from pointer target type
> > [-Werror=discarded-qualifiers]
> > if ((slash = strrchr(M4, '/')) != NULL) {
> >
> > The following trivial patch seems to make gcc6 happy again.
>
> This is a strange one. As gcc6 has been removed from ports, I had to
> resort to an older 12-STABLE box which still had it, but no matter what
> I try, I cannot get the warning that is being produced by the CI system.
> What does it do differently?
>
> Also, the warning is indeed bogus, as strrchr() returns a non-const char
> pointer. As I can't reproduce it, I also can't verify which gcc version
> fixes the bogus warning.
>
It's bogus, but it's also not-even-wrong given that strrchr doesn't do
anything to make it actually safe to mutate *strrchr() in a scenario
like this where the input is apparently a string literal. I consider
it an anti-footgun measure to make sure we've constified slash here.
Thanks,
Kyle Evans
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r362333 - in head: contrib/flex contrib/flex/src usr.bin/lex usr.bin/lex/lib
On 24 Jun 2020, at 02:41, Kyle Evans wrote:
>
> On Thu, Jun 18, 2020 at 1:09 PM Jung-uk Kim wrote:
>>
>> Author: jkim
>> Date: Thu Jun 18 18:09:16 2020
>> New Revision: 362333
>> URL: https://svnweb.freebsd.org/changeset/base/362333
>>
>> Log:
>> MFV: r362286
>>
>> Merge flex 2.6.4.
>>
>
> Hi,
>
> I'm looking at getting amd64 world buildable again by gcc6; this seems
> to give it some gas:
>
> /usr/src/contrib/flex/src/main.c: In function 'check_options':
> /usr/src/contrib/flex/src/main.c:347:14: error: assignment discards
> 'const' qualifier from pointer target type
> [-Werror=discarded-qualifiers]
> if ((slash = strrchr(M4, '/')) != NULL) {
>
> The following trivial patch seems to make gcc6 happy again.
This is a strange one. As gcc6 has been removed from ports, I had to
resort to an older 12-STABLE box which still had it, but no matter what
I try, I cannot get the warning that is being produced by the CI system.
What does it do differently?
Also, the warning is indeed bogus, as strrchr() returns a non-const char
pointer. As I can't reproduce it, I also can't verify which gcc version
fixes the bogus warning.
-Dimitry
signature.asc
Description: Message signed with OpenPGP
Re: svn commit: r362333 - in head: contrib/flex contrib/flex/src usr.bin/lex usr.bin/lex/lib
On 20. 6. 23., Kyle Evans wrote:
> On Tue, Jun 23, 2020 at 8:07 PM Jung-uk Kim wrote:
>>
>> On 20. 6. 23., Kyle Evans wrote:
>>> On Thu, Jun 18, 2020 at 1:09 PM Jung-uk Kim wrote:
Author: jkim
Date: Thu Jun 18 18:09:16 2020
New Revision: 362333
URL: https://svnweb.freebsd.org/changeset/base/362333
Log:
MFV: r362286
Merge flex 2.6.4.
>>>
>>> Hi,
>>>
>>> I'm looking at getting amd64 world buildable again by gcc6; this seems
>>> to give it some gas:
>>>
>>> /usr/src/contrib/flex/src/main.c: In function 'check_options':
>>> /usr/src/contrib/flex/src/main.c:347:14: error: assignment discards
>>> 'const' qualifier from pointer target type
>>> [-Werror=discarded-qualifiers]
>>>if ((slash = strrchr(M4, '/')) != NULL) {
>>>
>>> The following trivial patch seems to make gcc6 happy again.
>>>
>>> diff --git a/contrib/flex/src/main.c b/contrib/flex/src/main.c
>>> index 711e387b1b5..97e043c6275 100644
>>> --- a/contrib/flex/src/main.c
>>> +++ b/contrib/flex/src/main.c
>>> @@ -342,7 +342,7 @@ void check_options (void)
>>> /* Setup the filter chain. */
>>> output_chain = filter_create_int(NULL, filter_tee_header,
>>> headerfilename);
>>> if ( !(m4 = getenv("M4"))) {
>>> - char *slash;
>>> + const char *slash;
>>> m4 = M4;
>>> if ((slash = strrchr(M4, '/')) != NULL) {
>>> m4 = slash+1;
>>
>> Hmm... It looks like a false positive and I am little reluctant to
>> change the vendor code.
>>
>> Can you just add "-Wno-discarded-qualifiers" or something to
>> CWARNFLAGS.gcc in share/mk/bsd.sys.mk for some WARNS level?
>>
>
> Do we not have a working relationship with an upstream on this one to
> sort it out?
Not really. You may file an issue or a pull request but I don't see
much activity from the author recently.
https://github.com/westes/flex
Jung-uk Kim
> It's debatably correct; M4 is effectively a const string (string
> literal, as far as I can tell) and strrchr promises a little more than
> it should because we really shouldn't mutate the result in that kind
> of scenario. In this case, the result isn't mutated, but it certainly
> looks like it could be with the current declaration of slash.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r362333 - in head: contrib/flex contrib/flex/src usr.bin/lex usr.bin/lex/lib
On Tue, Jun 23, 2020 at 8:07 PM Jung-uk Kim wrote:
>
> On 20. 6. 23., Kyle Evans wrote:
> > On Thu, Jun 18, 2020 at 1:09 PM Jung-uk Kim wrote:
> >>
> >> Author: jkim
> >> Date: Thu Jun 18 18:09:16 2020
> >> New Revision: 362333
> >> URL: https://svnweb.freebsd.org/changeset/base/362333
> >>
> >> Log:
> >> MFV: r362286
> >>
> >> Merge flex 2.6.4.
> >>
> >
> > Hi,
> >
> > I'm looking at getting amd64 world buildable again by gcc6; this seems
> > to give it some gas:
> >
> > /usr/src/contrib/flex/src/main.c: In function 'check_options':
> > /usr/src/contrib/flex/src/main.c:347:14: error: assignment discards
> > 'const' qualifier from pointer target type
> > [-Werror=discarded-qualifiers]
> >if ((slash = strrchr(M4, '/')) != NULL) {
> >
> > The following trivial patch seems to make gcc6 happy again.
> >
> > diff --git a/contrib/flex/src/main.c b/contrib/flex/src/main.c
> > index 711e387b1b5..97e043c6275 100644
> > --- a/contrib/flex/src/main.c
> > +++ b/contrib/flex/src/main.c
> > @@ -342,7 +342,7 @@ void check_options (void)
> > /* Setup the filter chain. */
> > output_chain = filter_create_int(NULL, filter_tee_header,
> > headerfilename);
> > if ( !(m4 = getenv("M4"))) {
> > - char *slash;
> > + const char *slash;
> > m4 = M4;
> > if ((slash = strrchr(M4, '/')) != NULL) {
> > m4 = slash+1;
>
> Hmm... It looks like a false positive and I am little reluctant to
> change the vendor code.
>
> Can you just add "-Wno-discarded-qualifiers" or something to
> CWARNFLAGS.gcc in share/mk/bsd.sys.mk for some WARNS level?
>
Do we not have a working relationship with an upstream on this one to
sort it out?
It's debatably correct; M4 is effectively a const string (string
literal, as far as I can tell) and strrchr promises a little more than
it should because we really shouldn't mutate the result in that kind
of scenario. In this case, the result isn't mutated, but it certainly
looks like it could be with the current declaration of slash.
Thanks,
Kyle Evans
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r362333 - in head: contrib/flex contrib/flex/src usr.bin/lex usr.bin/lex/lib
On 20. 6. 23., Kyle Evans wrote:
> On Thu, Jun 18, 2020 at 1:09 PM Jung-uk Kim wrote:
>>
>> Author: jkim
>> Date: Thu Jun 18 18:09:16 2020
>> New Revision: 362333
>> URL: https://svnweb.freebsd.org/changeset/base/362333
>>
>> Log:
>> MFV: r362286
>>
>> Merge flex 2.6.4.
>>
>
> Hi,
>
> I'm looking at getting amd64 world buildable again by gcc6; this seems
> to give it some gas:
>
> /usr/src/contrib/flex/src/main.c: In function 'check_options':
> /usr/src/contrib/flex/src/main.c:347:14: error: assignment discards
> 'const' qualifier from pointer target type
> [-Werror=discarded-qualifiers]
>if ((slash = strrchr(M4, '/')) != NULL) {
>
> The following trivial patch seems to make gcc6 happy again.
>
> diff --git a/contrib/flex/src/main.c b/contrib/flex/src/main.c
> index 711e387b1b5..97e043c6275 100644
> --- a/contrib/flex/src/main.c
> +++ b/contrib/flex/src/main.c
> @@ -342,7 +342,7 @@ void check_options (void)
> /* Setup the filter chain. */
> output_chain = filter_create_int(NULL, filter_tee_header,
> headerfilename);
> if ( !(m4 = getenv("M4"))) {
> - char *slash;
> + const char *slash;
> m4 = M4;
> if ((slash = strrchr(M4, '/')) != NULL) {
> m4 = slash+1;
Hmm... It looks like a false positive and I am little reluctant to
change the vendor code.
Can you just add "-Wno-discarded-qualifiers" or something to
CWARNFLAGS.gcc in share/mk/bsd.sys.mk for some WARNS level?
Jung-uk Kim
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r362333 - in head: contrib/flex contrib/flex/src usr.bin/lex usr.bin/lex/lib
On Thu, Jun 18, 2020 at 1:09 PM Jung-uk Kim wrote:
>
> Author: jkim
> Date: Thu Jun 18 18:09:16 2020
> New Revision: 362333
> URL: https://svnweb.freebsd.org/changeset/base/362333
>
> Log:
> MFV: r362286
>
> Merge flex 2.6.4.
>
Hi,
I'm looking at getting amd64 world buildable again by gcc6; this seems
to give it some gas:
/usr/src/contrib/flex/src/main.c: In function 'check_options':
/usr/src/contrib/flex/src/main.c:347:14: error: assignment discards
'const' qualifier from pointer target type
[-Werror=discarded-qualifiers]
if ((slash = strrchr(M4, '/')) != NULL) {
The following trivial patch seems to make gcc6 happy again.
diff --git a/contrib/flex/src/main.c b/contrib/flex/src/main.c
index 711e387b1b5..97e043c6275 100644
--- a/contrib/flex/src/main.c
+++ b/contrib/flex/src/main.c
@@ -342,7 +342,7 @@ void check_options (void)
/* Setup the filter chain. */
output_chain = filter_create_int(NULL, filter_tee_header, headerfilename);
if ( !(m4 = getenv("M4"))) {
- char *slash;
+ const char *slash;
m4 = M4;
if ((slash = strrchr(M4, '/')) != NULL) {
m4 = slash+1;
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
