Linux data types size

What is the maximum size of signed long long data type in 32 bit Linux

I am wondering how to handle large range of values in 32 bit Linux platform using the C++ program. Thanks for you help.

std::numeric_limits::max() . Note that long long is only guaranteed to be 64 bits since C++11 (in C++, that is.)

@juanchopanza, The call std::numeric_limits::max(); returns a large value. but the above code is not working. I think I didn’t understand your comment completely

BTW, your program does not perform any output: it is lacking a call to some output function like printf

4 Answers 4

The problem is that the type of an unsuffixed integer constant (like 42 ) is the smallest of int , long int , long long int that can hold its value, and the type of an expression is determined by the expression itself, not by the context in which it appears.

So if int happens to be 32 bits on your system, then in this:

unsigned long long val = 140417 * 100000 + 92 + 1;

the constants 140417 and 100000 (which both fit in 32 bits) are of type int , and the multiplication is a 32-bit multiplication — which overflows because the product of those two numbers doesn’t fit in 32 bits. (The type of a standalone literal is adjusted based on its value; the type of a larger expression is not.)

The most straightforward way to avoid this is to use constants of type unsigned long long :

unsigned long long val = 140417ULL * 100000ULL + 92ULL + 1ULL; 

(It happens that not all the ULL suffixes are necessary, but it doesn’t hurt to apply them to all the constants in the expression.)

Источник

Possible to find out the sizes of data types (int, float, double, . ) on a system, without writing a C program?

Is it possible to find out the sizes of data types (int, float, double, . ) on a Linux system, without writing a C program? Would the results for C same as for C++, and other programming languages in the same Linux system?

I am curious — if you don’t intend to write a C program, what difference does it make if C data types are one size rather than another?

7 Answers 7

If you know the definition of the data type you want you can use getconf to find these values out on most Unix systems.

The list of variables is defined in the man page man limits.h as well as here, man sysconf , in addition to being on disk. You can use locate limits.h to find it, it’s often here: /usr/include/linux/limits.h .

With the caveat that this applies only to the platform’s official C compiler. There may be alternative compilers, or alternative configurations (typically through command line options) of the official compiler, that lead to different sizes.

@Gilles — have you ever seen a way to actually list these variables out? I’ve been looking and cannot for the life of me find a tool that can do this. Seems like there would be. Also I was under the impression that getting these values through getconf was the safest way, so long as you say, I’m hitting «the» official compiler on the box.

The reliable way — and the way people use when they care, which is by and large when they want to compile a C program — is to compile a small C program. See how autoconf operates. getconf isn’t so safe, unless you’re calling the C compiler as c89 or c99 with (almost) no option.

With gcc at least, this works:

$ cpp -dD /dev/null | grep __SIZEOF_LONG__ 

Anyway, why don’t you want to write a C program to do it? You could send a tiny C program to your compiler from the shell something like this:

binary=$(mktemp) cat <<\EOF | cc -o $binary -x c - #include int main() < printf("int=%lu bytes\n", sizeof(int)); printf("long=%lu bytes\n", sizeof(long)); >EOF $binary rm $binary 

The -x c tells the compiler the language is C , and the — means read from standard input.

On my system, the above prints:

Yes. You could scan /usr/include//limits.h

For example, on my NetBSD amd64, /usr/include/amd64/limits.h would show:

#define CHAR_BIT 8 /* number of bits in a char */ #define SCHAR_MAX 0x7f /* max value for a signed char */ #define SCHAR_MIN (-0x7f-1) /* min value for a signed char */ #define UCHAR_MAX 0xff /* max value for an unsigned char */ #define CHAR_MAX 0x7f /* max value for a char */ #define CHAR_MIN (-0x7f-1) /* min value for a char */ #define USHRT_MAX 0xffff /* max value for an unsigned short */ #define SHRT_MAX 0x7fff /* max value for a short */ #define SHRT_MIN (-0x7fff-1) /* min value for a short */ #define UINT_MAX 0xffffffffU /* max value for an unsigned int */ #define INT_MAX 0x7fffffff /* max value for an int */ #define INT_MIN (-0x7fffffff-1) /* min value for an int */ #define ULONG_MAX 0xffffffffffffffffUL /* max value for an unsigned long */ #define LONG_MAX 0x7fffffffffffffffL /* max value for a long */ #define LONG_MIN (-0x7fffffffffffffffL-1) /* min value for a long */ 

Источник

size of basic data types in C

The size of float and double must be at least 4 and 8 respectively. 2

@SecurityMatt @Hot Licks No. char can have more than 8 bits, so sizeof(int) == 1 is possible, e.g. on TI 28Cxx where both have 16 bits.

5 Answers 5

My question is if I were to run the same program on a 32-bit machine will I see different results

Or in other words does the size of the basic data types depend on 1) processor 2) Operating System 3) anything else

1. Yes, 2. yes, 3. yes, for example if you run a 32-bit app in 32-bit compatibility mode on a 64-bit OS, then it most likely will use a 32-bit word size (of course, it was compiled like that). Oh, and yes, it may depend on the compiler too.

«And your compiler flags. « (Thanks, Kay!)

Subject to having to install some libraries [probably just glibc] in it’s 32-bit variant, you should be able to try this yourself by using gcc -m32 myprog.c [or clang -m32 myprog.c ].

However, the only thing of your items that have been listed that will change if you move from a 64-bit x86 linux system to 32-bit x86 linux system, using gcc-based compilers, is the size of long . Note the heavy qualification of x86, gcc, etc — compilers have a lot of freedom. Someone could write a compiler for Linux that uses 16-bit int and 64-bit long on a 32-bit system with no huge amount of difficulty. Using that compiler to compile the Linux kernel and many of the Linux tools would probably fail [most likely including compiling gcc with that compiler]. But you can’t really say «on this architecture» or «in this OS» or «with this compiler» . without also qualifying what the OTHER parameters are.

Case in point: A Microsoft C/C++ compiler has a long that is 32 bit even on 64-bit systems. Why, I hear you ask? Because a large number of Windows API functions use long as a 32-bit value as legacy from when Windows was a 16-bit OS on Intel 286/386 processors. Since (some of) the system calls are backwards compatible a very long way in Windows, code that is written for 16-bit systems will still work on 64-bit Windows [unless the code is using some really unusual system calls, and of course, the STYLE will look a bit ancient]. Changing long to a 64-bit value would have broken some of that functioanilty, so the compiler guys at MS decided to stick with long = 32 bit. If you want 64-bit integers, you have to use long long or int64_t or something else, not long . Of course, this breaks some code that assumes that sizeof(long) == sizeof(void *) . Hopefully, most such code has already been fixed.

Источник