Re: svn commit: r367103 - head/usr.bin/calendar
On Wed, Oct 28, 2020 at 9:09 AM Stefan Esser wrote: > Am 28.10.20 um 14:34 schrieb Kyle Evans: > > On Wed, Oct 28, 2020 at 8:24 AM Stefan Esser wrote: > >> I'm thinking about support for nested conditionals and #else in > >> calendar files, but I'm not sure about the possibility to MFC > >> such a change and I do not want to invite users to create calendar > >> files that work in -CURRENT but not in -STABLE. > > > > Unsolicited $0.02: Do whatever you feel comfortable with. It's up to > > people trying to use the new/advanced features to make sure it's > > compatible with the calendar(1) that *they* are using, and I'm having > > a hard time imagining folks using deploying additional calendar data > > in ports outside of deskutils/calendar-data which you can curate for > > stuff like that. > > I only read your reply after committing the change that allows for > recursion. > > The issue reported by Julian H. Stacey on the freebsd-stable list > made me check for the code that implements these conditions, and > I noticed that there was no #ifdef (which he had tried to use), > but it was trivial to implement. > > The man-page mentions that a restricted subset of CPP directives > is supported, and ISTR that an earlier version of the calendar > program actually forked CPP to pre-process the data files. > > This approach required a "traditional" CPP that ignored the content > of the non-directives being processed, which is no longer available. > > In a way I'm removing some of the limitations that resulted from > the switch to an internal parser for the conditions. > > If there is consensus not to introduce any new features into our > calendar program, then I'm going to revert these changes. > > I had planned to give time for a discussion about a possible > merge to -STABLE. > > I have already created a port of the calendar program as > deskutils/calendar and was planning to upgrade the port to include > these changes in -CURRENT. > > The port could be used to provide release users with these features, > if they consider them useful. > > Since the changes are fully compatible with old data files, I do > not think that a MFC was a violation of POLA. > > We do now have the calendar-data port for use in -CURRENT and it > could be used to distribute calendar files that use the new features. > > Since old calendar programs will not look into the port's data file > directory, they will continue to operate on files in the base > system. > > If the calendar program from a port is used, it will support the > features of this version and that all calendar files that take > advantage of them. > > We might hide these new features by removal from the man-page or we > could discourage their use by declaring them unportable extensions. > Honestly, I think MFCing what we've committed to date and requiring calendar-data is fine. POLA isn't violated because you have to install a new port, especially when the program that 'fails' includes that in its failure message. It's the least bad solution, and calendar isn't a critical part of the infrastructure where we have to make herculean efforts to hide any changes. It beats the old files rotting in stable. Warner ___ 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: r367103 - head/usr.bin/calendar
Am 28.10.20 um 14:34 schrieb Kyle Evans: On Wed, Oct 28, 2020 at 8:24 AM Stefan Esser wrote: I'm thinking about support for nested conditionals and #else in calendar files, but I'm not sure about the possibility to MFC such a change and I do not want to invite users to create calendar files that work in -CURRENT but not in -STABLE. Unsolicited $0.02: Do whatever you feel comfortable with. It's up to people trying to use the new/advanced features to make sure it's compatible with the calendar(1) that *they* are using, and I'm having a hard time imagining folks using deploying additional calendar data in ports outside of deskutils/calendar-data which you can curate for stuff like that. I only read your reply after committing the change that allows for recursion. The issue reported by Julian H. Stacey on the freebsd-stable list made me check for the code that implements these conditions, and I noticed that there was no #ifdef (which he had tried to use), but it was trivial to implement. The man-page mentions that a restricted subset of CPP directives is supported, and ISTR that an earlier version of the calendar program actually forked CPP to pre-process the data files. This approach required a "traditional" CPP that ignored the content of the non-directives being processed, which is no longer available. In a way I'm removing some of the limitations that resulted from the switch to an internal parser for the conditions. If there is consensus not to introduce any new features into our calendar program, then I'm going to revert these changes. I had planned to give time for a discussion about a possible merge to -STABLE. I have already created a port of the calendar program as deskutils/calendar and was planning to upgrade the port to include these changes in -CURRENT. The port could be used to provide release users with these features, if they consider them useful. Since the changes are fully compatible with old data files, I do not think that a MFC was a violation of POLA. We do now have the calendar-data port for use in -CURRENT and it could be used to distribute calendar files that use the new features. Since old calendar programs will not look into the port's data file directory, they will continue to operate on files in the base system. If the calendar program from a port is used, it will support the features of this version and that all calendar files that take advantage of them. We might hide these new features by removal from the man-page or we could discourage their use by declaring them unportable extensions. Regards, STefan OpenPGP_signature Description: OpenPGP digital signature
Re: svn commit: r367103 - head/usr.bin/calendar
On Wed, Oct 28, 2020 at 8:24 AM Stefan Esser wrote:
>
> Am 28.10.20 um 14:12 schrieb Kyle Evans:>> Modified:
> head/usr.bin/calendar/io.c
> >> ==
> >> --- head/usr.bin/calendar/io.c Wed Oct 28 11:54:09 2020(r367102)
> >> +++ head/usr.bin/calendar/io.c Wed Oct 28 13:06:39 2020(r367103)
> >> @@ -212,6 +212,21 @@ token(char *line, FILE *out, bool *skip)
> >> return (T_OK);
> >> }
> >>
> >> + if (strncmp(line, "ifdef", 5) == 0) {
> >> + walk = line + 6;
> >> + trimlr();
> >> +
> >
> > I think you wanted to step walk forward 5 instead of 6 here
>
> Thank you for spotting this bug ...
>
> It did not show up in my tests, since there generally is a blank
> after the token, but I'll fix this immediately since I want to
> MFC that change.
>
> Nobody should be affected since #ifdef was officially unsupported
> before this change ...
>
+1, thanks!
> I'm thinking about support for nested conditionals and #else in
> calendar files, but I'm not sure about the possibility to MFC
> such a change and I do not want to invite users to create calendar
> files that work in -CURRENT but not in -STABLE.
Unsolicited $0.02: Do whatever you feel comfortable with. It's up to
people trying to use the new/advanced features to make sure it's
compatible with the calendar(1) that *they* are using, and I'm having
a hard time imagining folks using deploying additional calendar data
in ports outside of deskutils/calendar-data which you can curate for
stuff like that.
___
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: r367103 - head/usr.bin/calendar
Am 28.10.20 um 14:12 schrieb Kyle Evans:>> Modified:
head/usr.bin/calendar/io.c
==
--- head/usr.bin/calendar/io.c Wed Oct 28 11:54:09 2020(r367102)
+++ head/usr.bin/calendar/io.c Wed Oct 28 13:06:39 2020(r367103)
@@ -212,6 +212,21 @@ token(char *line, FILE *out, bool *skip)
return (T_OK);
}
+ if (strncmp(line, "ifdef", 5) == 0) {
+ walk = line + 6;
+ trimlr();
+
I think you wanted to step walk forward 5 instead of 6 here
Thank you for spotting this bug ...
It did not show up in my tests, since there generally is a blank
after the token, but I'll fix this immediately since I want to
MFC that change.
Nobody should be affected since #ifdef was officially unsupported
before this change ...
I'm thinking about support for nested conditionals and #else in
calendar files, but I'm not sure about the possibility to MFC
such a change and I do not want to invite users to create calendar
files that work in -CURRENT but not in -STABLE.
___
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: r367103 - head/usr.bin/calendar
On Wed, Oct 28, 2020 at 8:06 AM Stefan Eßer wrote:
>
> Author: se
> Date: Wed Oct 28 13:06:39 2020
> New Revision: 367103
> URL: https://svnweb.freebsd.org/changeset/base/367103
>
> Log:
> Fix parsing of #ifdef in calendar files
>
> There was code to process an #ifndef tokens, but none for #ifdef.
> The #ifdef token was mentioned as unsupported in the BUGS section,
> but no reason was given and I do not see why it should stay omitted.
>
> Misleading information in The BUGS section of the man-page regarding
> the maximum number of #define and #include statements supported has
> been removed. These limits might have applied to a prior version of
> this program, but do not seem to apply to the current implementation.
>
> I have not tried to test for the existence of the limits, but the
> include file processing just recursively calls the parser (without
> counting the recursion depth) and the stringlist functions do not
> impose a limit on the number of entries.
>
> Reported by: j...@berklix.com
> MFC after:3 days
>
> Modified:
> head/usr.bin/calendar/calendar.1
> head/usr.bin/calendar/io.c
>
> Modified: head/usr.bin/calendar/calendar.1
> ==
> --- head/usr.bin/calendar/calendar.1Wed Oct 28 11:54:09 2020
> (r367102)
> +++ head/usr.bin/calendar/calendar.1Wed Oct 28 13:06:39 2020
> (r367103)
> @@ -346,11 +346,9 @@ double-check the start and end time of solar and lunar
> .Sh BUGS
> The
> .Nm
> -internal cpp does not correctly do #ifndef and will discard the rest
> -of the file if a #ifndef is triggered.
> -It also has a maximum of 50 include file and/or 100 #defines
> -and only recognises #include, #define and
> -#ifndef.
> +internal cpp does not support nested conditions and will continue
> +parsing of the input file on the next #endif even in nested contexts.
> +It does only recognise #include, #define, #ifdef and #ifndef.
> .Pp
> There is no possibility to properly specify the local position
> needed for solar and lunar calculations.
>
> Modified: head/usr.bin/calendar/io.c
> ==
> --- head/usr.bin/calendar/io.c Wed Oct 28 11:54:09 2020(r367102)
> +++ head/usr.bin/calendar/io.c Wed Oct 28 13:06:39 2020(r367103)
> @@ -212,6 +212,21 @@ token(char *line, FILE *out, bool *skip)
> return (T_OK);
> }
>
> + if (strncmp(line, "ifdef", 5) == 0) {
> + walk = line + 6;
> + trimlr();
> +
I think you wanted to step walk forward 5 instead of 6 here
___
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"
svn commit: r367103 - head/usr.bin/calendar
Author: se
Date: Wed Oct 28 13:06:39 2020
New Revision: 367103
URL: https://svnweb.freebsd.org/changeset/base/367103
Log:
Fix parsing of #ifdef in calendar files
There was code to process an #ifndef tokens, but none for #ifdef.
The #ifdef token was mentioned as unsupported in the BUGS section,
but no reason was given and I do not see why it should stay omitted.
Misleading information in The BUGS section of the man-page regarding
the maximum number of #define and #include statements supported has
been removed. These limits might have applied to a prior version of
this program, but do not seem to apply to the current implementation.
I have not tried to test for the existence of the limits, but the
include file processing just recursively calls the parser (without
counting the recursion depth) and the stringlist functions do not
impose a limit on the number of entries.
Reported by: j...@berklix.com
MFC after:3 days
Modified:
head/usr.bin/calendar/calendar.1
head/usr.bin/calendar/io.c
Modified: head/usr.bin/calendar/calendar.1
==
--- head/usr.bin/calendar/calendar.1Wed Oct 28 11:54:09 2020
(r367102)
+++ head/usr.bin/calendar/calendar.1Wed Oct 28 13:06:39 2020
(r367103)
@@ -346,11 +346,9 @@ double-check the start and end time of solar and lunar
.Sh BUGS
The
.Nm
-internal cpp does not correctly do #ifndef and will discard the rest
-of the file if a #ifndef is triggered.
-It also has a maximum of 50 include file and/or 100 #defines
-and only recognises #include, #define and
-#ifndef.
+internal cpp does not support nested conditions and will continue
+parsing of the input file on the next #endif even in nested contexts.
+It does only recognise #include, #define, #ifdef and #ifndef.
.Pp
There is no possibility to properly specify the local position
needed for solar and lunar calculations.
Modified: head/usr.bin/calendar/io.c
==
--- head/usr.bin/calendar/io.c Wed Oct 28 11:54:09 2020(r367102)
+++ head/usr.bin/calendar/io.c Wed Oct 28 13:06:39 2020(r367103)
@@ -212,6 +212,21 @@ token(char *line, FILE *out, bool *skip)
return (T_OK);
}
+ if (strncmp(line, "ifdef", 5) == 0) {
+ walk = line + 6;
+ trimlr();
+
+ if (*walk == '\0') {
+ warnx("Expecting arguments after #ifdef");
+ return (T_ERR);
+ }
+
+ if (definitions == NULL || sl_find(definitions, walk) == NULL)
+ *skip = true;
+
+ return (T_OK);
+ }
+
if (strncmp(line, "ifndef", 6) == 0) {
walk = line + 6;
trimlr();
___
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"
