[cfe-dev] Partial Pre-processing Question

Wed Nov 18 08:57:08 PST 2015

On Wed, Nov 18, 2015 at 8:28 AM, Martin J. O'Riordan <
martin.oriordan at movidius.com> wrote:

> Let’s say for example I have:
>
>
>
> #include <stddef.h>
>
> #include “myfile.h”
>
>
>
> int main() {
>
>   foo(NULL);
>
> }
>
>
>
> and “myfile.h” has:
>
>
>
> extern void foo(); // Tentative declaration
>
>
>
> When fully pre-processed this will have ‘<stddef.h>’ and “myfile.h” fully
> expanded.  If in the case my definition of NULL is just ‘0’, then this
> becomes:
>
>
>
> # 1 "myfile.c"
>
> # 1 "<built-in>" 1
>
> # 1 "<built-in>" 3
>
> # 306 "<built-in>" 3
>
> # 1 "<command line>" 1
>
> # 1 "<built-in>" 2
>
> # 1 "myfile.c" 2
>
> # 1 "<*path-to-stdinc*>/stddef.h" 1 3 4
>
> # 51 "<*path-to-stdinc*>/stddef.h" 3 4
>
> typedef int ptrdiff_t;
>
> # 62 "<*path-to-stdinc*>/stddef.h" 3 4
>
> typedef unsigned int size_t;
>
> # 90 "<*path-to-stdinc*>/stddef.h" 3 4
>
> typedef unsigned char wchar_t;
>
> # 118 "<*path-to-stdinc*>/stddef.h" 3 4
>
> # 1 "<*path-to-stdinc*>/__stddef_max_align_t.h" 1 3 4
>
> # 35 "<*path-to-stdinc*>/__stddef_max_align_t.h" 3 4
>
> typedef struct {
>
>   long long __clang_max_align_nonce1
>
>       __attribute__((__aligned__(__alignof__(long long))));
>
>   long double __clang_max_align_nonce2
>
>       __attribute__((__aligned__(__alignof__(long double))));
>
> } max_align_t;
>
> # 119 "<*path-to-stdinc*>/stddef.h" 2 3 4
>
> # 1 "myfile.c" 2
>
>
>
> # 1 "./myfile.h" 1
>
> extern void foo();
>
> # 2 "myfile.c" 2
>
>
>
>
>
> int main() {
>
>   foo(0);
>
> }
>
>
>
> But what I would really like is something like:
>
>
>
> # 1 "myfile.c"
>
> # 1 "<built-in>" 1
>
> # 1 "<built-in>" 3
>
> # 306 "<built-in>" 3
>
> # 1 "<command line>" 1
>
> # 1 "<built-in>" 2
>
> # 1 "myfile.c" 2
>
> #include <stddef.h>
>
> # 1 "myfile.c" 2
>
>
>
> # 1 "./myfile.h" 1
>
> extern void foo();
>
> # 2 "myfile.c" 2
>
>
>
>
>
> int main() {
>
>   foo(NULL);
>
> }
>
>
>
> The example is contrived, but assume that ‘int’ is 32-bit, ‘void*’ is
> 64-bit and the actual definition of ‘void foo()’ takes a pointer
> argument, then the original code in ‘<stddef.h>’ is wrong, and while
> debugging I realise “hey, I should have defined NULL to be ‘((void*)0)’”.
> If my test-case contained all of the user code pre-processed but not the
> system includes, then I can quickly evaluate the fix.
>
>
>
> This is a really trivialised example, in practice bug reports are usually
> much larger.  And this example assumes I have a bug in the definition of
> NULL, which is unlikely, but in the real-world I may be updating the set
> of headers for the system includes from one version to a newer version, or
> I might have decided that I would prefer to distribute ‘uClibc’ headers
> instead of ‘newlib’ headers, but I want to keep my test cases valid in
> the context of the revised system header files.
>
>
>
> Having an option to allow this kind of partial pre-processing could be
> very useful.  I can write scripts which can collapse the expanded header
> back into the ‘#include <stddef.h>’ from the normal pre-processed file,
> but I can’t undo the expansion of the macros it contains such as NULL in
> this case.  I could also write an external tool to do this, but it would be
> hard to ensure that it accurately mimics the search paths for CLang and
> there is plenty of opportunity for error and divergence over time.  And
> integrated option would not have this problem.
>
>
>
> I’m not proposing the addition of such an option, but was curious if CLang
> already had such a feature that I had missed when browsing the huge number
> of options, especially since some options have no help text associated with
> them and are invisible to either ‘--help’ or ‘--help-hidden’.
>

Right - we don't. I don't think we'd object to having one, we just haven't
had a need for one so no one's done the work.

- Dave

>
>
> Thanks,
>
>
>
>             MartinO - Movidius Ltd.
>
>
>
> *From:* David Blaikie [mailto:dblaikie at gmail.com]
> *Sent:* 18 November 2015 15:49
> *To:* Martin J. O'Riordan <martin.oriordan at movidius.com>
> *Cc:* Clang Dev <cfe-dev at lists.llvm.org>
> *Subject:* Re: [cfe-dev] Partial Pre-processing Question
>
>
>
>
>
>
>
> On Wed, Nov 18, 2015 at 6:48 AM, Martin J. O'Riordan via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
> I am wondering if there is some hidden option or mechanism in CLang that I
> can use to pre-process like ‘-E’ or ‘-frewrite-includes’, but which does
> not expand the headers from the system include directories?
>
>
>
> There are often times when I would like this type of capability, so that I
> can create test-cases for reported bug, but have them remain valid with
> future revisions of the compiler and its supporting headers and libraries.
> It is not uncommon for a new version of a system header (ISO C, ISO C++, or
> our own extended headers) to have changes that are not 100% compatible with
> the results of the expanded result of an older version.
>
>
>
> I'm not quite following what you've said here /\ - if the test case has
> fully preprocessed code then it won't have any system headers to conflict
> with updated system headers, no? It'll be standalone. I've certainly found
> these sort of test cases to be fairly robust - but I usually do the
> reduction (as Yaron was mentioning) up-front, so I may not've run into the
> situations you're describing. Given how much the compiler has to be robust
> to user code backwards compatibility, I'd be surprised it it's often the
> case that a system header used a feature that the compiler soon became
> incapable of processing.
>
>
>
>
>
> The headers belonging to the programmer and their source need to be
> expanded, but I would like to retain the unexpanded system headers, and in
> particular not expand the macros defined in a system header, and leave the
> system headers as ‘#include <*sysheadername*>’.
>
>
>
> Thanks,
>
>
>
>             MartinO - Movidius Ltd.
>
>
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20151118/a0dc329f/attachment.html>