Re: cvs: php4 /ext/standard file.c

> Oh. I see. I wonder though why I will want to kill my process any time > there's no place to write a file, but well - I guess that's another > product of commitee thinking. Doesn't matter now. If so, does it mean that > according to this standard, there's no way (except for blocking that > SIGXFSZ) to know if any write I attempt won't kill my application? And how > programmers are supposed to handle this? What was the thought behind this > invention? Can't we just block that signal? Or can we reset errno and > check after write if we got ENOSPC? If any data has already been written (possible in both cases as outlined above), write() will return the number of bytes and not set errno. Returning an integer result and setting errno at the same time is not possible in many Unix kernels. Historically, kernel functions return only a single integer (positive for success, negative for failure). In the latter case, the number will be negated (-ENOSPC becomes ENOSPC), assigned to errno and the application gets -1 as a result from the system call. The rationale behind SIGXFSZ seems to be that a process should be terminated, if it exceeds process limits. - Sascha