Bug 496423 - something maybe busted in stdlib.h?
Summary: something maybe busted in stdlib.h?
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: glibc
Version: rawhide
Hardware: x86_64
OS: Linux
low
medium
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-04-19 00:43 UTC by Tom Horsley
Modified: 2009-04-23 10:54 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-04-23 10:06:42 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Buffer.cpp run through g++ -E (698.19 KB, text/plain)
2009-04-19 01:13 UTC, Tom Horsley
no flags Details
Buffer.cpp run through g++ -E -dD (774.07 KB, text/plain)
2009-04-22 23:37 UTC, Tom Horsley
no flags Details

Description Tom Horsley 2009-04-19 00:43:48 UTC
Description of problem:

Trying to compile truecrypt on fedora 11, I get this:

Compiling Buffer.cpp
In file included from StringConverter.h:12,
                 from SerializerFactory.h:14,
                 from Serializable.h:16,
                 from Exception.h:14,
                 from Buffer.cpp:10:
/usr/include/stdlib.h:351: error: expected ‘;’ before ‘*’ token
/usr/include/stdlib.h:352: error: expected ‘;’ before ‘*’ token
/usr/include/stdlib.h:353: error: expected ‘;’ before ‘*’ token
/usr/include/stdlib.h:357: error: expected ‘;’ before ‘*’ token
/usr/include/stdlib.h:361: error: ‘int32_t’ has not been declared

I didn't have this problem on fedora 10, but I haven't yet analyzed
it enough to know if the source code is doing something weird or the
stdlib.h header is really busted.

Version-Release number of selected component (if applicable):
glibc-headers-2.9.90-16.x86_64
glibc-2.9.90-16.x86_64

How reproducible:
Every time I try to compile this code.

Steps to Reproduce:
1.way too complex to describe. This is version 5.0 of the truecrypt
source with some local patches applied.
2.
3.
  
Actual results:
error above

Expected results:
no compile problems

Additional info:

Comment 1 Tom Horsley 2009-04-19 01:13:51 UTC
Created attachment 340196 [details]
Buffer.cpp run through g++ -E

I'm not sure what the heck this code is doing. It appears to maybe be defining
int32 in terms of int32_t and vice-versa, but with some namespaces involved as well. I'm willing to call it a truecrypt source bug, but it is still true that
the same source compiles OK in fedora 10 (or did a while back, I suppose
recent updates may have busted it there as well).

I guess I need to hack the source even more to reliably compile.

Comment 2 Tom Horsley 2009-04-19 01:15:21 UTC
Here's the command line used by the Makefile to compile this. There
are lots of suspicous -D options as well (this is the version I modified
to use -E instead of -c):

g++ -E -MMD -I/zooty/build/truecrypt-5.0-source -I/zooty/build/truecrypt-5.0-source/Crypto -DBOOL=int -DFALSE=0 -DTRUE=1 -D__int8=char -D__int16=short -D__int32=int '-D__int64=long long'   -O2 -fno-strict-aliasing   -DTC_UNIX -DTC_LINUX -fdata-sections -ffunction-sections  -Wall -Wno-sign-compare -Wno-unused-parameter Buffer.cpp > Buffer.e

Comment 3 Jakub Jelinek 2009-04-22 09:36:36 UTC
Can you please add -dD to the options, so that macros can be seen in the preprocessed source as well?

Comment 4 Tom Horsley 2009-04-22 23:37:16 UTC
Created attachment 340850 [details]
Buffer.cpp run through g++ -E -dD

OK, here's the same file with -dD added to the command line.

I did discover a way to get this to work: After I unpack and patch the source,
I added a little script that runs through all the .cpp files and just
sticks:

#include <stdlib.h>

at the beginning of the file so it is included before all other local includes.

Everything seems to compile perfectly fine if I do that, and it is no worse
than most of the other hacks I'm doing to the source :-).

Comment 5 Jakub Jelinek 2009-04-23 10:06:42 UTC
That's clearly a truecrypt bug.
See how it does:
namespace TrueCrypt
{
#include <inttypes.h>
...
}
...
#include <stdlib.h>

That's invalid, standard headers may be only included outside of any external declaration or definition, so can't be included from within a namespace definition, see ISO C++ [lib.using.headers]/3.

Comment 6 Tom Horsley 2009-04-23 10:54:26 UTC
Yea, I was definitely leaning toward a truecrypt bug, I just couldn't
figure out what silly thing it was doing. Thanks for letting me know.


Note You need to log in before you can comment on or make changes to this bug.