From owner-freebsd-stable@freebsd.org Thu Oct 29 13:04:14 2020 Return-Path: Delivered-To: freebsd-stable@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 75881450983 for ; Thu, 29 Oct 2020 13:04:14 +0000 (UTC) (envelope-from se@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CMQct2YQ5z3Ssq; Thu, 29 Oct 2020 13:04:14 +0000 (UTC) (envelope-from se@freebsd.org) Received: from Stefans-MacBook-Pro-449.fritz.box (p200300cd5f0bbc0018d60868c7568750.dip0.t-ipconnect.de [IPv6:2003:cd:5f0b:bc00:18d6:868:c756:8750]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: se/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 9A6DF233EA; Thu, 29 Oct 2020 13:04:13 +0000 (UTC) (envelope-from se@freebsd.org) To: Diane Bruce Cc: freebsd-stable , Greg Balfour , "Julian H. Stacey" References: <3ec7872e-c264-e05f-cc3b-bbd2f421a97f@freebsd.org> <202010290029.09T0Td4m004819@fire.js.berklix.net> <20201029120702.GA44939@night.db.net> From: Stefan Esser Subject: Re: calendar (1) - patch to correct error description Message-ID: Date: Thu, 29 Oct 2020 14:04:12 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 MIME-Version: 1.0 In-Reply-To: <20201029120702.GA44939@night.db.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2020 13:04:14 -0000 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