Strange warnings when compiling CVS...

[rickg22]

Code

sdk\as\bindings\scriptbindings.cpp: In function `void Register_ProjectFile(asIScriptEngine*)':
sdk\as\bindings\scriptbindings.cpp:262: warning: invalid access to non-static data member `ProjectFile::project' of NULL object
sdk\as\bindings\scriptbindings.cpp:262: warning: (perhaps the `offsetof' macro was used incorrectly)

This goes from lines 262 to 270 of the same file.

Code

In file included from plugins\astyle\/formattersettings.h:4,
                 from plugins\astyle\formattersettings.cpp:2:
plugins\astyle\/./astyle/astyle.h:68:2: warning: #warning Compiling DEBUG version (which will print lots of TRACE information to cerr)!

How to get rid of these? And I mean "fix", not just "hide"

[sethjackson]

It seems that ProjectFile::project is NULL???

I looked at the source file and I don't get what it is doing. LOL

All the stuff in quotes...... I guess I'm dumb or something.

Also does the forward slash have anything to do with it?

And is it compiling debug version or something??? I haven't compiled from CVS in awhile so I'm sorta lost.

[Urxae]

I looked into this when I first saw those warnings, and the offsetof macro is indeed used incorrectly. It should only be used on POD types, and ProjectFile doesn't qualify.
Wouldn't know how to actually fix this, other than rewrite that part of the AngelScript engine to use member data pointers. That might require some template magic akin to boost::function to work for multiple types though, unless you only need it to work for ProjectFile.

It seems that ProjectFile::project is NULL???

No, it uses the offsetof macro, which basically casts a pointer to a member of a dereferenced null pointer to an unsigned integer to get the member's offset into the structure.

And is it compiling debug version or something??? I haven't compiled from CVS in awhile so I'm sorta lost.

This is a fairly recent addition to CVS (at least, to the HEAD branch).

[rickg22]

I read more about it.

-Wno-invalid-offsetof (C++ only)
    Suppress warnings from applying the offsetof macro to a non-POD type. According to the 1998 ISO C++ standard, applying offsetof to a non-POD type is undefined. In existing C++ implementations, however, offsetof typically gives meaningful results even when applied to certain kinds of non-POD types. (Such as a simple struct that fails to be a POD type only by virtue of having a constructor.) This flag is for users who are aware that they are writing nonportable code and who have deliberately chosen to ignore the warning about it.

I modified the codeblocks-NewBuild.cbp to include this flag, but I'd like to know if I can commit. It might throw errors using other compilers.

Also, I added a definition of NDEBUG inside the astyle.h file, to rebuild the astyle plugin ito release mode.

Yiannis, is it ok to commit?

[mandrav]

Rick, this flag works only for GCC-4.0 and up. Don't commit it...

[Urxae]

I modified the codeblocks-NewBuild.cbp to include this flag, but I'd like to know if I can commit. It might throw errors using other compilers.

I thought you wanted to

"fix", not just "hide"

this? :p

Rick, this flag works only for GCC-4.0 and up. Don't commit it...

According to this gcc mailing list post it would be added in 3.4. And I can confirm it's available in mingw 3.4.2:

Code

D:\Temp> cat test.cpp
#include <cstdio>

struct data
{
    data() : x(0) {}
    int x;
};

int main()
{
    std::printf("hello world\n");
    std::printf("offsetof x: %i\n", offsetof(data, x));
}

D:\Temp> g++ test.cpp -o test.exe
test.cpp: In function `int main()':
test.cpp:12: warning: invalid access to non-static data member `data::x' of NULL object
test.cpp:12: warning: (perhaps the `offsetof' macro was used incorrectly)

D:\Temp> g++ -Wno-invalid-offsetoff test.cpp -o test.exe

D:\Temp> test
hello world
offsetof x: 0

D:\Temp> g++ --version
g++ (GCC) 3.4.2 (mingw-special)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[mandrav]

According to this gcc mailing list post it would be added in 3.4. And I can confirm it's available in mingw 3.4.2:

Thanks for the correction, but it still doesn't matter. There's no rule to require a specific gcc version to build C::B. In other words, it still can't go in the project file as an option.
Many users (esp. linux users) use older versions like gcc 3.3.5...

[thomas]

It actually works fine under certain conditions, but there are caveats.

First, it works with C++ files, but not with C files. This is an issue when setting it for the Code::Blocks project, but you would not want to do that anyway.

You will want to set it for the smallest possible subset, which is the SDK target in this case.
This, however, means that the major part of Code::Blocks (over 400 files) is compiled without this warning, which is bad. If the build system allowed us to pass custom compiler flags to individual files, that might be acceptable, but compiling the whole SDK this way is dangerous - it may hide actual errors in other places.

Lastly and most importantly, when using older compiler versions, you would expect it to produce additional warnings about unknown command line options in addition to the existing ones.
However, reality is still worse. gcc will actually bail out with an error, so the build is broken.

[rickg22]

Alright then Oh, about the Astyle plugin, that I can commit, right?

[mandrav]

Alright then Oh, about the Astyle plugin, that I can commit, right?

Sure

[thomas]

I fixed it :lol: :lol: :lol:

Actually it is pretty obvious what you have to do, read the error message

Code

#undef offsetof
#define offsetof(T, M) ( reinterpret_cast <size_t> ( & reinterpret_cast <const volatile char &>(reinterpret_cast<T *> (1000)->M) ) - 1000u)

Now say again that macros are not evil 

[thomas]

Seriously now... I know it is a hack and a macro on top.

But offsetof is a hack anyway (and a macro too).

With the casts added to wxScintilla (r1512), I can compile Code::Blocks with zero warnings when putting this offsetof replacement into scriptbindings.cpp (I hope it is really a 100% valid replacement, but I think so... at least it does not crash me). Yes, zero warnings. Repeat that.
This means that any real warnings are now a lot easier to spot.

Shouldn't we go for that workaround then? We know these warnings are not related to a bug, so they are utterly useless. And the macro won't affect any other files if it is located in the cpp file.

After all, why do we compile with -Wall if we get so many useless warnings that we don't see the real ones anyway

[Michael]

I fixed it :lol: :lol: :lol:

Actually it is pretty obvious what you have to do, read the error message

Code

#undef offsetof
#define offsetof(T, M) ( reinterpret_cast <size_t> ( & reinterpret_cast <const volatile char &>(reinterpret_cast<T *> (1000)->M) ) - 1000u)

Now say again that macros are not evil 

Could not be used instead of a macro an inline function?

Michael

[thomas]

No.

EDIT:

Slightly longer answer:
Technically, yes, but
- it is a lot more complicated
- you may have to create a temporary object (I am not sure if you can trick the compiler to do it on a pointer)
- you still must #undef offsetof, so you use preprocessor commands either way
- you need a different calling convention, meaning you have to rewrite the existing code
- you have additional constraints that offsetof has not (so it may not always work)
- it is still a hack

[tiwag]

@thomas
now i get the 20 warnings from offsetof in scriptbindings.cpp again,
but i think i'm not dreaming that your changed offsetof macro definition was already in SVN ? right?

now it isn't anymore in SVN ? why ?