[LAU] everything stops after 2.1GB

Bill Purvis bill at billp.org
Thu Nov 10 10:59:31 UTC 2016


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.

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

Bill

-- 
+----------------------------------------+
| Bill Purvis                            |
| email: bill at billp.org                  |
+----------------------------------------+



More information about the Linux-audio-user mailing list