On Sat, Jun 12, 2010 at 07:35:26PM +0200, Dag-Erling Smørgrav wrote: > Bernd Walter <ti...@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 > later.
I'm at least sure that the compiler can't if it is linked from another object file. 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 <be...@bwct.de> http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. _______________________________________________ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
