Error checking with execlp() - Unix

This is a discussion on Error checking with execlp() - Unix ; In article , phil-news-nospam@ipal.net wrote: > On Mon, 30 Jun 2008 21:06:42 -0400 Barry Margolin > wrote: > | In article , phil-news-nospam@ipal.net > | wrote: > | > |> On Sun, 29 Jun 2008 23:02:13 -0400 Barry Margolin > ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 34 of 34

Thread: Error checking with execlp()

  1. Re: Error checking with execlp()

    In article , phil-news-nospam@ipal.net
    wrote:

    > On Mon, 30 Jun 2008 21:06:42 -0400 Barry Margolin
    > wrote:
    > | In article , phil-news-nospam@ipal.net
    > | wrote:
    > |
    > |> On Sun, 29 Jun 2008 23:02:13 -0400 Barry Margolin
    > wrote:
    > |> | In article <871w2gqufl.fsf@fever.mssgmbh.com>,
    > |> | Rainer Weikusat wrote:
    > |>
    > |> [...]
    > |>
    > |> |> I see no real difference between
    > |> |>
    > |> |> rc = execlp("program", "program", (char *)0);
    > |> |> if (rc == -1) ...
    > |> |>
    > |> |> and
    > |> |>
    > |> |> a = 3;
    > |> |> if (a == 3) ...
    > |> |>
    > |> |
    > |> | That's ridiculous. a = 3 doesn't do anything other than set a to 3.
    > |>
    > |> I think the point is that in both cases the conditional is unneeded. In
    > the
    > |> latter case I would expect the compiler to remove the conditional for all
    > but
    > |> the leaset level of optimization (and even then I would not be surprised).
    > |> In the former case, a compiler built _for_ a POSIX environment might do it
    > |> there as well, especially at higher optimizations.
    > |
    > | Are you really concerned about optimizing the error case of a program?
    > | 99% of the time the error handling code after a call to exec() will
    > | never be run. And when it is, do we really care how quickly it reports
    > | the error?
    >
    > It's not about _wanting_ optimization; it's about the fact that optimization
    > (even when it's unimportant) showing you want isn't doing anything useful.
    > The optimization has to still be correct. If something gets optimized out,
    > then it was "correct" (in the sense that the code does the same thing, not
    > necessarily in well written code) to leave out that code.


    Are you saying that any time the compiler is able to rewrite your code
    with an optimization, you've written bad code?

    The point of compiler optimizations is to save us from having to deal
    with all sorts of minutiae. And that's what I think this argument we're
    having is about: an unimportant detail. No harm comes from checking the
    return value of exec(). It's redundant, that's all.

    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    *** PLEASE don't copy me on replies, I'll read them in the group ***

  2. Re: Error checking with execlp()

    On Thu, 03 Jul 2008 00:07:52 -0400 Barry Margolin wrote:
    | In article , phil-news-nospam@ipal.net
    | wrote:
    |
    |> On Mon, 30 Jun 2008 21:06:42 -0400 Barry Margolin
    |> wrote:
    |> | In article , phil-news-nospam@ipal.net
    |> | wrote:
    |> |
    |> |> On Sun, 29 Jun 2008 23:02:13 -0400 Barry Margolin
    |> wrote:
    |> |> | In article <871w2gqufl.fsf@fever.mssgmbh.com>,
    |> |> | Rainer Weikusat wrote:
    |> |>
    |> |> [...]
    |> |>
    |> |> |> I see no real difference between
    |> |> |>
    |> |> |> rc = execlp("program", "program", (char *)0);
    |> |> |> if (rc == -1) ...
    |> |> |>
    |> |> |> and
    |> |> |>
    |> |> |> a = 3;
    |> |> |> if (a == 3) ...
    |> |> |>
    |> |> |
    |> |> | That's ridiculous. a = 3 doesn't do anything other than set a to 3.
    |> |>
    |> |> I think the point is that in both cases the conditional is unneeded. In
    |> the
    |> |> latter case I would expect the compiler to remove the conditional for all
    |> but
    |> |> the leaset level of optimization (and even then I would not be surprised).
    |> |> In the former case, a compiler built _for_ a POSIX environment might do it
    |> |> there as well, especially at higher optimizations.
    |> |
    |> | Are you really concerned about optimizing the error case of a program?
    |> | 99% of the time the error handling code after a call to exec() will
    |> | never be run. And when it is, do we really care how quickly it reports
    |> | the error?
    |>
    |> It's not about _wanting_ optimization; it's about the fact that optimization
    |> (even when it's unimportant) showing you want isn't doing anything useful.
    |> The optimization has to still be correct. If something gets optimized out,
    |> then it was "correct" (in the sense that the code does the same thing, not
    |> necessarily in well written code) to leave out that code.
    |
    | Are you saying that any time the compiler is able to rewrite your code
    | with an optimization, you've written bad code?

    No. I'm saying that the code that was omitted by the compiler was not needed.


    | The point of compiler optimizations is to save us from having to deal
    | with all sorts of minutiae. And that's what I think this argument we're
    | having is about: an unimportant detail. No harm comes from checking the
    | return value of exec(). It's redundant, that's all.

    True, that is the point of compiler optimization. But optimization also does
    provide a comparative side effect: it lets us see what could have been done
    differently. That does NOT mean we _should_ do it differently, just that it
    would still be correct if we did.

    My argument is that omitting the test of the return value of execve() is just
    as correct when the programmer writes the code as when the compiler generates
    machine language. Assuming it would (and maybe it doesn't), then the real
    question is whether it is good programming practice to do so. I personally
    do omit the test of the return value, and move straight on to testing errno.
    I do that because I know the return value of execve() is effectively defined
    as a constant.

    --
    |WARNING: Due to extreme spam, googlegroups.com is blocked. Due to ignorance |
    | by the abuse department, bellsouth.net is blocked. If you post to |
    | Usenet from these places, find another Usenet provider ASAP. |
    | Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) |

  3. Re: Error checking with execlp()

    Barry Margolin writes:

    [...]

    > And that's what I think this argument we're having is about: an
    > unimportant detail. No harm comes from checking the
    > return value of exec(). It's redundant, that's all.


    Something being provably useless is not an argument for its
    inclusion into anything, especially taking into account that human
    work is needed to include it in the first place and that it has the
    side effect of causing more useless human work in future.

    That 'some people' see the main problem in 'programing' in trying to
    somehow coax a computer into doing what they want him to do is an
    apprentice's (or dilettante's) lack of perspective. The actual problem
    is 'write something which can still be used ten years from now to be a
    base for solving a related-but-different task'. And, of course,
    'something which is easy to fix whenever a yet unknown functional
    defect is discovered', ie when someone (possibly not even the original
    author of the code) has to again (or for the first time) take a closer
    look at it a couple of months or years after it was originally
    constructed in a certain way.

    Eg, I spent most of my workday yesterday with turning 'some version'
    of the bustybugs-init into a full-fledged process monitor. There is
    still at least one known defect in the present code because I haven't
    (yet) been able to determine a particular 'irrelevant detail' about
    its behaviour. If less of this code had been 'caused' by a general
    lack of knowledge regarding the behaviour of UNIX(*)-systems[*] and
    stayed in there 'because it was merely redundant', this would have
    been a lot less work to do.

    I guess your theory would be that I should rather reverse compile the
    'opitmized' machine code or work directly with the compiler assembly
    output ...
    [*] Two striking example would be 'block SIGCHLD during fork'
    (comment text) in a program which does not handle SIGCHLD,
    meaning, it is never generated, and defining a handler for
    SIGSTOP (cannot be handled).

  4. Re: Error checking with execlp()

    On Thu, 03 Jul 2008 08:56:57 +0200 Rainer Weikusat wrote:

    |[*] Two striking example would be 'block SIGCHLD during fork'
    | (comment text) in a program which does not handle SIGCHLD,
    | meaning, it is never generated, and defining a handler for
    | SIGSTOP (cannot be handled).

    Oh, you're getting close to my IRC exit message :-)

    "sighandler: unknown signal received: SIGKILL (9)"

    Can you spot the programming error here:

    int rc;
    rc = execlp("program", "program", (char *)0);
    if ( rc == 0 ) {
    fprintf( stderr, "program successfully executed\n" );
    return 0;
    }
    if ( rc == -1 ) {
    perror( "unable to execute program" );
    }
    else {
    fprintf( stderr, "unrecognized return code from execlp(): %u\", rc );
    }
    return 1;

    --
    |WARNING: Due to extreme spam, googlegroups.com is blocked. Due to ignorance |
    | by the abuse department, bellsouth.net is blocked. If you post to |
    | Usenet from these places, find another Usenet provider ASAP. |
    | Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) |

  5. Re: Error checking with execlp()

    On 3 Jul 2008 13:13:35 GMT, phil-news-nospam@ipal.net wrote:
    > On Thu, 03 Jul 2008 08:56:57 +0200 Rainer Weikusat wrote:
    >
    > |[*] Two striking example would be 'block SIGCHLD during fork'
    > | (comment text) in a program which does not handle SIGCHLD,
    > | meaning, it is never generated, and defining a handler for
    > | SIGSTOP (cannot be handled).
    >
    > Oh, you're getting close to my IRC exit message :-)
    >
    > "sighandler: unknown signal received: SIGKILL (9)"
    >
    > Can you spot the programming error here:
    >
    > int rc;
    > rc = execlp("program", "program", (char *)0);
    > if ( rc == 0 ) {
    > fprintf( stderr, "program successfully executed\n" );
    > return 0;
    > }
    > if ( rc == -1 ) {
    > perror( "unable to execute program" );
    > }
    > else {
    > fprintf( stderr, "unrecognized return code from execlp(): %u\", rc );
    > }
    > return 1;


    Which one of them all?

    I can see at least the following:

    * The if (rc == 0) { ... } code is unreachable, since by definition
    execlp() will never return to the caller if it succeeds.

    * There's a missing 'else' between the two first if condition checks.
    This means that in the hypothetical scenario that execlp() would in
    fact return zero, the first if-block would run and the final else
    part would be unreachable code.

    * If execlp() fails the else-part is unreachable, because it is
    defined to always return -1 on failure.

    * If execlp() fails the final return 1 is executed. But return where?
    Ok, this is not really an error, but it's definitely something more
    related to the internal design of the execlp() API consumer; not
    really something _required_ by execlp() itself.

    All of the above checks can be usually replaced with a simple check like:

    #include
    #include

    const char *pname = "program";
    int rc;

    if (execlp(pname, pname, (char *)0) == -1) {
    fprintf(stderr, "cannot execlp \"%s\"\n", pname);
    return 1;
    }

    That's all...

    On success execlp() will, by definition, NOT return at all. On failure,
    it will, again by definition, return -1. I don't see why you would feel
    obliged to check for any other return value, unless you suspect that the
    system version of execlp() is bogus/broken/wrong.


  6. Re: Error checking with execlp()

    In article , phil-news-nospam@ipal.net
    wrote:

    > On Thu, 03 Jul 2008 00:07:52 -0400 Barry Margolin
    > wrote:
    > | In article , phil-news-nospam@ipal.net
    > | wrote:
    > |
    > |> On Mon, 30 Jun 2008 21:06:42 -0400 Barry Margolin
    > |> wrote:
    > |> | In article , phil-news-nospam@ipal.net
    > |> | wrote:
    > |> |
    > |> |> On Sun, 29 Jun 2008 23:02:13 -0400 Barry Margolin
    > |> wrote:
    > |> |> | In article <871w2gqufl.fsf@fever.mssgmbh.com>,
    > |> |> | Rainer Weikusat wrote:
    > |> |>
    > |> |> [...]
    > |> |>
    > |> |> |> I see no real difference between
    > |> |> |>
    > |> |> |> rc = execlp("program", "program", (char *)0);
    > |> |> |> if (rc == -1) ...
    > |> |> |>
    > |> |> |> and
    > |> |> |>
    > |> |> |> a = 3;
    > |> |> |> if (a == 3) ...
    > |> |> |>
    > |> |> |
    > |> |> | That's ridiculous. a = 3 doesn't do anything other than set a to 3.
    > |> |>
    > |> |> I think the point is that in both cases the conditional is unneeded.
    > In
    > |> the
    > |> |> latter case I would expect the compiler to remove the conditional for
    > all
    > |> but
    > |> |> the leaset level of optimization (and even then I would not be
    > surprised).
    > |> |> In the former case, a compiler built _for_ a POSIX environment might do
    > it
    > |> |> there as well, especially at higher optimizations.
    > |> |
    > |> | Are you really concerned about optimizing the error case of a program?
    > |> | 99% of the time the error handling code after a call to exec() will
    > |> | never be run. And when it is, do we really care how quickly it reports
    > |> | the error?
    > |>
    > |> It's not about _wanting_ optimization; it's about the fact that
    > optimization
    > |> (even when it's unimportant) showing you want isn't doing anything useful.
    > |> The optimization has to still be correct. If something gets optimized
    > out,
    > |> then it was "correct" (in the sense that the code does the same thing, not
    > |> necessarily in well written code) to leave out that code.
    > |
    > | Are you saying that any time the compiler is able to rewrite your code
    > | with an optimization, you've written bad code?
    >
    > No. I'm saying that the code that was omitted by the compiler was not
    > needed.


    That's what "redundant" means.

    Just because it's "correct" to leave something out, it doesn't mean that
    it's "incorrect" to include it. Unnecessary, yes, but not incorrect.

    >
    >
    > | The point of compiler optimizations is to save us from having to deal
    > | with all sorts of minutiae. And that's what I think this argument we're
    > | having is about: an unimportant detail. No harm comes from checking the
    > | return value of exec(). It's redundant, that's all.
    >
    > True, that is the point of compiler optimization. But optimization also does
    > provide a comparative side effect: it lets us see what could have been done
    > differently. That does NOT mean we _should_ do it differently, just that it
    > would still be correct if we did.
    >
    > My argument is that omitting the test of the return value of execve() is just
    > as correct when the programmer writes the code as when the compiler generates
    > machine language.


    No one is arguing that you must check the return value. It's OK to
    leave out the check. This whole subthread started because people said
    it was wrong that the OP included the check.

    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    *** PLEASE don't copy me on replies, I'll read them in the group ***

  7. Re: Error checking with execlp()

    Giorgos Keramidas writes:

    [...]

    > #include
    > #include
    >
    > const char *pname = "program";
    > int rc;
    >
    > if (execlp(pname, pname, (char *)0) == -1) {
    > fprintf(stderr, "cannot execlp \"%s\"\n", pname);
    > return 1;
    > }
    >
    > That's all...
    >
    > On success execlp() will, by definition, NOT return at all. On failure,
    > it will, again by definition, return -1. I don't see why you would feel
    > obliged to check for any other return value, unless you suspect that the
    > system version of execlp() is bogus/broken/wrong.


    This is less overloaded with code blocks which will never be executed,
    but just doing

    execlp(pname, pnname, (char *)0);

    perror("execlp");
    _exit(1);

    would be entirely sufficient.

  8. Re: Error checking with execlp()

    In article <87zloyk002.fsf@kobe.laptop>,
    Giorgos Keramidas wrote:

    > On 3 Jul 2008 13:13:35 GMT, phil-news-nospam@ipal.net wrote:
    > > On Thu, 03 Jul 2008 08:56:57 +0200 Rainer Weikusat
    > > wrote:
    > >
    > > |[*] Two striking example would be 'block SIGCHLD during fork'
    > > | (comment text) in a program which does not handle SIGCHLD,
    > > | meaning, it is never generated, and defining a handler for
    > > | SIGSTOP (cannot be handled).
    > >
    > > Oh, you're getting close to my IRC exit message :-)
    > >
    > > "sighandler: unknown signal received: SIGKILL (9)"
    > >
    > > Can you spot the programming error here:
    > >
    > > int rc;
    > > rc = execlp("program", "program", (char *)0);
    > > if ( rc == 0 ) {
    > > fprintf( stderr, "program successfully executed\n" );
    > > return 0;
    > > }
    > > if ( rc == -1 ) {
    > > perror( "unable to execute program" );
    > > }
    > > else {
    > > fprintf( stderr, "unrecognized return code from execlp(): %u\", rc
    > > );
    > > }
    > > return 1;

    >
    > Which one of them all?
    >
    > I can see at least the following:
    >
    > * The if (rc == 0) { ... } code is unreachable, since by definition
    > execlp() will never return to the caller if it succeeds.


    What if there's a bug in the execlp() implementation? The else-clause
    above seems to be trying to protect against implementations that don't
    follow the spec.

    However, I think the rc==0 case should be subsumed into that
    else-clause. execlp() should never return 0, so why would you consider
    that to be successful?

    >
    > * There's a missing 'else' between the two first if condition checks.


    It's not needed because the first if block contains a return statement.

    > This means that in the hypothetical scenario that execlp() would in
    > fact return zero, the first if-block would run and the final else
    > part would be unreachable code.
    >
    > * If execlp() fails the else-part is unreachable, because it is
    > defined to always return -1 on failure.


    But what if the OS programmer made a mistake?

    While application programmers normally assume the OS does what it's
    supposed to do, what's wrong with defensive programming? Some types of
    failures are difficult to protect against (it would be silly to check
    that every write() successfully did its job, although backup programs
    often include a "verify" option), but this is an easy case.

    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    *** PLEASE don't copy me on replies, I'll read them in the group ***

  9. Re: Error checking with execlp()

    On Thu, 03 Jul 2008 22:58:01 -0400 Barry Margolin wrote:

    |> No. I'm saying that the code that was omitted by the compiler was not
    |> needed.
    |
    | That's what "redundant" means.
    |
    | Just because it's "correct" to leave something out, it doesn't mean that
    | it's "incorrect" to include it. Unnecessary, yes, but not incorrect.

    I'm not saying that it is incorrect to include it. I'm just saying that it
    is correct to not include it. I choose to not include it (see my previous
    posts) and I assert that doing so is correct.


    |> | The point of compiler optimizations is to save us from having to deal
    |> | with all sorts of minutiae. And that's what I think this argument we're
    |> | having is about: an unimportant detail. No harm comes from checking the
    |> | return value of exec(). It's redundant, that's all.
    |>
    |> True, that is the point of compiler optimization. But optimization also does
    |> provide a comparative side effect: it lets us see what could have been done
    |> differently. That does NOT mean we _should_ do it differently, just that it
    |> would still be correct if we did.
    |>
    |> My argument is that omitting the test of the return value of execve() is just
    |> as correct when the programmer writes the code as when the compiler generates
    |> machine language.
    |
    | No one is arguing that you must check the return value. It's OK to
    | leave out the check. This whole subthread started because people said
    | it was wrong that the OP included the check.

    It's merely unneeded.

    --
    |WARNING: Due to extreme spam, googlegroups.com is blocked. Due to ignorance |
    | by the abuse department, bellsouth.net is blocked. If you post to |
    | Usenet from these places, find another Usenet provider ASAP. |
    | Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) |

  10. Re: Error checking with execlp()

    On Fri, 04 Jul 2008 02:42:53 +0300 Giorgos Keramidas wrote:
    | On 3 Jul 2008 13:13:35 GMT, phil-news-nospam@ipal.net wrote:
    |> On Thu, 03 Jul 2008 08:56:57 +0200 Rainer Weikusat wrote:
    |>
    |> |[*] Two striking example would be 'block SIGCHLD during fork'
    |> | (comment text) in a program which does not handle SIGCHLD,
    |> | meaning, it is never generated, and defining a handler for
    |> | SIGSTOP (cannot be handled).
    |>
    |> Oh, you're getting close to my IRC exit message :-)
    |>
    |> "sighandler: unknown signal received: SIGKILL (9)"
    |>
    |> Can you spot the programming error here:
    |>
    |> int rc;
    |> rc = execlp("program", "program", (char *)0);
    |> if ( rc == 0 ) {
    |> fprintf( stderr, "program successfully executed\n" );
    |> return 0;
    |> }
    |> if ( rc == -1 ) {
    |> perror( "unable to execute program" );
    |> }
    |> else {
    |> fprintf( stderr, "unrecognized return code from execlp(): %u\", rc );
    |> }
    |> return 1;
    |
    | Which one of them all?
    |
    | I can see at least the following:
    |
    | * The if (rc == 0) { ... } code is unreachable, since by definition
    | execlp() will never return to the caller if it succeeds.
    |
    | * There's a missing 'else' between the two first if condition checks.
    | This means that in the hypothetical scenario that execlp() would in
    | fact return zero, the first if-block would run and the final else
    | part would be unreachable code.

    The first (although unreachable) if-block ends with a return. So the
    else is not needed. This is how I code. If an if-block contains a
    return, continue, or even a goto (yes, I use those for certain specific
    reasons), I don't code an else on a subsequent if-block since it won't
    fall through.


    | * If execlp() fails the else-part is unreachable, because it is
    | defined to always return -1 on failure.
    |
    | * If execlp() fails the final return 1 is executed. But return where?
    | Ok, this is not really an error, but it's definitely something more
    | related to the internal design of the execlp() API consumer; not
    | really something _required_ by execlp() itself.
    |
    | All of the above checks can be usually replaced with a simple check like:
    |
    | #include
    | #include
    |
    | const char *pname = "program";
    | int rc;
    |
    | if (execlp(pname, pname, (char *)0) == -1) {
    | fprintf(stderr, "cannot execlp \"%s\"\n", pname);
    | return 1;
    | }
    |
    | That's all...
    |
    | On success execlp() will, by definition, NOT return at all. On failure,
    | it will, again by definition, return -1. I don't see why you would feel
    | obliged to check for any other return value, unless you suspect that the
    | system version of execlp() is bogus/broken/wrong.

    The posted code was not an example of anything I feel obligated to code.
    Instead, it was an example to ponder for various errors.

    BTW, there was another error inserted, which you can avoid considering if
    the last else-clause is being discarded. That error is using a "%u" format
    for an int. It should be a "%d" format. If someone had chosen to accept
    the last else-clause, then they should have at least caught that error (why
    I put it in that specific location). Of course your argument is that clause
    would never be executed (true) and thus skipping any run-time errors there
    is completely valid (but I was curious who might flag that as an error so I
    put it in).

    --
    |WARNING: Due to extreme spam, googlegroups.com is blocked. Due to ignorance |
    | by the abuse department, bellsouth.net is blocked. If you post to |
    | Usenet from these places, find another Usenet provider ASAP. |
    | Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) |

  11. Re: Error checking with execlp()

    On Fri, 04 Jul 2008 08:47:02 -0400 Barry Margolin wrote:

    | While application programmers normally assume the OS does what it's
    | supposed to do, what's wrong with defensive programming? Some types of
    | failures are difficult to protect against (it would be silly to check
    | that every write() successfully did its job, although backup programs
    | often include a "verify" option), but this is an easy case.

    Defensive programming can be carried to an extreme, too. Just how far is far
    enough? What if _exit(1) returns?

    --
    |WARNING: Due to extreme spam, googlegroups.com is blocked. Due to ignorance |
    | by the abuse department, bellsouth.net is blocked. If you post to |
    | Usenet from these places, find another Usenet provider ASAP. |
    | Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) |

  12. Re: Error checking with execlp()

    In article , phil-news-nospam@ipal.net
    wrote:

    > On Thu, 03 Jul 2008 22:58:01 -0400 Barry Margolin
    > wrote:
    >
    > |> No. I'm saying that the code that was omitted by the compiler was not
    > |> needed.
    > |
    > | That's what "redundant" means.
    > |
    > | Just because it's "correct" to leave something out, it doesn't mean that
    > | it's "incorrect" to include it. Unnecessary, yes, but not incorrect.
    >
    > I'm not saying that it is incorrect to include it. I'm just saying that it
    > is correct to not include it. I choose to not include it (see my previous
    > posts) and I assert that doing so is correct.


    Did I (or anyone) ever disagree with that? All I've ever been said is
    that there's nothing wrong with the OP's code that checks the return
    value.

    >
    >
    > |> | The point of compiler optimizations is to save us from having to deal
    > |> | with all sorts of minutiae. And that's what I think this argument we're
    > |> | having is about: an unimportant detail. No harm comes from checking the
    > |> | return value of exec(). It's redundant, that's all.
    > |>
    > |> True, that is the point of compiler optimization. But optimization also
    > does
    > |> provide a comparative side effect: it lets us see what could have been
    > done
    > |> differently. That does NOT mean we _should_ do it differently, just that
    > it
    > |> would still be correct if we did.
    > |>
    > |> My argument is that omitting the test of the return value of execve() is
    > just
    > |> as correct when the programmer writes the code as when the compiler
    > generates
    > |> machine language.
    > |
    > | No one is arguing that you must check the return value. It's OK to
    > | leave out the check. This whole subthread started because people said
    > | it was wrong that the OP included the check.
    >
    > It's merely unneeded.


    Right.

    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    *** PLEASE don't copy me on replies, I'll read them in the group ***

  13. Re: Error checking with execlp()

    Barry Margolin writes:
    > In article , phil-news-nospam@ipal.net
    >
    >> On Thu, 03 Jul 2008 22:58:01 -0400 Barry Margolin
    >> wrote:
    >>
    >> |> No. I'm saying that the code that was omitted by the compiler was not
    >> |> needed.
    >> |
    >> | That's what "redundant" means.
    >> |
    >> | Just because it's "correct" to leave something out, it doesn't mean that
    >> | it's "incorrect" to include it. Unnecessary, yes, but not incorrect.
    >>
    >> I'm not saying that it is incorrect to include it. I'm just saying that it
    >> is correct to not include it. I choose to not include it (see my previous
    >> posts) and I assert that doing so is correct.

    >
    > Did I (or anyone) ever disagree with that? All I've ever been said is
    > that there's nothing wrong with the OP's code that checks the return
    > value.


    A program is a sort of publication. It's meant to be read by
    the programmer, another programmer (perhaps yourself a few
    days, weeks or years later), and lastly a machine. The
    machine doesn't care how pretty the program is - if the
    program compiles, the machine's happy

    There is a lot wrong with adding code to programs which is known to
    have no effect except confusing other people.

  14. Re: Error checking with execlp()

    On Mon, 07 Jul 2008 10:57:51 +0200 Rainer Weikusat wrote:
    | Barry Margolin writes:
    |> In article , phil-news-nospam@ipal.net
    |>
    |>> On Thu, 03 Jul 2008 22:58:01 -0400 Barry Margolin
    |>> wrote:
    |>>
    |>> |> No. I'm saying that the code that was omitted by the compiler was not
    |>> |> needed.
    |>> |
    |>> | That's what "redundant" means.
    |>> |
    |>> | Just because it's "correct" to leave something out, it doesn't mean that
    |>> | it's "incorrect" to include it. Unnecessary, yes, but not incorrect.
    |>>
    |>> I'm not saying that it is incorrect to include it. I'm just saying that it
    |>> is correct to not include it. I choose to not include it (see my previous
    |>> posts) and I assert that doing so is correct.
    |>
    |> Did I (or anyone) ever disagree with that? All I've ever been said is
    |> that there's nothing wrong with the OP's code that checks the return
    |> value.
    |
    | A program is a sort of publication. It's meant to be read by
    | the programmer, another programmer (perhaps yourself a few
    | days, weeks or years later), and lastly a machine. The
    | machine doesn't care how pretty the program is - if the
    | program compiles, the machine's happy
    |
    | There is a lot wrong with adding code to programs which is known to
    | have no effect except confusing other people.

    In a few cases, I've had to add code to programs where the only real effect
    is to quash a compiler warning, usually about a possibly uninitialized variable
    that really will be initialized, but the compiler's analysis doesn't go deep
    enough to know that no path could be followed that would not assigne it. One
    typical case is a loop that has a conditional break in the middle, and assigns
    that variable following that conditional, where that conditional will never
    be true the first time around, which assures the assignment always happens.

    When I do have to add such code, I comment it as such, to avoid confusion by
    the programmer ("he assigned it here needlessly"). It might be nice if there
    was a way to assert to the compiler that a variable really has been assigned
    a value in the preceeding code within the block, and to not worry about any
    uses of an uninitialized variable following that assertion (which generates
    no code). Example: __assert_initialized__( varname );

    It's no big deal. Generally the useless initialization takes 4 bytes of
    code text space at run time, and one instruction time executed. It's not
    something to dwell on if you aren't coding some finite embedded firmware.

    --
    |WARNING: Due to extreme spam, googlegroups.com is blocked. Due to ignorance |
    | by the abuse department, bellsouth.net is blocked. If you post to |
    | Usenet from these places, find another Usenet provider ASAP. |
    | Phil Howard KA9WGN (email for humans: first name in lower case at ipal.net) |

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2