Re: [LAU] everything stops after 2.1GB

On Thu, 10 Nov 2016 10:59:31 +0000
Bill Purvis <bill@email-addr-hidden> wrote:

> On 09/11/16 19:47, Johannes Kroll wrote:
> > On Wed, 9 Nov 2016 20:08:39 +0100 (CET)
> > "J. C." <julien@email-addr-hidden> 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.

_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-user
Received on Thu Nov 10 16:15:02 2016