Ok, meanwhile this is taking on consideration I took care of ‘\n’, ‘\r’ and “\r\n” to finish the value of a key correctly with a \0. All errors have disappeared except one. Almost FINE!
I use now Valgrind (very useful indeed, thanks) but I cannot find something useful that reveals the problem in MacOs Action: \r as CR (for unicode) · AbelPau/gdal@1f20e88 (github.com)<https://github.com/AbelPau/gdal/actions/runs/8271208701/job/22630450124> When I run in a docker with Ubuntu 22.04 with valgrind seem that it’s ok (in other stages there were some useful information): ==21710== ==21710== HEAP SUMMARY: ==21710== in use at exit: 29,003 bytes in 256 blocks ==21710== total heap usage: 5,865,320 allocs, 5,865,064 frees, 19,927,117,986 bytes allocated ==21710== ==21710== LEAK SUMMARY: ==21710== definitely lost: 0 bytes in 0 blocks ==21710== indirectly lost: 0 bytes in 0 blocks ==21710== possibly lost: 0 bytes in 0 blocks ==21710== still reachable: 29,003 bytes in 256 blocks ==21710== suppressed: 0 bytes in 0 blocks ==21710== Reachable blocks (those to which a pointer was found) are not shown. ==21710== To see them, rerun with: --leak-check=full --show-leak-kinds=all ==21710== ==21710== For lists of detected and suppressed errors, rerun with: -s ==21710== ERROR SUMMARY: 26 errors from 3 contexts (suppressed: 0 from 0) So, do you have any idea how I could reproduce the macOS_build error? It’s the only mistake now :=o Thanks for any clue! De: Even Rouault <even.roua...@spatialys.com> Enviado el: dimecres, 13 de març de 2024 17:04 Para: Abel Pau <a....@creaf.uab.cat>; gdal-dev@lists.osgeo.org Asunto: Re: [gdal-dev] There's something strange about two tests that are very similar My intuition is that reading/writing ini file should be quite straightforward (unless I'm missing some subtelties of the format). In port/cpl_conv.cpp, we have a CPLLoadConfigOptionsFromFile() function that does that in a specific way for the purposes of parsing the GDAL configuration file (https://gdal.org/user/configoptions.html#gdal-configuration-file). But I can imagine we could have a more general std::map<std::string, std::pair<std::string,std::string>> CPLLoadIniFile(const char* pszIniFilename, CSLConstList papszOptions (if needed)) that would return a map of section -> (key, value) pairs. Regarding an external project, this might be considered but one has to evaluate if there are not downsides (e.g will the effort to make it compile on all platforms and make all analysis tools we use happy not be greater than its benefits) Le 13/03/2024 à 15:00, Abel Pau via gdal-dev a écrit : Hi again, MiraMon files have had INI files containing metadata information for ages. To read and write sections and key/values from them, we use specific Windows functions (https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-getprivateprofilestring). When I started programming the driver, I had to create a function to do that as I couldn't use the Windows one. I suspect that these functions are not accurate and are failing. Is there any function in GDAL that can read INI files (at least to check if a section exists and to get the value of a key in an existing section)? If not, perhaps using the following could be considered: https://github.com/brofield/simpleini It seems to have an MIT license... If it's possible to use this parser, what would be the procedure? I noticed that Even added a parser for some command line arguments and perhaps something similar can be done with that. If not, is it possible for me to add some files in the MiraMonVector driver and use them? It's better to use something existing and multiplatform than to "reinvent the wheel" with some new function that can fail (in fact, is failing now). Thanks.
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev
