I'm here for you, OP

>>107993991
ive have never used that syscall

File: 1758076927543699.png (116 KB, 720x720)

116 KB PNG

>>107993991
Is this faster than unmapping and mapping? Is this useful for dynamic arrays?

File: 1769355561686646.gif (531 KB, 1280x1280)

531 KB GIF

>>107994702
yaaayyyyyy thank u anon ily

>>107997983
>Is this faster than unmapping and mapping?
if it is, not to a degree that matters
>Is this useful for dynamic arrays?
no, probably not

>>107993991
Do eventfd next.

bampu

i realized why i thought munmap should be part of mmap. because they're just malloc/free, and i'm used to the idea that realloc can do anything malloc and free can do. so here's realloc to complete the set.

>>107993991
>toes on the state flag
>Minnesota
We recently got a new minimal flag that looks like some gay pride shit. No more toes; shit sucks.

>>107993991
just another linux-specific syscall thats completely unneeded
linux is excellent but under da hood it really is a bit of a mess

>>107993991
>remapping memory mention
dynamic array bros we won.

>>107997983
It's much faster than mmap-copy-munmap for changing the size of a mapping, both because it never needs to do an actual copy (the size of the mapping is changed with VM trickery, even if MREMAP_MAYMOVE), and because not having to have two copies of the mapping in memory (by the end of the copy) leads to fewer cache misses and page faults.

>>108000439
see >>108000489
malloc/realloc/free requires linking CRT and setting up TLS
mmap/mremap/munmap just work

File: syscalls c.png (37 KB, 793x212)

37 KB PNG

Newb here, so apparently in C you just have access to all these syscalls out of the box, no libraries need to be imported or anything, right? But dumb question then: some kernels have different syscalls, right? So don't you limit your program's portability by writing with syscalls?

>>108000675
>in C you just have access to all these syscalls out of the box
For the most part. In some cases syscalls might not have a standard library wrapper yet, so you need to call them manually with the syscall() function.
>portability
Syscalls that are part of POSIX are available pretty much everywhere these days (including windows with WSL, though implementation quality may vary there). Syscalls that aren't part of POSIX may only be available on a particular kernel.

>>108000714
thanks for the answer. Still confused though. This UNIX util is C under the hood so the question still applies, how can this be portable when they're using different syscalls?

#example from "OS: 3EP"
prompt> strace cat foo
...
open("foo", O_RDONLY|O_LARGEFILE)
read(3, "hello\n", 4096)
write(1, "hello\n", 6)
hello
read(3, "", 4096)
close(3)

but when I do it on my Ubuntu server:

$ strace cat foo
openat(AT_FDCWD, "foo", O_RDONLY)       = 3
fstat(3, {st_mode=S_IFREG|0664, st_size=6, ...}) = 0
fadvise64(3, 0, 0, POSIX_FADV_SEQUENTIAL) = 0
mmap(NULL, 139264, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x73e1bbc5f000
read(3, "hello\n", 131072)              = 6
write(1, "hello\n", 6hello)                  = 6
read(3, "", 131072)                     = 0
munmap(0x73e1bbc5f000, 139264)          = 0
close(3)

I can see how both calls are equivalent, but still, why are they so different?

>>108000777
And I understand that AT_FDCWD in openat(AT_FDCWD, "foo", O_RDONLY) makes openat() behave exactly like open(), but there's so many other different syscalls. Again, my basic question is, doesn't this break portability?

>>107993991
I remember seeing the man page for this one before by coincidence and deciding that I would try to never use it.

>>107997983
You never need to unmap remap.
I also never bother to close or free.
Process ending takes care if it.

>>108000777
From the looks of things the second one is checking to see if it can read the file before trying to read it, is telling the OS that it intends to read the file sequentially, and is using a much larger and dynamically allocated buffer while reading, while the first cat is doing just the bare minimum. All the calls both are using are in POSIX but some of the ones used by the second one are newer additions to the standard so it's likely just two different cats written by two different authors.

>>108000675
>don't you limit your program's portability by writing with syscalls?
you are
it's a reasonable trade-off if you want performance or specific behavior that can't be achieved using what libc offers

>>108000675
nobody normal writes with just syscalls
if you are a worth a dime programmer you write a layer that abstracts os

>>108000831
generally most libraries like that will be ifdef'd for different platforms

>>108000675
>Newb here, so apparently in C you just have access to all these syscalls out of the box, no libraries need to be imported or anything, right?
false. what's documented in the syscall manpage is the libc wrapper of the syscall, which may only be distantly related to the actual underlying syscall. in order to access it you need to use a libc. libcs ship with your c compiler, so they will generally be available, but they are still a library, and need to be #included to use them. If you look at the bottom of that man page, you will notice that it ascribes it to posix (and linux, bsd, sysv, etc), not to the c standard. Hence it will be available on posix systems, but not necessarily elsewhere. Compare something like strcmp, which is ascribed to the c standard, and hence will be available using any compatible c compiler. It is still part of the libc, mind, so you still need to include it, and not disable linking the libc.

>>108003919
well, no. that's not exactly correct. you have direct access to the syscall on whatever architecture you want. you just have to write the inline assembly yourself
also, generally the man pages for syscalls are pretty good about documenting when the libc wrapper differs from the underlying linux syscall

>>108003092
>ifdef'd
not sure what this means, I can take a guess though

>>108003919
helpful post, thanks for clarifying

>>108004391
wait. I'm confused again

>>108006031
https://elixir.bootlin.com/musl/v1.2.5/source/arch/aarch64/syscall_arch.h
https://elixir.bootlin.com/musl/v1.2.5/source/arch/arm/syscall_arch.h
https://elixir.bootlin.com/musl/v1.2.5/source/arch/i386/syscall_arch.h
https://elixir.bootlin.com/musl/v1.2.5/source/arch/x32/syscall_arch.h
https://elixir.bootlin.com/musl/v1.2.5/source/arch/x86_64/syscall_arch.h

>>108006031
what are you confused about.
but also, come to the new thread

>>108007422
hmmm nyo