On Thu, 10 Nov 2016 10:59:31 +0000 Bill Purvis <bill@xxxxxxxxx> wrote: > On 09/11/16 19:47, Johannes Kroll wrote: > > On Wed, 9 Nov 2016 20:08:39 +0100 (CET) > > "J. C." <julien@xxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
