Bug 52565
| Summary: | Bogus printf macro in /usr/include/bits/stdio.h | ||
|---|---|---|---|
| Product: | [Retired] Red Hat Public Beta | Reporter: | jay |
| Component: | glibc | Assignee: | Jakub Jelinek <jakub> |
| Status: | CLOSED RAWHIDE | QA Contact: | |
| Severity: | high | Docs Contact: | |
| Priority: | medium | ||
| Version: | roswell | ||
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2001-08-25 08:57:31 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
otoh this is really the fault of glibc rather than gcc3... The offending macro is # if __GNUC_PREREQ (2,97) # define printf(fmt, args...) fprintf (stdout, fmt, ##args) # endif This macro was removed in glibc-2.2.4-1 (as gcc 3.0 can optimize printf internally too). |
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.2-2 i586; en-US; 0.7) Gecko/20010316 Description of problem: When compiling programs with optimisation, GCC defines the __USE_EXTERN_INLINES macro. The /usr/include/bits/stdio.h header #defines a macro for printf in this case. However, while this is probably fine for C, it breaks C++ programs where objects can have member functions called printf. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: Compile the following program with "g++3 -O2" #include <stdio.h> struct foo { int val; foo() : val(0) { } int printf(const char *fmt, ...) { return 0; } }; int main (int argc, char *argv[]) { return 0; } This will fail because the "printf(.." gets turned into "fprintf(stdout,..." which is not valid for a function defintion. Note that becuase of the fact that the macro is only defined if __USE_EXTERN_INLINES is defined by the compiler, this bug will NOT occur if you compile without optimisation. It also goes away if you change the name of the member function (unfortunately I have about 1000 of them). Actual Results: testit2.cc:7: parse error before `char' Expected Results: Program should compile without error. Additional info: Defining that macro wasn't a good idea. I've marked this a severity: high becuase this makes valid programs fail to compile, and it is insane to promote the software to full-release knowing that it will break working software.