On Sun, 19 Aug 2012 22:23:47 -0400, Lew Pitcher wrote:
>> I suppose that fork() belongs in the same boat.
> ITYM execlp() and friends
No, that belongs in the "never returns to its caller" boat.
> fork() always returns to the caller
Usually twice, only the second "caller" is in a process which didn't even
exist when fork() was called.
Ralph Spitzner <(E-Mail Removed)> writes:
> Keith Thompson wrote:
>> the compiler is not required to diagnose the error -- but neither is it
>> required to generate any code for the printf() call. (And with gcc, it
>> can produce no output or crash with a segmentation fault, depending on
>> the optimization level).
> Ok, got it now, sorry Willem too, didn't mean to offend.
> Maybe I'm just getting old, not seeing advantages of
> this or that keyword/qualifier
In general, the advantage of such qualifiers (restrict, noreturn
-- even register) is to give more information to the compiler.
In most cases, the compiler is free to ignore that information,
but it provides an opportunity for optimization.
In many cases, the information is in the form of a promise made
by the programmer to the compiler. The compiler is free to rely
on that promise -- and if the programmer has lied (e.g., using
`noreturn` on a function that does return to its caller), then the
compiler can take bloody revenge (or, more realistically, generate
code that doesn't behave as it would in the absence of the promise).