globalDefinitions_gcc.hpp revision 1472
1472N/A * Copyright (c) 1998, 2009, Oracle and/or its affiliates. All rights reserved. 0N/A * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. 0N/A * This code is free software; you can redistribute it and/or modify it 0N/A * under the terms of the GNU General Public License version 2 only, as 0N/A * published by the Free Software Foundation. 0N/A * This code is distributed in the hope that it will be useful, but WITHOUT 0N/A * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or 0N/A * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License 0N/A * version 2 for more details (a copy is included in the LICENSE file that 0N/A * accompanied this code). 0N/A * You should have received a copy of the GNU General Public License version 0N/A * 2 along with this work; if not, write to the Free Software Foundation, 0N/A * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. 1472N/A * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA 0N/A// This file holds compiler-dependent includes, 0N/A// globally used constants & types, class (forward) 0N/A// declarations and a few frequently used utility functions. 0N/A// 4810578: varargs unsafe on 32-bit integer/64-bit pointer architectures 0N/A// When __cplusplus is defined, NULL is defined as 0 (32-bit constant) in 0N/A// system header files. On 32-bit architectures, there is no problem. 0N/A// On 64-bit architectures, defining NULL as a 32-bit constant can cause 0N/A// problems with varargs functions: C++ integral promotion rules say for 0N/A// varargs, we pass the argument 0 as an int. So, if NULL was passed to a 0N/A// varargs function it will remain 32-bits. Depending on the calling 0N/A// convention of the machine, if the argument is passed on the stack then 0N/A// only 32-bits of the "NULL" pointer may be initialized to zero. The 0N/A// other 32-bits will be garbage. If the varargs function is expecting a 0N/A// pointer when it extracts the argument, then we have a problem. 0N/A// Solution: For 64-bit architectures, redefine NULL as 64-bit constant 0. 0N/A// Note: this fix doesn't work well on Linux because NULL will be overwritten 0N/A// whenever a system header file is included. Linux handles NULL correctly 0N/A// through a special type '__null'. 0N/A// NULL vs NULL_WORD: 0N/A// On Linux NULL is defined as a special type '__null'. Assigning __null to 0N/A// integer variable will cause gcc warning. Use NULL_WORD in places where a 0N/A// pointer is stored as integer value. On some platforms, sizeof(intptr_t) > 0N/A// sizeof(void*), so here we want something which is integer type, but has the 0N/A// same size as a pointer. 512N/A // Cast 0 to intptr_t rather than int32_t since they are not the same type 512N/A // on platforms such as Mac OS X. 0N/A// Compiler-specific primitive types 0N/A// %%%% how to access definition of intptr_t portably in 5.5 onward? 0N/A// If this gets an error, figure out a symbol XXX that implies the 0N/A// prior definition of intptr_t, and add "&& !defined(XXX)" above. 0N/A#
endif // _SYS_INT_TYPES_H 0N/A// Additional Java basic types 0N/A//---------------------------------------------------------------------------------------------------- 0N/A// Special (possibly not-portable) casts 0N/A// Cast floats into same-size integers and vice-versa w/o changing bit-pattern 0N/A// %%%%%% These seem like standard C++ to me--how about factoring them out? - Ungar 0N/A//---------------------------------------------------------------------------------------------------- 0N/A// Constant for jlong (specifying an long long canstant is C++ compiler specific) 0N/A// Build a 64bit integer constant 0N/A//---------------------------------------------------------------------------------------------------- 0N/A// NOTE:In the ANSI committee's continuing attempt to make each version 0N/A// of C++ incompatible with the previous version, you can no longer cast 0N/A// pointers to functions without specifying linkage unless you want to get 0N/A// This also means that pointers to functions can no longer be "hidden" 0N/A// in opaque types like void * because at the invokation point warnings 0N/A// will be generated. While this makes perfect sense from a type safety 0N/A// point of view it causes a lot of warnings on old code using C header 0N/A// files. Here are some typedefs to make the job of silencing warnings 0N/A// The final kick in the teeth is that you can only have extern "C" linkage 0N/A// specified at file scope. So these typedefs are here rather than in the 0N/A// .hpp for the class (os:Solaris usually) that needs them. 0N/A // typedef for missing API in libc 0N/A//---------------------------------------------------------------------------------------------------- 0N/A// checking for nanness 0N/A// isnanf() broken on Intel Solaris use isnand() 0N/A#
error "missing platform-specific definition here" 0N/A// Checking for finiteness 0N/A// Portability macros 0N/A// HACK: gcc warns about applying offsetof() to non-POD object or calculating 0N/A// offset directly when base address is NULL. Use 16 to get around the 0N/A// warning. gcc-3.4 has an option -Wno-invalid-offsetof to suppress