remove/rewrite some particularly verbose comments

This commit is contained in:
Lynne Megido 2022-01-23 03:18:25 +10:00
parent fc45376673
commit 162ed80e1e
Signed by: lynnesbian
GPG Key ID: F0A184B5213D9F90
3 changed files with 5 additions and 13 deletions

View File

@ -68,19 +68,16 @@ cfg_if! {
// Mach-O Binaries (The executable format used by macOS)
// my source for most of this info is this article: https://h3adsh0tzz.com/2020/01/macho-file-format/
// like linux's ELF binaries, mach-o binaries do not typically have an extension, but if they did, it'd
// probably be something like ".macho", so, that'll do i guess. fif doesn't actually use the extensions
// specified here anyway.
info.add("application/x-mach-binary", "macho", |buf| {
// a 32-bit mach-o header occupies 28 bits of space, so any input smaller than that cannot be a mach-o
// binary, even if it starts with the magic numbers.
// the three magic numbers that can appear are 0xFEEDFACF, 0xFEEDFACE, and 0xCAFEBABE. the code below
// checks for all three of these, in both big and little endian order.
// java class files also start with 0xCAFEBABE. since infer doesn't support detecting these files,
// collisions are not an issue. if, however, infer does gain support for identifying java class files, the
// 0xCAFEBABE check should be removed, as java bytecode files are far more prevalent than 32-bit universal
// mach-o binaries [citation needed].
// check for magic numbers (0xFEEDCACF, 0xFEEDFACE, 0xCAFEBABE) in both big and little endian forms
buf.len() >= 28 && [b"\xFE\xED\xFA\xCF", b"\xFE\xED\xFA\xCE", b"\xCA\xFE\xBA\xBE", b"\xCF\xFA\xED\xFE",
b"\xCE\xFA\xED\xFE", b"\xBE\xBA\xFE\xCA"].iter().any(|magic_numbers| buf.starts_with(&magic_numbers[..]))
});
@ -94,8 +91,7 @@ cfg_if! {
// Scalable Vector Graphics
info.add("image/svg+xml", "svg", |buf| {
// before doing the moderately expensive SVG check, we should make sure that the input is actually SGML-ish,
// by which i mean, starts with anywhere from zero to ∞-1 whitespace characters, and then a less than sign,
// and then there's some other stuff we don't care about right now
// by which i mean, starts with the pattern "\s*<".
// so, here comes our fancy pants """""SGML-ish validator"""""
for c in buf {

View File

@ -80,10 +80,8 @@ pub struct Parameters {
#[clap(long, requires = "fix")]
pub overwrite: bool,
// NOTE: clap's comma-separated argument parser makes it impossible to specify extensions with commas in their name -
// `-e sil\,ly` is treated as ["sil", "ly"] rather than as ["silly"], no matter how i escape the comma (in bash,
// anyway). is this really an issue? it does technically exclude some perfectly valid extensions, but i've never seen
// a file extension with a comma in its name before.
// NOTE: it is impossible (as far as i can tell) to accept extensions with commas in their name. i don't know why
// you would ever want a file named something like "example.xy,z", though... fif's -e and -x flags don't support this.
/// Only examine files with these extensions.
/// Multiple extensions can be specified by either using the flag multiple times (`-e jpg -e png -e gif`), or by
/// separating them with commas (`-e jpg,png,gif`).

View File

@ -130,8 +130,6 @@ fn simple_directory() {
for (result, canonical_result) in results.iter().zip(canonical_results.iter()) {
// there should be no IO errors during this test. any IO errors encountered are outside the scope of this test.
// let result = result.as_ref().expect("Error while scanning file");
// let canonical_result = canonical_result.as_ref().expect("Error while scanning file");
// paths should be canonical
assert_eq!(canonicalize(&result.file).unwrap(), canonical_result.file);