Project

General

Profile

Actions

Bug #1402

closed

multiple by 8 / 10 instead of 0.8 to prevent the need for floating support

Added by Anonymous about 17 years ago. Updated almost 16 years ago.

Status:
Fixed
Priority:
Normal
Category:
core
Target version:
ASK QUESTIONS IN Forums:

Description

in server.c, please replace "0.8" by "8 / 10".

This allows using lighttpd to run without floating point emulation on embedded machines without floating point support (such as ARM).

This fix has been tested in OpenEmbedded for long now. Please consider merging it.

-- leonw


Files

src-server.c.patch (1.02 KB) src-server.c.patch Remove dependency of floating point math. For embedded systems. Anonymous, 2008-01-03 22:05
Actions #1

Updated by stbuehler about 16 years ago

  • Target version changed from 1.4.20 to 1.4.21
Actions #2

Updated by LX about 16 years ago

Anonymous wrote:

in server.c, please replace "0.8" by "8 / 10".

This allows using lighttpd to run without floating point emulation on embedded machines without floating point support (such as ARM).

This fix has been tested in OpenEmbedded for long now. Please consider merging it.

-- leonw

Instead of "* 8 / 10", it would be faster to use "<< 3 / 10" and still work on embedded systems.

Greetings, LX

Actions #3

Updated by stbuehler about 16 years ago

  • Patch available set to No

LX wrote:

Instead of "* 8 / 10", it would be faster to use "<< 3 / 10" and still work on embedded systems.

Greetings, LX

If it is faster with your compiler, you should not use that compiler. Never "optimize" such things, they only make your code less readable.

Actions #4

Updated by ralf about 16 years ago

Whats wrong with the patch from leonw?

Actions #5

Updated by peto about 16 years ago

There's nothing wrong with the patch that I can see. stbuehler is correct that rewriting math with shifts is usually a bad idea, but the patch didn't do that. Rewriting floating point math as integer math is often a very good idea. Not only does it work better on embedded systems with no FPU, it's also more easily predictable (though off-by-one rounding errors in this particular case would be harmless).

Actions #6

Updated by stbuehler almost 16 years ago

  • Status changed from New to Fixed
  • % Done changed from 0 to 100

Applied in changeset r2381.

Actions

Also available in: Atom