Closed Bug 212161 Opened 16 years ago Closed 8 years ago

build warnings in nsJVMAuthTools.cpp when using gcc under Win32

Categories

(Core Graveyard :: Java: OJI, defect)

x86
Windows XP
defect
Not set

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: bugzilla, Assigned: alfred.peng)

References

(Blocks 2 open bugs)

Details

when I build under gcc with win32

c:/mozilla/mozilla/modules/oji/src/nsJVMAuthTools.cpp: In member function
   `virtual nsresult nsJVMAuthTools::Internal::QueryInterface(const nsIID&,
   void**)':
c:/mozilla/mozilla/modules/oji/src/nsJVMAuthTools.cpp:86: warning: invalid
   offsetof from non-POD type `class nsJVMAuthTools'; use pointer to member
   instead
c:/mozilla/mozilla/modules/oji/src/nsJVMAuthTools.cpp: In member function
   `virtual nsrefcnt nsJVMAuthTools::Internal::AddRef()':
c:/mozilla/mozilla/modules/oji/src/nsJVMAuthTools.cpp:86: warning: invalid
   offsetof from non-POD type `class nsJVMAuthTools'; use pointer to member
   instead
c:/mozilla/mozilla/modules/oji/src/nsJVMAuthTools.cpp: In member function
   `virtual nsrefcnt nsJVMAuthTools::Internal::Release()':
c:/mozilla/mozilla/modules/oji/src/nsJVMAuthTools.cpp:86: warning: invalid
   offsetof from non-POD type `class nsJVMAuthTools'; use pointer to member
Status: NEW → ASSIGNED
I haven't met this warning,
did you see this warning when build nsJVMManager.cpp?

Thanks!
I use VC++6.0,

Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 12.00.8804 for 80x86
Copyright (C) Microsoft Corp 1984-1998. All rights reserved.
I see these when I compile under gcc under windows. So no VC++ here.

If I delete "nsJVMAuthTools.o" and type "make" I see these warnings
Summary: build warnings in nsJVMAuthTools.cpp → build warnings in nsJVMAuthTools.cpp when using gcc under Win32
did you see this warning when build nsJVMManager.cpp?

Delete "nsJVMManager.o" and type "make", can you see these warnings?

Thanks!

after delete "nsJVMManager.o" and "make":

c:/mozilla/mozilla/modules/oji/src/nsJVMManager.cpp: In member function
   `virtual nsresult nsJVMManager::Internal::QueryInterface(const nsIID&,
   void**)':
c:/mozilla/mozilla/modules/oji/src/nsJVMManager.cpp:122: warning: invalid
   offsetof from non-POD type `struct nsJVMManager'; use pointer to member
   instead
c:/mozilla/mozilla/modules/oji/src/nsJVMManager.cpp: In member function
   `virtual nsrefcnt nsJVMManager::Internal::AddRef()':
c:/mozilla/mozilla/modules/oji/src/nsJVMManager.cpp:122: warning: invalid
   offsetof from non-POD type `struct nsJVMManager'; use pointer to member
   instead
c:/mozilla/mozilla/modules/oji/src/nsJVMManager.cpp: In member function
   `virtual nsrefcnt nsJVMManager::Internal::Release()':
c:/mozilla/mozilla/modules/oji/src/nsJVMManager.cpp:122: warning: invalid
   offsetof from non-POD type `struct nsJVMManager'; use pointer to member
   instead
c:/mozilla/mozilla/modules/oji/src/nsJVMManager.cpp: In member function `PRBool

   nsJVMManager::MaybeStartupLiveConnect()':
c:/mozilla/mozilla/modules/oji/src/nsJVMManager.cpp:899: warning: unused
   variable `PRBool registeredLiveConnectFactory'
Blocks: buildwarning
->kyle
Assignee: joshua.xia → kyle.yuan
Status: ASSIGNED → NEW
Blocks: mingw
Ha! I have been trying to find a bug with the word offsetof in the summary.

http://gcc.gnu.org/ml/gcc-prs/2003-01/msg01232.html
http://coding.derkeiler.com/Archive/C_CPP/comp.lang.cpp/2003-11/3069.html

I am seeing these in a lot of places.

There is not much information on the web about this warning, but it seems that
gcc < 3.0 was lax about it, and gcc 3.4 (compared to 3.3) has changed the 
message, which is why we are seeing it now.

So far as I can tell, the main reason to use the offsetof macro in C++ code
is to get the address of a member of an object to pass to a non-C++ 
function (such as legacy C code). Where this is the case then the use
of the offsetof macro should be deprecated and replaced by pointer-to-member.

See http://gcc.gnu.org/ml/gcc/2003-11/msg00289.html

It may be difficult to see which of the warnings require changes to
the code for portability/safety - probably very few as I suspect that
most of these cases are those where although the use of offset is
contrary to the language specification, any reasonable implementation
will give the right answer.

We ought to be sure that all cases where the offsetof will produce
nonsense (where the offset may not be a compile-time constant,
for example), are modified to use the pointer-to-member syntax.

Would patches be considired?
Assignee: yuanyi21 → pete.zha
mass reassign to Alfred
Assignee: zhayupeng → alfred.peng
Product: Core → Core Graveyard
QA Contact: dsirnapalli → java.oji
This code no longer exists.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.