Linux Newbie: Linux VS Posix Manual

Linux newbie: Linux vs POSIX manual

Basically, the linux manuals are documentation of the commands/APIs from their writers; The POSIX manuals are from the POSIX standard. Usually, the "normal" ones are shorter and terser, but deal with the specific implementation; the POSIX ones are longer and more detailed (see man 3p read), but only tell what is in the standard.

The best is to look in both.

In linux (or POSIX) function similar to win32 mem api

Read Advanced Linux Programming. Don't seek an exact equivalent in Linux for each functionality of Win32 that you know or want. Learn to natively think in Linux terms. Study free software similar to yours (see freecode or sourceforge to find some).

^{And yes, Posix or Linux vs Windows is very different, notably for their notion of processes, etc...}

You probably want mmap(2) and mprotect(2); I don't know at all Windows (so I have no idea of what HeapCreate does).

Maybe using the lower layer of cross-platform toolkits like Qt (i.e. QtCore...) or Glib (from Gtk ...) might help you.

Linux C standard library is often GNU libc (but you could use some other, e.g. MUSL libc, which is very readable IMHO). It use syscalls listed in syscalls(2) and implemented by the Linux kernel (in particular, malloc(3) is generally built above mmap(2)...).

Take the habit of studying the source code of free software if that helps you.

BTW, for an interpreter, you could consider using Boehm's conservative garbage collector...

Convert Windows library call to POSIX for Linux compatibility

POSIX has three basic permission sets:

• user: the owner of the file,
• group: the group of the file (often just the primary group the owner of the file belongs to, but not always), and
• other (a.k.a. "world"): anybody outside the file's group that also isn't the file owner

Assuming you're wanting Windows-like behavior, you'll want to set them all to read-only (i.e. remove all write permissions); this is the same thing that WINE does on Linux. This isn't straightforward in QB64 due to how much POSIX leaves up to the implementation (e.g. where st_mode appears in struct stat), so you'd want to write a DECLARE LIBRARY header that allows you to wrap the C-based functionality if you want it to work on both Linux and OS X (and any other system that QB64 can natively run on):

#define _XOPEN_SOURCE 700
#include <sys/stat.h> // chmod, stat

// Make a file read-only for all users.
// Returns 0 on success, -1 on error.
int makeReadOnlyPOSIX(const char *path)
{
    int n;
    struct stat fileInfo;
    const mode_t noWriteMask = (
        S_IRUSR | S_IRGRP | S_IROTH
        | S_IXUSR | S_IXGRP | S_IXOTH
        | S_ISUID | S_ISGID
#ifdef S_ISVTX
        | S_ISVTX
#endif
    );

    n = stat(path, &fileInfo);
    if (n == -1) return n;

    n = chmod(path, fileInfo.st_mode & noWriteMask);

    return n;
}

Your original QB64 code, however, also has a flaw: you're checking for existence of the file, then modifying the file's attributes, which is the definition of a TOCTOU vulnerability (see Example 2, the POSIX C approximate equivalent of your code).

To fix the problem, just get and set the file permissions. If there's a problem at any point, you can either verify the file exists and print an error message (or print that it doesn't exist), or you can simply print an error message, regardless of whether the file exists or not. To make the code cleaner in Windows (since GetFileAttributes& can return an error value), you might create a C function that does the same as makeReadOnlyPOSIX:

#include <windows.h>

int makeReadOnlyWindows(const char *path)
{
    DWORD attrs;
    attrs = GetFileAttributesA(path);
    if (attrs == INVALID_FILE_ATTRIBUTES)
        return -1;
    return (int)SetFileAttributesA(path, attrs & 0x01) - 1;
}

Then you can write this in your QB64 code:

$IF WIN = 0 THEN
IF makeReadOnlyPOSIX(ASCIIZ) = 0 THEN
$ELSE
IF makeReadOnlyWindows(ASCIIZ) = 0 THEN
$END IF
    PRINT "Success."
ELSE
    PRINT "Error."
END IF

Of course, I'm assuming that $IF ... THEN, $ELSE, etc. in QB64 work like the C preprocessor (i.e. generating correct output based on the evaluations of the conditions), but even if it does, you might prefer something more like this:

$IF WIN = 0 THEN
    IF makeReadOnlyPOSIX(ASCIIZ) = 0 THEN
        PRINT "Success."
    ELSE
        PRINT "Error."
    END IF
$ELSE
    IF makeReadOnlyWindows(ASCIIZ) = 0 THEN
        PRINT "Success."
    ELSE
        PRINT "Error."
    END IF
$END IF

Edit

If you wanted your code to work with the same function name, you could do the following in QB64:

$IF WIN = 0 THEN
    DECLARE LIBRARY "posixHeader"
        FUNCTION makeReadOnly ALIAS makeReadOnlyPOSIX& (fname$)
    END DECLARE
$ELSE
    DECLARE LIBRARY "winHeader"
        FUNCTION makeReadOnly ALIAS makeReadOnlyWindows& (fname$)
    END DECLARE
$END IF

That way, you can just use something like the following in your actual code:

IF makeReadOnly(ASCIIZ) = 0 THEN
    PRINT "Success."
ELSE
    PRINT "Error."
END IF

I mention this only because it's easier to maintain something where the logic isn't split between pre-compilation directives, not to mention the lack of duplication.

Launching many copies of POSIX C++ code on GPU

Is there any easy way of recompiling the code for GPU and running on "many more" GPU cores?

No

What is the easiest way to port existing boost C++ code for GPU assuming I want to run the threads as-is?

There isn't one. As noted in comments, C++17 includes parallel algorithms, and NVIDIA ship a C++17 compiler with CUDA support. That is a long way from taking a "POSIX C++" code and just running it directly on a GPU. No GPU programming paradigm I am familiar with works like that.

---

Related Topics