struct flock is posix defined locking mechanism on *nix platform

Example usage (copied from https://gavv.github.io/articles/file-locks/) :

  #include <fcntl.h>

  struct flock fl;
  memset(&fl, 0, sizeof(fl));

  // lock in shared mode
  fl.l_type = F_RDLCK;

  // lock entire file
  fl.l_whence = SEEK_SET; // offset base is start of the file
  fl.l_start = 0;         // starting offset is zero
  fl.l_len = 0;           // len is zero, which is a special value representing end
                        // of file (no matter how large the file grows in future)

  fl.l_pid = 0; // F_SETLK(W) ignores it; F_OFD_SETLK(W) requires it to be zero

  // F_SETLKW specifies blocking mode
  if (fcntl(fd, F_SETLKW, &fl) == -1) {
    exit(1);
  }

  // atomically upgrade shared lock to exclusive lock, but only
  // for bytes in range [10; 15)
  //
  // after this call, the process will hold three lock regions:
  //  [0; 10)        - shared lock
  //  [10; 15)       - exclusive lock
  //  [15; SEEK_END) - shared lock
  fl.l_type = F_WRLCK;
  fl.l_start = 10;
  fl.l_len = 5;

  // F_SETLKW specifies non-blocking mode
  if (fcntl(fd, F_SETLK, &fl) == -1) {
      exit(1);
  }

  // release lock for bytes in range [10; 15)
  fl.l_type = F_UNLCK;

  if (fcntl(fd, F_SETLK, &fl) == -1) {
      exit(1);
  }

  // close file and release locks for all regions
  // remember that locks are released when process calls close()
  // on any descriptor for a lock file
  close(fd);

Ld library path

See merge request redox-os/relibc!279

Get rid of assembly code in call_inits_finis

See merge request !282

Socket fix

See merge request redox-os/relibc!281

Rust's TcpListener fails because of the address format being wrong. The format
comes from `accept`, but there we internally use this function.

Headers

See merge request !280

This was triggered by gcc for some reason It included sys/types.h and
assumed sys/select.h to be there. And that seams to be the case in musl.

The problem with relibc here is that sys/types.h is are part of relibc
"include/*.h" files, while sys/select.h is generated by cbindgen. That
makes it impossible to #include select.h in types.h epsecially that
there are files like fcntl.c that uses types.h. They would complain
about missing headers. I fixed this by renaming sys/types.h to
sys/types_internal.h and then generating types.h using cbindgen as well
except for that. however fcntl and dlmalloc can include types_internal
instead of types.h

The problem here is that _Bool type is not defined in C++ yet this file
is using it. That leads to issues when compiling gcc. I borrowed the
same techniques used in other stdbool.h

This patch implements access function for both redox and linux and makes
sure that neither access errno variable

no name authored 4 years ago and Ahmed Abd El Mawgood committed 4 years ago

This reverts commit d9bacaec.

no name authored 4 years ago and Ahmed Abd El Mawgood committed 4 years ago

This reverts commit b0dde81c.

The main issue was not with "access" being used, it was with errno being
accessed. This patch accesses errno as well

LD_LIBRARY_PATH="/folder/with/no/libc" ./a.out

gives segfault with the following stack trace

0x00000000004d1cae in relibc::platform::sys::e (sys=18446744073709551614) at src/platform/linux/mod.rs:54
 54                  errno = -(sys as isize) as c_int;
(gdb) bt
 #0  0x00000000004d1cae in relibc::platform::sys::e (sys=18446744073709551614) at src/platform/linux/mod.rs:54
 #1  0x00000000004d361e in <relibc::platform::sys::Sys as relibc::platform::pal::Pal>::open (path=0x5555555634c0, oflag=524288, mode=0) at src/platform/linux/mod.rs:330
 #2  0x000000000049a2ad in relibc::fs::File::open (path=0x5555555634c0, oflag=524288) at src/fs.rs:28
 #3  0x0000000000482b49 in relibc::ld_so::linker::Linker::load_recursive (self=0x7fffffffdd30, name=..., path=...) at src/ld_so/linker.rs:119
 #4  0x0000000000484963 in relibc::ld_so::linker::Linker::load_library (self=0x7fffffffdd30, name=...) at src/ld_so/linker.rs:184
 #5  0x0000000000483b53 in relibc::ld_so::linker::Linker::load_data (self=0x7fffffffdd30, name=..., data=...) at src/ld_so/linker.rs:152
 #6  0x00000000004831fe in relibc::ld_so::linker::Linker::load_recursive (self=0x7fffffffdd30, name=..., path=...) at src/ld_so/linker.rs:140
 #7  0x000000000048228a in relibc::ld_so::linker::Linker::load (self=0x7fffffffdd30, name=..., path=...) at src/ld_so/linker.rs:97
 #8  0x0000000000414a3b in relibc_ld_so_start (sp=0x7fffffffe310, ld_entry=4198896) at src/ld_so/start.rs:182
 #9  0x0000000000401209 in _start () at src/ld_so/src/lib.rs:10
 #10 0x0000000000000001 in ?? ()
 #11 0x00007fffffffe592 in ?? ()
 #12 0x0000000000000000 in ?? ()

netdb: implement getnetbynane and getnetent

See merge request !278

This patch implements getnetbyname and getnetent functions.

Scanf

See merge request !277

This is the behavior of glibc which I assume to be right

The LookAheadReader api works similar to read but it has 2 methods,
lookahead: it will read 1 byte (with internal ftell) without modifying
the file's own ftell() and commit() which saves the current file ftell

LookAheadReader can wrap both buffers and files

FIX error: right operand of shift expression '(1 << BLA)' is greater than or...

See merge request !276

no name authored 4 years ago and Ahmed Abd El Mawgood committed 4 years ago

FIX error: right operand of shift expression '(1 << BLA)' is greater than or equal to the precision BLA of the left operand [-fpermissive]

Ld library path

See merge request !275

During early parts of ld.so, errno and other thread local variables are
not yet initialized so we cannot use function (such as unistd::access)
that depends on such thread local variables (errno). For this reason
this patch creates small wrapper around the syscall that doesn't not
touch the errno

Current LD_LIBRARY_PATH implementation overwrites the original search
path, which is not the best idea, instead this patch would check
LD_LIBRARY_PATH first and if it didn't find the libraries it is looking
for, then it will search the original search path

Don't accept null pointer in tests when requesting aligned memory

See merge request redox-os/relibc!272

Minor fixes to posix_memalign()

See merge request redox-os/relibc!271