10 Nov
2016
10 Nov
'16
2:44 p.m.
On Thu, 10 Nov 2016 10:59:31 +0000
Bill Purvis <bill(a)billp.org> wrote:
On 09/11/16 19:47, Johannes Kroll wrote:
You're right of course. Replace "int" with "long" in my message
above
and it starts to make sense.
On Wed, 9 Nov 2016 20:08:39 +0100 (CET)
"J. C." <julien(a)mail.upb.de> wrote:
Sorry, that's not true. In earlier times,
before things like standards were
invented and 32 bits seemed a lot, int=16 bits, long=32bits. When they got
round to standardising C, int was defined as either 16 or 32 bits, depending
on the architecture. Short=16 bits, long=32bits. Then 64 bits came in, and
16-bit machine were virtually forgotten. int was then only vaguely defined
but in practice it is always 32 bits (unless you have a very old
compiler for
a 16-bit machine). It does NOT extend to 64 bits, with the possible
exception
of some obscure machines that only support 64 bits (CDC?). Long is either
32 or 64 bit, depending on applicable architecture. Nov 9 2016, Markus Seeber has written:
...
No, but it could be a bug/misfeature in the
software you are using for
recording. It could be related to an integer overflow when using a
32-bit signed integer to keep track of file size or something similar.
In C, an 'int' would compile to a 32-bit or 64-bit variable according to
the word size of the target machine. As other possible causes don't
seem to apply, this seems likely. Are you perhaps on a 32bit OS?
Yes, I
am, but would that really effect the systems facility to read and
interpret 64bit integers in a file? The only reliable way is to use the extended types:
int_16, int_32, int_64
which are now available (for those that like typing longer names.... ;-))
(u)int32_t etc, yes.