On Sun, 3 Dec 2023 09:33:30 +0000 Rafael Ayala Hernandez <rafael.ayalahernan...@oist.jp> wrote:
> The binary files that are read contain just arrays of coefficients > and metadata about these. > > I would like to provide a small file of these to be used in the > examples of the man page for the functions that read them. Files can be "binary" in multiple different senses. Your files are binary in the sense that they contain data not in a plain text format. This usage is fine. PNG images and files produced by save() or saveRDS() are binary in this sense too. Files can also be "binary" in the sense that they are not human-readable source code for a computer program, but compiled executable code. *.exe's and *.dll's, *.so's and *.dylib's, and also *.jar files are binaries in this sense. The reason they are forbidden is because they are much harder to inspect than the source code they have been compiled from. It's not always so clear-cut, though. One example is R's own serialization format where one could save a function and later restore and run it. If R did not allow this, it would be much less convenient to use, despite being slightly more secure. In another example, due to a vulnerability, a binary data file (or even a text file, say, a JavaScript program) may contain an encoded computer program that the data-reading program will execute instead of reading it due to being confused. (E.g. jailbreak.me used to confuse iPhones into overwriting parts of their firmware despite that's normally not allowed for a website.) It is important to write parsers for binary and text files so that even if these files are produced by an adversary, the program reading them will not be tricked into executing program code stored inside. You should be mostly safe if you're doing this in pure R (or else R may need to be fixed). -- Best regards, Ivan ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
