It's a simple, standard typing rule that's been around in C/C++ since the
beginning of time. In the following expression
60 * 60 * 24
you are multiplying an int by an int by an int. The type of the result is
therefore int. On the Palm OS an int is only 16bits. This, the result of
20864 instead of 86400. In your expression
ULong adaysworthofsecs = 86400; // 60 secs/min * 60 mins/hr * 24 hrs/day
the compile "sees" that 86400 doesn't "fit" into a 16-bit integer so it
promotes it to a long (signed 32-bit value) which can then be (silently)
converted to an unsigned long (ULONG).
If your first expression was rewritten as
60L * 60L * 24L
then you would have achieved the correct result as well.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Bradly
J. Barton
Sent: Monday, February 28, 2000 9:40 PM
To: Palm Developer Forum
Subject: Multiplication Madness Revisited
(Second attempt to post, apologies if this is a repeat.)
I didn't see any resolution to this in the last couple digests, so at risk
of opening a raw wound, I'd like to add my two cents and a piece of sample
code...
I first encountered this problem when trying to code something that
required yesterday's date.. so I decided the best way to do this was to
take the return value from TimGetSeconds, subtract a day's worth of
seconds, and feed that result to TimSecondsToDateTime.. the first pass of
code looked like this:
DateTimeType dateTime;
TimSecondsToDateTime((TimGetSeconds() - (60 * 60 * 24)), &dateTime);
Now, peculiarly enough.. this was not giving me the right answer.. so I
changed it a little:
DateTimeType dateTime;
ULong secs = TimGetSeconds() - (60 * 60 * 24);
TimSecondsToDateTime(secs, &dateTime);
And the answer still wasn't right.. so I tried this:
DateTimeType dateTime;
ULong adaysworthofsecs = 60 * 60 * 24;
ULong secs = TimGetSeconds();
secs -= adaysworthofsecs;
Ok, now I was confused.. but only for a moment.. tracing the above code in
the debugger, I found the value assigned to adaysworthofsecs was only 20864
(ok, I'm trying to remember off the top of my head, but it was close to
that number). A quick check showed that the actual value 86400 - 20864 was
65536 ... hmmm.. curiouser and curiouser.. so deciding to do it the way I
probably should have in the first place (and just plugged 86400 in directly
instead of adding all of that compile time/run time depending on
optimization nonsense), I had the completed code:
ULong secs;
ULong adaysworthofsecs = 86400; // 60 secs/min * 60 mins/hr * 24 hrs/day
char yest[11];
secs = TimGetSeconds();
secs-= adaysworthofsecs;
TimSecondsToDateTime (secs, &dateTime);
StrPrintF(yest, "%02d/%02d/%d", dateTime.month, dateTime.day,
dateTime.year);
So, bottom line.. why does the compiler do this? It assumes integer values
for the constants even though its being assigned to a long? What's up with
that?
Bradly J. Barton - [EMAIL PROTECTED]
Jenies Technologies Incorporated
(972) 602-1835
JTI.net
PalmInHand.com
--
For information on using the Palm Developer Forums, or to unsubscribe,
please see http://www.palm.com/devzone/mailinglists.html
--
For information on using the Palm Developer Forums, or to unsubscribe, please see
http://www.palm.com/devzone/mailinglists.html
