Re: Two mod_include problems

[Paul J. Reder]

Its mostly a matter of pedantics. :)

Logically the reset should be linked to the actual action
of passing the bytes. In your hypothetical else there are
no bytes, so *all* existing (i.e. 0) bytes have been sent.
The problem I see with that is that if code is added later,
involving setaside bytes or some other method of keeping
some parts around, we might end up with something like:
     if (ctx->state == PRE_HEAD) {
         if (!empty) {
             pass
             /* reset deleted from here */
         }
         else if (empty & leftovers) {
                 foo
         }
         reset  /* reset added here */
     }
and the person doesn't realize the affinity that "reset"
should have with "pass". "foo" doesn't actually pass anything
and therefore shouldn't "reset", but that has been lost by
moving the "reset" outside of the "pass" context.
I'm trying to prevent potential future confusion. Does that
make sense?
Paul J. Reder

André Malo wrote:
* Paul J. Reder wrote:


With the other changes, the way I read the patch was as:

    if (ctx->state == PRE_HEAD) {
        if (!empty) {
            pass
            /* reset deleted from here */
        }
        reset  /* reset added here */
    }


yep... I meant, one could equally write the patch as:

      if (ctx->state == PRE_HEAD) {
          if (!empty) {
              pass
              reset
          }
          else {
              reset
          }
      }
where the else path means if(empty). I'm just confused, why not to reset in
that case.
nd

--
Paul J. Reder
-----------------------------------------------------------
"The strength of the Constitution lies entirely in the determination of each
citizen to defend it.  Only if every single citizen feels duty bound to do
his share in this defense are the constitutional rights secure."
-- Albert Einstein