Am 29.10.20 um 13:07 schrieb Diane Bruce:
On Thu, Oct 29, 2020 at 01:29:39AM +0100, Julian H. Stacey wrote:
Hi Stefan
Am 28.10.20 um 13:02 schrieb Julian H. Stacey:
man calendar states:
"The calendar internal cpp does not correctly do #ifndef and will discard
the rest of the file if a #ifndef is triggered."
That is wrong, as proved by test file:
If I was asked about this I'd suggest ripping out the internal cpp
and switching back to an external cpp IFF calendar is all in ports.
The idea when the original very hurried hack was done was to remove
more from base. No longer a problem if using ports.
This is a possibility, but there exists no plan to remove the calendar
program from base, currently.
I have created the deskutils/calendar port for RELEASE users that want
to take advantage of recent changes to the calendar program, but this
port exists for only this particular purpose.
Piping of the calendar files through CPP leads to other problems, e.g.
how to feed error messages from CPP back to the calendar program in
a sensible way.
I have made the semantics of #define and #if(n)def more similar to
that of a CPP, but there still is one major difference:
#define COND true
#ifdef COND
will not get the result you might expect, since "COND true" has been
defined and
#ifdef COND true
will evaluate to true.
This is easily changed (I'd use only the first word in #define and
reject #ifdef if followed by more than one word), but while being
nearer to what CPP would give, it deviates from many years of
practice in FreeBSD and might not be allowed to be MFCed.
And different semantics in -CURRENT vs. -STABLE are even less
acceptable, IMHO.
But I'd like to apply such a patch, anyway.
There are other changes to the semantics that are possible, e.g.
to check that #ifdef/#endif are balanced or that there is no #else
outside an #ifdef/#endif range.
Implementing such checks is quite simple, given the structure of
the code, but I'm not sure that this is required or even a good
idea, since it might break current calendar data files that are
not really well-formed ...
Best regards, STefan
_______________________________________________
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
