pow() must be giving you 9.9999999 (or something similar) instead of 10 which
is rounded down to 9 by the int typecast.
This results in 3 * 9 + 2 = 29.
To solve this you can, for example, do a round() before the typecast or you can
add 0.5 to the output of pow() before doing the typecast.
Best!
Edwin
On 15 Aug 2022, at 08:31, Jaime Oliver <jaime.oliv...@gmail.com> wrote:
Hi Chris, Brad, All,
I managed to trace the error to the function below. It reads a text file and
copies its contents to a matrix. The file it's reading is always made of lines
with the same number of elements like this below:
0 4 4 8 32
1 4 4 8 32
2 4 4 8 32
...
The specific error I'm getting right now is that it is reading that number 32
as 29. Again, this same code works fine in all other OSs I've tried.
I'm assuming the issue is in the pow() function and all the typecasting (int),
(double) as Chris suggested?
As for compilation, I am using the latest pd_lib_builder as the makefile.
Thanks for your help!
best,
Jaime
code:
int readbarfile(int a[][8], FILE *f) {
int i, ii, j, jj, strsize, temp;
char * line = NULL;
size_t len = 0;
ssize_t read;
char ss[10];
temp=j=0;
ii=0;
while ((read = getline(&line, &len, f)) != -1) {
jj = 4;
strsize = (int) read;
for (i=strsize-1; i>=0; i--){
if ( line[i] == (int) 32 || line[i] == (int) 10) { //space or
newline
if(i != (strsize-1)) {
a[ii][jj] = temp;
jj--;
}
j=0;
temp=0;
}
else {
ss[0] = line[i];
temp += atoi(ss)*( (int) pow((double)10, (double)j) );
j++;
}
}
ii++;
}
return (ii);
}
On Fri, Aug 12, 2022 at 1:57 PM Chris Clepper <cgclep...@gmail.com> wrote:
> That issue only relates to data corruption in the case of major failures like
> power loss and kernel panics. In most of those situations some data loss is
> not only expected but also the least of your concerns.
>
> As for the original topic, the first thing to check is the usual problems
> moving between architectures like endianess, definition of data structures
> (is long really 32 bits, double 64 bits, etc), memory alignment and compiler
> settings. Does the code work with all of the optimizations turned off?
>
> On Fri, Aug 12, 2022 at 5:58 AM Bastiaan van den Berg <b...@spacedout.nl>
> wrote:
>> Did you read that M1's storage has so much cache + lies to the OS about
>> cache commitments, leading to data corruption sometimes?
>> https://twitter.com/marcan42/status/1494213855387734019
>>
>> On Fri, Aug 12, 2022 at 6:14 AM Jaime Oliver <jaime.oliv...@gmail.com> wrote:
>>> Dear all,
>>>
>>> I have a c external that compiles and runs fine on windows, Linux, and Mac
>>> Intel systems, but while the exact same code compiles ok on a Mac M1
>>> system, it runs with errors.
>>>
>>> I am trying to figure out the bug, but wonder if anyone has come across
>>> something like this? The external itself is not particularly complex. It
>>> writes and reads text files, does basic arithmetic, and uses arrays of
>>> various sizes.
>>>
>>> Does anyone have any suggestions of where to look first?
>>>
>>> Best,
>>>
>>> Jaime
>>> _______________________________________________
>>> Pd-list@lists.iem.at mailing list
>>> UNSUBSCRIBE and account-management ->
>>> https://lists.puredata.info/listinfo/pd-list
>> _______________________________________________
>> Pd-list@lists.iem.at mailing list
>> UNSUBSCRIBE and account-management ->
>> https://lists.puredata.info/listinfo/pd-list
> _______________________________________________
> Pd-list@lists.iem.at mailing list
> UNSUBSCRIBE and account-management ->
> https://lists.puredata.info/listinfo/pd-list
--
**********************
Jaime E Oliver LR
www.jaimeoliver.pe
_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
_______________________________________________
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management ->
https://lists.puredata.info/listinfo/pd-list
