Christof points out problems with atoi() and line endings -- I ran into similar problems some time ago and resorted to sscanf()-ing what I read from the file to format it it 'properly' in memory before doing the conversion.
brad On Mon, Aug 15, 2022 at 3:39 AM Christof Ressi <[email protected]> wrote: > Edwin has already pointed out the immediate error in your code. > > However, there are a lot more problems. First some general issues: > > * you need to free the line buffer before returning from the function, > otherwise there will be a memory leak. > > * AFAICT, the string buffer passed to atoi() is not NULL-terminated. > atoi() stops after encountering a non-numeric character, so depending on > the data that happens to be on stack, this might appear to work - but it > can also easily lead to wrong results! > > * The default line ending on Windows is CRLF (13 + 10) instead of just LF > (10), so depending on how the file was created, your code might not work > correctly. > > Now some remarks about the actual code. IIUC, what you try to do is read > the content of the text file into a two-dimensional array. Your approach > seems to be the following: loop backwards character by character and > manually assemble the decimal numbers from individual digits. First off, in > this case there is need to call atoi() in the first place because you > already know the value of the digit. On the other hand, this is completely > unnecessary because atoi() can parse *numbers *- not only digits! For > example, atoi("1024") will output an integer 1024. > > Unfortunately, atoi() has a few problems: it does not handle errors and > it does not give you the position after the number, so you need to manually > search for whitespace/newlines. > https://cplusplus.com/reference/cstdlib/strtol/ > <https://urldefense.proofpoint.com/v2/url?u=https-3A__cplusplus.com_reference_cstdlib_strtol_&d=DwMFaQ&c=009klHSCxuh5AI1vNQzSO0KGjl4nbi2Q0M1QLJX9BeE&r=TUSlFmJ_9hRhpnUmWLtwdEo8SXGhxgz2NDS43-6hnKg&m=5HPO3yP5cO7EAoTCLdg8pt_pFjHj1F_sb9fmPj7RONcdAsUqm3_qp-YU6QFsBjhO&s=aojlAfmm0qrla86hNuWi_ywdPlUiiQh4BXpvgdwQljA&e=> > solves both issues. > > The most idiomatic way for reading a sequence of numbers from a textfile > in C would be https://cplusplus.com/reference/cstdio/sscanf/ > <https://urldefense.proofpoint.com/v2/url?u=https-3A__cplusplus.com_reference_cstdio_sscanf_&d=DwMFaQ&c=009klHSCxuh5AI1vNQzSO0KGjl4nbi2Q0M1QLJX9BeE&r=TUSlFmJ_9hRhpnUmWLtwdEo8SXGhxgz2NDS43-6hnKg&m=5HPO3yP5cO7EAoTCLdg8pt_pFjHj1F_sb9fmPj7RONcdAsUqm3_qp-YU6QFsBjhO&s=NQmHaCycNfkE6pc2Lw_VRoGaSYkZeYhDtqKZr8ih0jM&e=>. > Your code could be rewritten as follows: > int readbarfile(int a[][8], FILE *f) { > int row = 0; > char * line = NULL; > size_t len = 0; > while (getline(&line, &len, f) != -1) { > int col, value, nread, pos = 0; > for (col = 0; col < 4; col++) { > // We expect 1 converted element. > // (%n does not count, it only tells the current stream position.) > if (sscanf(line + pos, "%d%n", &value, &nread) == 1) { > a[row][col] = value; > pos += nread; > } else { > // handle conversion error > } > } > row++; > } > free(line); > return row; > } > > Since you are dealing with a fixed column size, this could be simplified > further: > int readbarfile(int a[][8], FILE *f) { > int row = 0, col; > char * line = NULL; > size_t len = 0; > while (getline(&line, &len, f) != -1) { > // We expect 4 integer items. Actually, we can directly read into the > output array > // because the data type (int) matches the %d specifier. > if (sscanf(line, "%d%d%d%d", &a[row][0], &a[row][1], &a[row][2], > &a[row][3]) != 4) { > // handle error > } > row++; > } > free(line); > return row; > } > > Christof > On 15.08.2022 08:29, Jaime Oliver 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 <[email protected]> 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 <[email protected]> >> 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 >>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__twitter.com_marcan42_status_1494213855387734019&d=DwMFaQ&c=009klHSCxuh5AI1vNQzSO0KGjl4nbi2Q0M1QLJX9BeE&r=TUSlFmJ_9hRhpnUmWLtwdEo8SXGhxgz2NDS43-6hnKg&m=5HPO3yP5cO7EAoTCLdg8pt_pFjHj1F_sb9fmPj7RONcdAsUqm3_qp-YU6QFsBjhO&s=oiKhcMBiqQPZXOuU59byzkz6mJov0w-_kEaq00lsSXg&e=> >>> >>> On Fri, Aug 12, 2022 at 6:14 AM Jaime Oliver <[email protected]> >>> 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 >>>> _______________________________________________ >>>> [email protected] mailing list >>>> UNSUBSCRIBE and account-management -> >>>> https://lists.puredata.info/listinfo/pd-list >>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.puredata.info_listinfo_pd-2Dlist&d=DwMFaQ&c=009klHSCxuh5AI1vNQzSO0KGjl4nbi2Q0M1QLJX9BeE&r=TUSlFmJ_9hRhpnUmWLtwdEo8SXGhxgz2NDS43-6hnKg&m=5HPO3yP5cO7EAoTCLdg8pt_pFjHj1F_sb9fmPj7RONcdAsUqm3_qp-YU6QFsBjhO&s=C9xTf51AkTfmar1-nEEfndNgNbpQJenqK5zX0_BfG50&e=> >>>> >>> _______________________________________________ >>> [email protected] mailing list >>> UNSUBSCRIBE and account-management -> >>> https://lists.puredata.info/listinfo/pd-list >>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.puredata.info_listinfo_pd-2Dlist&d=DwMFaQ&c=009klHSCxuh5AI1vNQzSO0KGjl4nbi2Q0M1QLJX9BeE&r=TUSlFmJ_9hRhpnUmWLtwdEo8SXGhxgz2NDS43-6hnKg&m=5HPO3yP5cO7EAoTCLdg8pt_pFjHj1F_sb9fmPj7RONcdAsUqm3_qp-YU6QFsBjhO&s=C9xTf51AkTfmar1-nEEfndNgNbpQJenqK5zX0_BfG50&e=> >>> >> _______________________________________________ >> [email protected] mailing list >> UNSUBSCRIBE and account-management -> >> https://lists.puredata.info/listinfo/pd-list >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.puredata.info_listinfo_pd-2Dlist&d=DwMFaQ&c=009klHSCxuh5AI1vNQzSO0KGjl4nbi2Q0M1QLJX9BeE&r=TUSlFmJ_9hRhpnUmWLtwdEo8SXGhxgz2NDS43-6hnKg&m=5HPO3yP5cO7EAoTCLdg8pt_pFjHj1F_sb9fmPj7RONcdAsUqm3_qp-YU6QFsBjhO&s=C9xTf51AkTfmar1-nEEfndNgNbpQJenqK5zX0_BfG50&e=> >> > > > -- > ********************** > Jaime E Oliver LR > www.jaimeoliver.pe > <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.jaimeoliver.pe&d=DwMFaQ&c=009klHSCxuh5AI1vNQzSO0KGjl4nbi2Q0M1QLJX9BeE&r=TUSlFmJ_9hRhpnUmWLtwdEo8SXGhxgz2NDS43-6hnKg&m=5HPO3yP5cO7EAoTCLdg8pt_pFjHj1F_sb9fmPj7RONcdAsUqm3_qp-YU6QFsBjhO&s=816FeXVgLvL2QY607BjMTQHSAVONVbxVVVkeYicfCok&e=> > > > _______________________________________________pd-l...@lists.iem.at mailing > list > UNSUBSCRIBE and account-management -> > https://lists.puredata.info/listinfo/pd-list > <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.puredata.info_listinfo_pd-2Dlist&d=DwMFaQ&c=009klHSCxuh5AI1vNQzSO0KGjl4nbi2Q0M1QLJX9BeE&r=TUSlFmJ_9hRhpnUmWLtwdEo8SXGhxgz2NDS43-6hnKg&m=5HPO3yP5cO7EAoTCLdg8pt_pFjHj1F_sb9fmPj7RONcdAsUqm3_qp-YU6QFsBjhO&s=C9xTf51AkTfmar1-nEEfndNgNbpQJenqK5zX0_BfG50&e=> > > _______________________________________________ > [email protected] mailing list > UNSUBSCRIBE and account-management -> > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.puredata.info_listinfo_pd-2Dlist&d=DwICAg&c=009klHSCxuh5AI1vNQzSO0KGjl4nbi2Q0M1QLJX9BeE&r=TUSlFmJ_9hRhpnUmWLtwdEo8SXGhxgz2NDS43-6hnKg&m=5HPO3yP5cO7EAoTCLdg8pt_pFjHj1F_sb9fmPj7RONcdAsUqm3_qp-YU6QFsBjhO&s=C9xTf51AkTfmar1-nEEfndNgNbpQJenqK5zX0_BfG50&e= > >
_______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
