Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.compilers > #1861

Re: Parsing partial sentences

Show all headers | View raw

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

Back to comp.compilers | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

Re: Parsing partial sentences Martin Ward <martin@gkc.org.uk> - 2017-04-11 10:30 +0100
  Re: Parsing partial sentences Hans-Peter Diettrich <DrDiettrich1@netscape.net> - 2017-04-20 16:14 +0200
    Re: Parsing partial sentences George Neuner <gneuner2@comcast.net> - 2017-04-21 07:41 -0400

csiph-web