[LAU] everything stops after 2.1GB

[Johannes Kroll]

On Thu, 10 Nov 2016 10:59:31 +0000
Bill Purvis <bill at billp.org> wrote:

> On 09/11/16 19:47, Johannes Kroll wrote:
> > On Wed, 9 Nov 2016 20:08:39 +0100 (CET)
> > "J. C." <julien at mail.upb.de> wrote:
> >  
> >> Nov 9 2016, Markus Seeber has written:
> >> ...  
> >>> 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?  
> > 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.  
> 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.

You're right of course. Replace "int" with "long" in my message above
and it starts to make sense.


> 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.