C/C++ Programming Questions Not Worth Their Own Thread

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > C/C++ Programming Questions Not Worth Their Own Thread

elevatordeadline: Jan 29, 2008

Teach me about 64-bit integers in C.

In Java, int is four bytes and long is eight bytes. That's not the case in C, where, if I understand correctly, sizeof(long) only has to be at least equal to sizeof(int). So what should I do when I need a 64-bit integer?

# ¿ Mar 20, 2008 22:02

Adbot: ADBOT LOVES YOU

# ¿ May 4, 2024 06:36

elevatordeadline: Jan 29, 2008

uint64_t and unsigned long long both work as long as I'm using gcc -std=c99. Hooray. Evidently, though, I don't understand what to do next.

For example,

code:

typedef unsigned long long ulong;

ulong x, y, z;
printf("%llu bytes.\n", (ulong) sizeof(ulong));
scanf("%llu %llu %llu", &x, &y, &z);
printf("x = %llu,\ny = %llu,\nz = %llu.\n", x, y, z);

If the input is 314, 31415926535897, and 6469693230, then the output is

code:

8 bytes.
x = 314,
y = 2147303424,
z = 2535732953.

Those numbers are not the same numbers at all. :(

# ¿ Mar 20, 2008 22:40

elevatordeadline: Jan 29, 2008

Lexical Unit posted:

You might open up your inttypes.h file and see what's in there. You may not find a perfectly portable solution, unfortunately.

code:

/* 7.8.1 Macros for format specifiers
 * 
 * MS runtime does not yet understand C9x standard "ll"
 * length specifier. It appears to treat "ll" as "l".
 * The non-standard I64 length specifier causes warning in GCC,
 * but understood by MS runtime functions.
 */

Oh, okay. Well, it's a good thing that this program's only going to be tested and run on a Linux machine that does understand "ll." Thanks, guys.

# ¿ Mar 21, 2008 00:53

elevatordeadline: Jan 29, 2008

I hope someone can tell me what I'm doing wrong, because apparently codepad can't.

Here's what's supposed to happen, and what codepad says does happen.

code:

Node at 0x804F438 says 10.000000x^100 and points to 0x0.

When I compile and run the same code, though, well.

code:

:< g++ -o a.exe a.cpp

:< a.exe
Node at 0x324C8 says -0.000000x^16386 and points to 0x64.

So what am I missing?

# ¿ May 1, 2008 11:29

elevatordeadline: Jan 29, 2008

vanjalolz posted:

I don't like the look of that, you're defining a struct Node then you're typedef'ing over it. You're using g++ so you dont need the type def anyway, change it to
code:
struct Node { ldouble coeff; ulong power; Node* next; }

The reason for the typedef is because this was at one point C code, and I didn't want to have struct nodes all over the place.

vanjalolz posted:

Are you on a 64 bit system? I think the proper way to printf pointers is %p.

I'm not, but you're right.

I don't get it, though. The new codepad output is still correct, but mine is still nonsense.

code:

>: g++ -Wall -Wextra -pedantic -o a.exe a.cpp

>: a.exe
Node at 0x000324E8 says -0.000000x^16386 and points to 0x00000064.

Also:

MrVacBob posted:

One of your printf formats is being ignored (probably because it doesn't like "%Lfx") so it's reading the wrong thing off the stack.

I don't see why that would even be true. If I don't use %Lf, the compiler warns about a format-argument mismatch, and using either of "%Lfx" or "%Lf x" makes no difference.

# ¿ May 2, 2008 01:32

Adbot: ADBOT LOVES YOU

# ¿ May 4, 2024 06:36

elevatordeadline: Jan 29, 2008

TSDK posted:

I think your dev environment is misconfigured. By the looks of it, either there's a mismatch in the calling convention or the long double support between your executable and the library you're linking against.

I guess so. As it turns out, changing long doubles and %Lfs, respectively, to doubles and %fs made everything work as it should've in the first place.

# ¿ May 6, 2008 07:58

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > C/C++ Programming Questions Not Worth Their Own Thread