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.> > > --- > > > // Test data for ~/.calendar/calendar > > > * bla0...> > This is not obvious from reading the man-page and it might be more > > intuitive, if the identifier was only the word up to the first blank, > > Yes > > > but the code in the calendar program does just strip off leading and > > trailing white-space. It might be too late to change this behavior. > > Hopefully not too late. > Either way, Ameliorations: > - Do a global edit in manual from "cpp" to "pre-processor" > to remove expectation of similarity to cpp. > - Define in manual exactly how the pre-processor handles defines. > > > > I have updated the code in -CURRENT to support #ifdef (MFC in 3 days) > > Nice > > > > and I plan to add supported for nested conditions in -CURRENT > > Nice > > > > (not > > sure whether that should be merged to -STABLE, though). > > Probably yes ? > > > > I could change the #define and #if/ifndef to only consider the first > > following word, but do not plan to do that at this time. > > Would be good if you did, silently swallowing space seperated text > as extended name of a define instead of value of define, is not > intuitive, At least document if you have no time to change it please ? > > Fixing documenting & extanding a pp in calendar could become like > re-inventing the wheel ? As a cpp is in src/ & not ports, can't > calendar use popen(/usr/bin/cpp) & save work ? Looks like there's > enough work to do in main calendar without extra work of a custom > pre processor ? > > Thanks for copy of your reply to Greg Balfour's off list mail, ref > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=205580 > which notes: > "This patch is against 11.4-RELEASE. Note that it requires > the installation of the devel/tradcpp port/package." > > I agree your policy point, FreeBSD can't use a port as dependency > to build calendar, while calendar is still build by src/ world. (& > not just for Free, but Net & Open BSD etc will have similiar views > I presume)Indeed I'd revert back to this.> > I don't know which cpp's from where might have been looked at in the past, > > > Regards, STefan > > Thanks ! > > Cheers, > -- > Julian Stacey, Consultant Sys. Eng. BSD Linux Unix, http://berklix.com/jhs/cv/ > Crash Brexit profits financial speculators in cabinet damaging Britain. > UK stole 3.7 million votes from Brits abroad 700 K in EU http://stolenvotes.ukDiane -- - db at FreeBSD.org db at db.net http://www.db.net/~db
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
Here's another 2 calendar errors, presumably cpp, that manifest in 12.2-STABLE, that 9.2-RELEASE gets right. Man calendar: Empty lines and lines protected by the C commenting syntax (/* ... */) are ignored. --- Input ~/.calendar/calendar friday fish /* * Oct 21 AAA */ friday and chips ---12.2-STABLE output Oct 30* and chips Oct 30 AAA Oct 30* fish Oct 31 AAA ---9.2-RELEASE output Oct 30* and chips Oct 30* fish --- Error 1: Why does it emit AAA ? Error 2: Why twice ? Puzzle: Doesnt happen if you change Oct above to Aug inside the comment. (PS both do a nasty stack unstack, which may look familiar to us programmers, but looks silly to normal peopler, inverting fish & chips) Cheers, -- Julian Stacey, Consultant Sys. Eng. BSD Linux Unix, http://berklix.com/jhs/cv/ Crash Brexit profits financial speculators in cabinet damaging Britain. UK stole 3.7 million votes from Brits abroad 700 K in EU http://stolenvotes.uk