On Tue, 2008-10-07 at 10:56 +0200, Bernd Petrovitsch wrote:
> On Tue, 2008-10-07 at 10:46 +0200, Hannes Gredler wrote:
> [...]
> > your changes really look good. - as soon you have the rework for the http_info
> > and txinfo plugin ready feel free to merge/commit to get devevelopment repository.
> > at http://gredler.at/hg/olsrd/ (its a development repository anyway, so we can
> 
> Done.
As for http://gredler.at/hg/olsrd/rev/fa85d8c3fafa : I built a gcc-4.3.2
which has even more warnings then before.

As for http://gredler.at/hg/olsrd/rev/df58351a117b (and the 2 preceding
commits):

- It works for me.(TM)
- Some function names (e.g. ipc_sendf) could be better. But I wanted the
  changes to be somewhat minimal (and my success in this is debatable)
  so renaming static functions can be done later.
- The output should be identical to before. Please check!
  Especially if the filtered output is complete and correct.
- Feel free to point out bugs, omissions, regressions, etc.

Technical notes:
- Setting all the file descriptors to "non-blocking" shouldn't be
  necessary. But it gives robustness if one can be quite sure that an
  illegal operation doesn't block. And the check for EAGAIN is cheap.
- The buffer extending in ipc_sendf() is not that elegant IMHO. But it
  is quite simple.
  And I'm not a big fan of static buffers.
- The va_copy() there is necessary as I couldn't find in any standard
  any guarantee that doing va_start() two times on the same list will
  succeed. So if anyone has a link to such a guarantee, I will happily
  fix that.
  Yes, I know, it usually works, almost everyone uses it, etc.
- In theory, we can handle now multiple parallel connections.
- The implicit state machine is quite obfuscated. Sorry ....
  The rules are:
  * The buffers are zero-terminated (so one can use normal str*
    functions).
  * conn->requlen == -1 if we got EOF from a read().
  * conn->respstart >= conn->resplen indicates that we wrote all of the 
    output.
  * And we read() all we get to empty sending and receiving buffers
    until we get EOF.
    Some browsers (at least from IE5.0/IE5.5 time) on Win* pop up
    alert windows with "error messages" if the server side closes the
    connection *after* successfully transmitting *all* of the data.
    The reason for not reading all was that the browser announced the
    HTTP request size but sent 2 more bytes.
    <rant>God only knows how many such workarounds of clearly buggy and
    thus br0ken Win* software exists.</rant>

	Bernd
-- 
Firmix Software GmbH                   http://www.firmix.at/
mobil: +43 664 4416156                 fax: +43 1 7890849-55
          Embedded Linux Development and Services




