Re: Parsing partial sentences

On Thu, 20 Apr 2017 16:14:43 +0200, Hans-Peter Diettrich
<DrDiettrich1@netscape.net> 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

Return to the comp.compilers page.
Search the comp.compilers archives again.