Path: csiph.com!weretis.net!feeder6.news.weretis.net!feeder.usenetexpress.com!feeder1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!news.iecc.com!.POSTED.news.iecc.com!nerds-end From: George Neuner Newsgroups: comp.compilers Subject: Re: Parsing partial sentences Date: Fri, 21 Apr 2017 07:41:10 -0400 Organization: A noiseless patient Spider Lines: 80 Sender: news@iecc.com Approved: comp.compilers@iecc.com Message-ID: <17-04-022@comp.compilers> References: <7fc5c7a1-97c5-2afb-ef80-6ef5de2d54ca@gkc.org.uk> <17-04-011@comp.compilers> <17-04-021@comp.compilers> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit Injection-Info: miucha.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="89198"; mail-complaints-to="abuse@iecc.com" Keywords: parse Posted-Date: 23 Apr 2017 12:54:05 EDT X-submission-address: compilers@iecc.com X-moderator-address: compilers-request@iecc.com X-FAQ-and-archives: http://compilers.iecc.com Xref: csiph.com comp.compilers:1861 On Thu, 20 Apr 2017 16:14:43 +0200, Hans-Peter Diettrich wrote: >After thinking more about macro expansion, interpretation of the macro >text should occur only when a macro is actually used, so that all >referenced identifiers (other macros, parameters, variables, functions) >are known to the parser/compiler. At that point the returned >non-terminal from the expanded macro can be used immediately to >determine a possible macro conversion. > >Some attributes should be added to the parse tree, so that it will be >possible to determine the macro name for every token, if it results from >a macro expansion, and the kind, type and scope of all used identifiers. >As long as only literal constants occur in the parse tree, the macro can >be converted into a named constant[1]. If identifiers occur as well, >more checks are required to reject e.g. identifiers of non-global scope, >before the macro can be converted into a function[2]. So far, so good. Actually converting "function" macros into functions [where possible] should lead to improved maintenance. However, in the past I have run into some bizarre macro systems where some macros create data structures for other macros to manipulate. I'm just guessing as I don't have an example handy - but considering such entwined macros independently, I could see manipulation macros being rejected by your translator for appearing to reference "identifiers of non-global scope". >If all tests are passed, the macro equivalent can be constructed and >stored, for later use. If such an equivalent has already been stored, >the new construct has to be compared with that first construct, to sort >out possible variations due to macro redefinition or varying macro >argument types. It may be possible to handle varying argument types by a >transformation into generic functions, or by type expansion. > >Provisions also are required (and already implemented) to prevent >duplicate parsing of properly guarded header files, which otherwise >could confuse the automatism about preceding expansions of macros. > >Did I miss something? Some actual things done with C macros. http://stackoverflow.com/questions/652788/what-is-the-worst-real-world-macros-pre-processor-abuse-youve-ever-come-across http://jhnet.co.uk/articles/cpp_magic https://github.com/pfultz2/Cloak/wiki/C-Preprocessor-tricks,-tips,-and-idioms https://natecraun.net/articles/struct-iteration-through-abuse-of-the-c-preprocessor.html > Martin Ward said: > >> However, in practice it depends on the purpose of your C to Pascal >> convertor. If it is to be a general purpose tool which has to be >> able to handle any C source code that anyone throws at it, >> then you are stuck. > >See above, my convertor only accepts valid C code. In so far the user >can throw any valid C source file at it. It's only required that the >original compiler and its libraries are made known to the convertor, so >that all compiler-predefined macros are known, and all #included header >files are available for parsing. Seemingly non-sensical macros can lead to valid C code. In one stackoverflow example they led to valid Java. >> An intermediate approach might be to keep all the macros >> which look straightforward and fall back on expanding macros >> which do weird things with the syntax. > >That's the current implementation, which does not yet handle translated >#defines at all. George