previous: >>108100361#define __NR_sendfile 40https://man7.org/linux/man-pages/man2/sendfile.2.htmlthis guy is pretty cool! i think i mentioned him in one of the earlier threads. quite handy for saving you the effort of all the stat, buffer, read, write nonsense.i was a bit torn about whether to include copy_file_range in today's thread, but it's distinct enough that it will get its own. it's basically the same thing, though (same for splice and tee lol). linux really loves to do that, huh? anyway, yeah, great syscall! highly recommend using it where you can. in a lot of places it's going to be just a drop in replacement.oh, one last point. the dual use of the offset argument is pretty neat. i really like that relevant resources: man manman syscallshttps://man7.org/linux/man-pages/https://linux.die.net/man/https://elixir.bootlin.com/linux/https://elixir.bootlin.com/musl/https://elixir.bootlin.com/glibc/
#define __NR_sendfile 40
copy_file_range
man man
man syscalls
>>108101019by having its semantics be simple enough that there are no error casesa more correct description in the manpage would probably be something to the effect of "There are no error cases in this function" - basically, we never expect to see an error, and we won't ever return you an errno value indicating one. i guess in a way that's what successful means here. it would be a bit more questionable if they said something like "The function is guaranteed to operate correctly">>108103187the ones you listed are probably my most actually written syscalls. getpid/gettid i use a lot under the hood, though>>108103411vdso is a meme honestly. i get why it exists, but god i hate it
>>108110059>zip bombSo it's just a small zip file that contains a massive file so you run out of space when you unzip it? Seems like a minor inconvenience at worst
>>108110116i see you've never run out of space on an old piece of shit machine lolsame goes for the classic fork-bomb:(){ :|:& };:difference is, the unzipped files will stick around after a reboot lmao
:(){ :|:& };:
>>108110241Yeah but any archiving software will warn about there not being enough disk space to unpack the file.
>>108110356do they? i don't keep up. presumably, though, with a malicious file (as per a zip bomb), it would be constructed in such a way as to mislead the archival software. or otherwise, as you say, what's the point?
>>108110059I've been waiting, tis quite late 2day! unfortunately you still need to stat the file, which is something I really don't like, because of the race condition it might invoke.so whenever you stat you pretty much always also have to lock, which is really cumbersome>>108110092>i use a lot under the hood, thoughfair enough. I rarely do user-oriented logging of that kind, cos whenever the problem exceeds simple printf-debug capabilities I attach a debugger. And I've very rarely written long-running server-kind programmes.
>>108110059Ah, yes, sendfile(2). The answer to HTTP and FTP workloads that really should've been invented by 4.4BSD already.
>>108110852>tis quite late 2day!i am sick :(>unfortunately you still need to stat the filenot strictly. you should be able to just pass a very large value into count. it'll return the number of bytes written>I rarely do user-oriented logging of that kindi wouldn't call it user oriented, really. it's getpid/gettid, not getuid. it's mostly useful for knowing when you're off in a thread
>>108110886Could trigger EOVERFLOW according strictly to the documentation.
>>108110925wow, i missed that.however, it says "the maximum size", not "the size"so that would imply to me that it's talking more about filesystem limits. i guess i can just go check the source
>>108110925>>108110942yeah, it's the max bytes possible for the inode, not the sizehttps://elixir.bootlin.com/linux/v6.18.6/source/fs/read_write.c#L1346
>>108110886>you should be able to just pass a very large value into countHUH, I suppose you're right. I like to read for small files and mmap for larger files, though, so that'd still require stat'ing.>i am sick :(that's not nice:( get well soon!>i wouldn't call it user oriented, really. it's getpid/gettid, not getuid. it's mostly useful for knowing when you're off in a threadyou are logging programme state into an external file for later reading, aren't you? I tend to just write "could not [do operation]" and then exit, retrying the entire thing with a debugger.
>>108111112often the code i work with doesn't lend itself well to debuggers (that's what i tell myself to cope with my laziness about learning gdb)
>>108111422>to cope with my laziness about learning gdbits user interface is horrible indeed to be fair to you
