Cleanup for cryptographic algorithms vs. compiler optimizations
ticso at cicely7.cicely.de
Sat Jun 12 22:52:22 UTC 2010
On Sat, Jun 12, 2010 at 07:35:26PM +0200, Dag-Erling Smørgrav wrote:
> Bernd Walter <ticso at cicely7.cicely.de> writes:
> > I'm not sure when removing a memset is allowed.
> Always, if the compiler can determine that the data will not be used
I'm at least sure that the compiler can't if it is linked from another
The problem with memset is that the compiler has an internal implementation.
On the other hand I wonder what the deep sense is to clear memory which
is unused later.
I know that crypto code can be tricky sometimes, but if someone is willing
to explain the specific reason my curiosity would be satified.
> In more general terms, the compiler is allowed to make any changes it
> likes to the program as long as the end result behaves exactly like it
> would if it hadn't been changed. This is called the "as if" rule. For
> instance, if you call printf() or fprintf() with a format string that
> does not contain any conversion specifiers, gcc will call gets() or
> fgets() instead.
Amazing - this is one of the things which can get nasty if you try some
kind of microtuning.
Recently I had to implement my own atoi on a controller because using the
library one magically had blown my RAM usage by 1k on a controller with
just 8k RAM.
> > Maybe passing volatile pointers might be enough.
> You can't pass a volatile pointer to memset.
Of course not - my fault - it takes non volatile pointers per definition.
B.Walter <bernd at bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
More information about the freebsd-current