Weird, frustrating problem with integer math. I have a 64 bit integer variable that I am trying to use to scan through a file (file position offset value) that simply will not play nice with 32 bit values. No matter what I do, I just cannot alter it, it will not accept any values other than constants. I tried turning on "Use 64 bit math" in the build setting, to no avail. Is there some kind of conversion I need to do to get it to accept other values?
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
macOS Sticky Variable
- Thread starter Sydde
- Start date
- Sort by reaction score
Post some code. Are you trying to initialize with a large integer? Are you setting your offset with some math? Are you using an off64_t, long int, something else? Are you using functions that accept this big type?
-Lee
-Lee
Its primary use is in the NSFileHandle method -seekToOffset: which calls for a unsigned long long. Nothing will affect the variable other than a constant. For example,
has no effect on the value of fileOffset. I tried UInt64 and SInt64 and the aforementioned compiler flag (debug mode on a G5, for native architecture, compiling with the 10.4 SDK), nothing will penetrate the variable. I dragged all my sources to a new project, in hopes that perhaps the project file itself was corrupted. Still the variable remains obstinate.
Code:
int recordAdjust;
long long fileOffset;
...
recordAdjust = calcRecordSize( currentRecord );
fileOffset += recordAdjust;
Explain how you know it has no effect on the value of fileOffset.
Off the top of my head, I suggest making a simple single-file command-line main() function that demonstrates the problem, and can be compiled with a simple gcc example.c command. Post it.
Try compiling for 32-bit G4 and see if anything changes.
Also, identify what the OS and Xcode versions are.
I threw this together:
Worked A-OK and printed what i expected:
I'm on a different platform, but I don't really think that's the problem. In your second post you said "aforementioned flag" but you hadn't mentioned a flag as far as i know, so telling us what that is might be helpful.
-Lee
Code:
#include <stdio.h>
int calcRecordSize(int);
int main(int argc, char *argv) {
long long fileOffset = 8000000000LL;
int recordAdjust = 0;
while(fileOffset <= 8000000080LL) {
recordAdjust = calcRecordSize(7);
fileOffset += recordAdjust;
printf("This time fileOffset is %lld\n",fileOffset);
}
}
int calcRecordSize(int something) {
return something;
}Worked A-OK and printed what i expected:
I'm on a different platform, but I don't really think that's the problem. In your second post you said "aforementioned flag" but you hadn't mentioned a flag as far as i know, so telling us what that is might be helpful.
-Lee
Are you sure the build you're running is the correct one?
How are you examining the value of fileOffset? Xcode's debugger seems to often show wrong values or nothing at all. If using logging, make sure you're using the right format specifiers.
It's probably one of those bugs that you stare at all day, then come back to it the next and the answer is sitting right in front of you
How are you examining the value of fileOffset? Xcode's debugger seems to often show wrong values or nothing at all. If using logging, make sure you're using the right format specifiers.
It's probably one of those bugs that you stare at all day, then come back to it the next and the answer is sitting right in front of you
I fear I may be experiencing some kind of debugger bug, because when I set it to show disassembly, step through that and then examine the memory location that holds the value, I see a non-zero value where the debugger is showing a zero.
Since PPC is big-endian, a 64-bit variable read as a 32-bit value will show the high-order half of the variable, which is almost always going to be zero in tests like this (otherwise, I would have to be working with a very large test file). If this really is a genuine bug, oh well, not like Apple will be addressing it.
I am running 3.1.2 on 10.5.8, but now I am downloading 3.2.6, which hopefully will not have this obscure problem. It is irritating to have a blind-spot when debugging.
Since PPC is big-endian, a 64-bit variable read as a 32-bit value will show the high-order half of the variable, which is almost always going to be zero in tests like this (otherwise, I would have to be working with a very large test file). If this really is a genuine bug, oh well, not like Apple will be addressing it.
I am running 3.1.2 on 10.5.8, but now I am downloading 3.2.6, which hopefully will not have this obscure problem. It is irritating to have a blind-spot when debugging.
Step back, take a deep breath, and follow the first rule in debugging: There is nothing strange going on, just _you_ made a mistake in _your_ code, and you need to find the problem in _your_ code. Did you turn all useful warnings on? Could you have two variables with the same name?