divinity76

yeah that would be bad. however, i believe the kernel won't do that..? it would already be in memory, the kernel could probably get those bytes from there, from it's...

im just GUESSING, and, testing needs to be done to be sure. proc1 want to read sector 1-10 kernel sends a read request to the BD (request not yet finished)...

is it possible the kernel would just have lied to the other programs and given them what proc 4 wanted to write, rather than what was actually on the BD?...

(but, if the kernel just issues the write request for proc 4 instantly, and don't want to lie to the other processes about what was actually on the BD at...

IMO faking support is better than not supporting Windows at all, but why do we need to fake it? is adding real support much more difficult or something? (i'm not...

this is related to issue #18 (an issue that has been, in my opinion, *erroneously* closed)

i just skimmed through https://tools.ietf.org/html/rfc4918#section-9.2 , and concluded that adding proper PROPPATCH support is certainly non-trivial. thanks for sharing!

ps, the ip validation itself can be done with filter_var, eg `$isValidIp=(false!==filter_var($ip,FILTER_VALIDATE_IP));` edit: but cidr range validation, that will be more difficult, perhaps significantly so :/

fwiw a patch to get bison to build on newer glibc is available at https://raw.githubusercontent.com/rdslw/openwrt/e5d47f32131849a69a9267de51a30d6be1f0d0ac/tools/bison/patches/110-glibc-change-work-around.patch (bison version should absolutely be bumped, but until then..)

there's nothing actionable here. To see why this happens, read up on "mtune" and "march" here: https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html And know that local builds are built with `-march=native -mtune=native` , which risks...