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

Groups > comp.lang.c > #162965

Re: Preprocessor <-> compiler

Show all headers | View raw

On 03/10/2021 18:55, Thiago Adams wrote:
> On Sunday, October 3, 2021 at 1:24:32 PM UTC-3, Bart wrote:
>> On 03/10/2021 14:47, Thiago Adams wrote:
>>> I have implemented the preprocessor 'on demand' in my c compiler
>>> front end and I was kind of regretting it because the code become
>>> much more complex compared with preprocess in everything in
>>> advance and separately.
>>>
>>> I was planning to change it to simplify the code but I realized that
>>> this makes it possible the integration with the compiler.
>>>
>>> My parser asks 'give me the next token’ for a preprocessor state machine
>>> and it returns only tokens already preprocessed.
>>>
>>> For instance:
>>>
>>> void F() {
>>> char ch =
>>> #if 0
>>> 'a'
>>> #else
>>> 'b'
>>> #endif
>>> ;
>>> }
>>> after '=' the parser pulls the next token and the preprocessor move
>>> its internal state consuming preprocessor tokens until it finds 'b' returning it’.
>>>
>>> It asks again and the preprocessor returns ';' changing it internal state
>>> after consuming (but not returning) #endif.
>>>
>>> The internal state (#include, #ifdefs, #endif) are kept in stacks.
>>> Macro expansion is on demand as well.
>>>
>>> This preprocessor state machine has an advantage.
>>>
>>> It still happens before the compiler phase but it has the compiler
>>> context and could access it.
>>>
>>> That means that #if could ask anything for the compiler like sizeof
>>> of the variable on scope, or if a variable/function exists etc.
>>>
>>> Considering this.. I was wondering if the C language could change its
>>> concepts to allow this in the future.
>>>
>>> When we read code, we don't do the preprocessor "separated" in
>>> your mind we do it "on demand" as well.
>>>
>>> The invention of _Static_assert for instance would not be necessary
>>>
>>> Instead of
>>>
>>> _Static_assert( sizeof(x) == sizeof(int), "must be sizeof int");
>>>
>>> we could just write:
>>>
>>> #if sizeof(x) != sizeof(int)
>> This requires that the lexer knows about symbol tables, scopes and user
>> types, and that operations such as building those types and user types
>> and the name resolution required to figure out which x is intended, are
>> all done while parsing.
> 
> The lexer ask questions direct to the compiler and the compiler has
> all the tables.
> 
> compiler says : "give me the next token, in case you need ask me".
> 
>   
>> In other words, that part needs to be single pass, which puts a
>> constraint on the compiler.
> 
> Yes, good point.
>   
>> Also, what happens when someone /only/ wants to do a preprocessing pass?
>> Then 'sizeof(x)' is meaningless.
> 
> Would be an error.
> 
>> Would you have to remove that ability from the language? I think more
>> than a few compilers depend on a third party preprocessors, and various
>> language processing tools may depend on it too.
>>
>> So it's an unlikely retrofit for C.
> 
> I think all the preprocessor is already very mixed with the compiler
> I have several samples.
> 
> -C++ added digit separators and they had to change pp-number (preprocessor
> definition of number). You cannot use an external preprocessor that is
> not synchronized.

> -#pragma are used to control the compiler. what happen using an external preprocessor
>    will just remove the content?

If an implementation doesn't understand what follows #pragma, then it 
will just ignore it.

When it does understand it, it will just define some input, or set some 
state, for the rest of the compiler to make use of. I don't think it 
needs input from the compiler, or from later stages of it, unless you 
have some examples?

When doing preprocessing only, then #pragma lines are passed unchanged. 
(My compiler consumes them, so it's a bug, sort of. But there are worse 
ones...)

> __func__ is already funny.

__func__ doesn't really belong in the processor. And actually it's a 
predefined identifier, not a predefined macro.

If you try and use __func__ with -E, then you just get __func__. Which 
means that when you try and compile that preprocessed output, /then/ it 
will be expanded to the function name, if it's inside a function.

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

Thread

Preprocessor <-> compiler Thiago Adams <thiago.adams@gmail.com> - 2021-10-03 06:47 -0700
  Re: Preprocessor <-> compiler Thiago Adams <thiago.adams@gmail.com> - 2021-10-03 08:38 -0700
  Re: Preprocessor <-> compiler Bart <bc@freeuk.com> - 2021-10-03 17:24 +0100
    Re: Preprocessor <-> compiler Thiago Adams <thiago.adams@gmail.com> - 2021-10-03 10:55 -0700
      Re: Preprocessor <-> compiler Bart <bc@freeuk.com> - 2021-10-03 19:41 +0100
        Re: Preprocessor <-> compiler Thiago Adams <thiago.adams@gmail.com> - 2021-10-03 12:16 -0700
          Re: Preprocessor <-> compiler Bart <bc@freeuk.com> - 2021-10-03 20:28 +0100
            Re: Preprocessor <-> compiler Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2021-10-03 14:12 -0700
  Re: Preprocessor <-> compiler Andrey Tarasevich <andreytarasevich@hotmail.com> - 2021-10-06 08:41 -0700
    Re: Preprocessor <-> compiler Thiago Adams <thiago.adams@gmail.com> - 2021-10-06 10:56 -0700

csiph-web