Juan, you should never use byte pointer arithmetic in C to create pointers to non-byte types since they cause unaligned memory access as you found out. In most architecture unaligned access is a fatal error (arm64 is just one of many), in some architectures (e.g. x86_64) it will succeed with a performance penalty. The alignment requirements are architecture-specific so it's not portable to do it in your code. You should use structs to access typed members since they guarantee alignment. If you need to access values from arbitrarily packed bytes, you have to copy the contents into a variable of the desired type (as you did in the example).
Cheers, Simon * - some compilers have extensions that allow the use of packed structs which will create temporary copies on access, but they are not part of the C standard so should not be used in R packages. > On Nov 27, 2022, at 9:07 AM, Juan Domingo Esteve <juan.domi...@uv.es> wrote: > > Keywords: compiler warning, package check, arm64 architectures > > This is the first of two reports with CRAN check problems that I found in my > package and > that affect only some particular architectures (in this case, arm64) > > Problem description: > > When compiling a package with C++ source code using Rcpp in a Linux system, > kernel 5.19.16-100, distribution Fedora 35, the generated package passed > R CMD check --as-cran test, giving no compilation warnings. > > Nevertheless, the compilation in the CRAN server provoked a warning > exclusively > for the arm64 architecture (found mostly in recent Apple Macs): > > jmatrix.cpp:50:8: runtime error: load of misaligned address 0x7ffdb159b8c2 > for type 'indextype', which requires 4 byte alignment > 0x7ffdb159b8c2: note: pointer points here > 00 00 00 fa 06 00 00 00 08 00 00 00 07 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 > > This seems to be a particularity of the compiler used by the CRAN sever for > this architecture, which does not like > to have 4-byte variables (indextype is a typedef I use for unsigned long) > aligned to non-multiple of 4 addresses. > > The original code which provoked this error was: > > // header was a pointer to unsigned char and header+2 points to safely > allocated memory > indextype *t; > t=(indextype *)(header+2); > > The solution was: > > Assuming that in all platforms the compiler will align properly simple > variable declarations, > we will use a variable instead of a pointer: > > indextype t=0; // This should be aligned, I hope.. > unsigned char *t1; > t1=header+2; > memcpy((void *)&t,(void *)t1,size_t(sizeof(indextype))); > > Another possible solution would have involved the use of the libc function > posix_memalign, but after > a web search it seems that it is not widely available in Windows and OSX. > > Even this is a really rare situation, I have preferred to document it, just > in case anyone else may benefit of the information. > > Juan > > -- > ________________________________________________________________ > Juan Domingo Esteve > Dept. of Informatics, School of Engineering > University of Valencia > Avda. de la Universidad, s/n. > 46100-Burjasot (Valencia) > SPAIN > > Telephone: +34-963543572 > Fax: +34-963543550 > email: juan.domi...@uv.es > ________________________________________________________________ > _______________________________________________ > Rcpp-devel mailing list > Rcpp-devel@lists.r-forge.r-project.org > https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel _______________________________________________ Rcpp-devel mailing list Rcpp-devel@lists.r-forge.r-project.org https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/rcpp-devel
