Bug #1402

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

Added by Anonymous almost 7 years ago. Updated over 5 years ago.

Status:FixedStart date:
Priority:NormalDue date:
Assignee:jan% Done:

100%

Category:core
Target version:1.4.21
Missing in 1.5.x:

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

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

Associated revisions

Revision 2381
Added by stbuehler over 5 years ago

Remove floating point math from server.c (fixes #1402)

History

#1 Updated by stbuehler almost 6 years ago

  • Target version changed from 1.4.20 to 1.4.21

#2 Updated by LX almost 6 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

#3 Updated by stbuehler almost 6 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.

#4 Updated by ralf almost 6 years ago

Whats wrong with the patch from leonw?

#5 Updated by peto almost 6 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).

#6 Updated by stbuehler over 5 years ago

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

Applied in changeset r2381.

Also available in: Atom