Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: Return values of fork() (Was: C idioms (Was: >< swap operator)) Date: Wed, 10 Oct 2018 16:15:59 -0700 Organization: None to speak of Lines: 22 Message-ID: References: <36d546c5-b471-45fc-b87a-8ebebdc0c0b7@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="714f42ca66b42b5b4f6239780ef2faa7"; logging-data="16131"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/eS4s5TtJJGXcH8LbitEjc" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:Lmnqb5cVmQZh1g7DwfVKyFRdjxk= sha1:WkQgLLjJ+YlzYPhx4Ro5jRxV92I= Xref: csiph.com comp.lang.c:136598 David Brown writes: [...] > POSIX is a common standard, but it does not have a monopoly on the name > "fork" or a function for that purpose. It is entirely reasonable to > conceive of a different multi-tasking OS that allows you to fork() > processes, and for which the "fork" function acts like POSIX "fork" in > normal cases but can give a range of error codes on failure. There would be no good reason to do so. fork() sets errno on failure. A version that returns a value other than -1 on failure would break existing code that checks that value. Defining a function named "fork" that behaves differently would make sense only in the context of an operating system that doesn't even pretend to have anything to do with POSIX. (Even so, it might be a good idea to call it something other than "fork" to avoid confusion.) -- Keith Thompson (The_Other_Keith) kst-u@mib.org Working, but not speaking, for JetHead Development, Inc. "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"