I don’t remember if I did read the book from doc.rust-lang.org/book or from doc.rust-lang.org/stable/book. However there are important things that they do not say, took me many days to try to figure out and I’m still not certain I got them correctly.

One simple example is how to be sure that the code I write (I’m currently using RustRover trial and the trial will end in 5 days, far less than what will make sense for me) will work on this laptop and that I can access the correct libraries.

Technically I’m using a MacBook Pro 14-inch with Apple M5 (obviously now with Tahoe 26.3) and it was hard to figure out to add libc = "1.0.0-alpha.3" after [dependencies] in my project Cargo.toml file. As a fact I’m also not certain it’s fully correct. With my C code (using Xcode) is easy to call lstat in code I write in a .c file that did #include <sys/stat.h> which declares int lstat(const char *, struct stat *) __DARWIN_INODE64(lstat);

However the biggest problem I’m having is with RadDir from fs::read_dir (also was hard to figure out that use std::fs; is not enough and try something adding use std::os::unix::fs::DirEntryExt;) because what is most important for me simply doesn't happen (or happens in the wrong way).

Limited example of my C code (obviously the dots stand for parts of the source I’m not copying as is not useful here):

....
#include <dirent.h>
....
DirEntries* readDir(const char* dirPath __attribute__((nonnull))) {
  DIR *dir = opendir(dirPath);
  ....
  DirEntries* dep = calloc(1, sizeof(DirEntry*));
  ....
  struct dirent *ent = readdir(dir);
  while (ent != NULL) {
    // add a new entry to *dep
    .... = newDirEntry(ent->d_name, ent->d_ino, ent->d_type);
    ....
    ent = readdir(dir);
  }
  closedir(dir);
  ....
  return dip;

}

I’m not getting all elements of struct dirent but it should be clear that I’m getting, and later using, d_type as a value (technically it’s a uint8_t with values from 0 to 14) and getting it as an unsigned integer value in rust … didn’t even figured out how to. It’s also clear that I’m getting all the childs (not sorted) of the directory and this is also impossible in rust.

Here is a list of 2 things (likely limited given I’m new and didn’t check everything) that I consider wrong in rust:

• A readable directory has at least two entries, the first is named “.” and refer to the same directory and the second is named “..” and refer to the parent. This is all not always true. It’s possible that they are not named like that, possible that they do not refer to that, possible that a directory is readable and has less than two entries. What is extremely common is not necessary always true.
• The d_type value is useless as a value because it identify alternatives and is different depending on the system therefore is much better to give access to checks of which alternative is there. This is also quite stupid. It is a value, just 4 bits but it is an unsigned integer. Give me an integer (even signed if you want as long as it’s >= 0 and, currently in my system, <= 14). I will take care of it. Just like I will take care of st_mode in struct stat (please leave it as uint16_t so it’s easy to shift it right by 12).

Basically making things like managing pointers better is a good idea but making impossible to access what really would work with no troubles like getting d_type as an integer value and getting info to first elements of directories (most of the times “.” and “..”) is definitely one of the reasons it may be currently useless to study rust. And I haven’t yet started to verify a path is managed correctly in all cases (including . and .. elements anywhere in the path which is then passed to a C function as a char*) and also not started to verify things like listxattr and getxattr (etc etc to setxattr …)

If I simply lost some info and what I wrote is wrong I hope I’ll find it in some reply.

3 posts - 3 participants

Read full topic