Re: pkg/58816: sysutils/xfm: fix startup issue caused by incomplete tradcpp macro expansion

["David Holland via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR pkg/58816; it has been noted by GNATS.

From: David Holland <dholland-pbugs%netbsd.org@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: pkg/58816: sysutils/xfm: fix startup issue caused by incomplete
 tradcpp macro expansion
Date: Thu, 7 Nov 2024 18:38:00 +0000

 On Thu, Nov 07, 2024 at 08:40:00AM +0000, rvp%SDF.ORG@localhost wrote:
  >  #else
  >  Xfm*TextField.baseTranslations:#override\n\
  > -HIST_TRANSLATION(FocusSet(), ) \
  > + HIST_TRANSLATION(FocusSet(), ) \
  >  Shift	<Key>Tab:FocusTraverse(b)\n\
  >  	<Key>Tab:FocusTraverse()\n\
 
 Did this ever work in _any_ cpp? Should tradcpp not splice lines when
 not in a string constant or preprocessor directive? Or should it
 insert a space in that case?
 
 My 1st ed K&R mentions escaped newlines in the context of string
 constants and #define, but apparently not otherwise.
 
 gcc -traditional does what tradcpp does but that doesn't prove
 anything.
 
 Does the code in xfm that reads the results do its own line splicing?
 
  > (Really, this should be fixed properly by using a general-purpose
  > macro processor like m4(1) rather than abusing tradcpp(1) on files
  > which are just _not_ C source code!)
 
 Yeah, well, most of the reason tradcpp exists is to support legacy
 uses like this.
 
 -- 
 David A. Holland
 dholland%netbsd.org@localhost