[LLVMbugs] [Bug 22031] New: preprocessor incorrectly replaces "macro defined as nothing" with # of spaces in name

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=22031

            Bug ID: 22031
           Summary: preprocessor incorrectly replaces "macro defined as
                    nothing" with # of spaces in name
           Product: clang
           Version: 3.4
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: dgoldman at ehdp.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Here is my version:

$ clang --version
Ubuntu clang version 3.4-1ubuntu3 (based on LLVM 3.4)
Target: x86_64-pc-linux-gnu
Thread model: posix

Here is example showing the alleged bug:

$ cat clang-2.h
#define MACRO_NAME
MACRO_NAME Y

$ clang -P -E clang-2.h

           Y

$ gcc -P -E clang-2.h
 Y

When MACRO_NAME is defined as "nothing", clang replaces with same # of spaces
as the macro name length. Instead, it should replace with one space (like gcc),
whether MACRO_NAME, MACRO, or whatever macro name.

I know the C compiler will not care about the extra spaces. But in support of
getting this called a bug and fixing it, I offer:

1) I (and others) use cpp to process other files where the extra spaces DO
matter. So this is a practical matter, not a theoretical quibble. For example,
I use cpp to produce input files to nroff, and spaces matter in that situation.
I only went to the effort of filing this bug report because the different clang
behavior does matter to me (and others).

2) I do not have the option to use a different preprocessor, such as m4 or the
few others available. I have researched and tested them a lot. I must use cpp.
Specifically, I have C header files used to compile C code, and also used to
produce html and text help files.

3) The clang behavior is illogical. It makes no sense to replace "macro defined
as nothing" with the same number of spaces as the macro name. What's the
benefit or rationale? I see none.

4) clang differs from gcc in this case. What reason for the difference? I see
none. And the difference seems to go against the idea that clang can be a
drop-in replacement for gcc.

5) This bug seems easily fixed (assuming familiarity with LLVM source code,
which I am not). It must take more effort (and code) to replace "macro defined
as nothing" with same number of spaces as macro name length. It must be simpler
to always replace with one space. So (besides being more correct) fixing the
bug would seem to simplify the LLVM source code.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20141226/e107225b/attachment.html>