Note that compiler optimization is performed for a compile unit. If the
memory block has global linkage, i.e. not auto and not file-static, the
compiler will perform the clear, since it doesn't know if you will use the
memory later.
If the memory block is file-static, it is a bit bothersome. If the memory
is used in a lot off different places, it might contain sensitive
information. Better OS clears memory returned by programs, but in some
environments it is up to the application to make sure that no sensitive
information is leaked. Most probably, a compiler will clear the memory
block. However, I'm not sure what the standard says about this case.
The easiest way to make sure a for() loop isn't empty is to insert a call
to a non-inlineable function, preferably a function in another compilation
unit to protect from global optimization. There are a number of tricks to
do inside a function to try getting the compiler to leave the for loop
intact. However, some compilers are very, very aggresive at detecting
surplus code or results that isn't needed etc, so it isn't really
recommended.
Since the compiler doesn't know about side effects in externally linked
functions, a number of functions in the runtime library may be used but
observe that some "functions" might actually be inline assemply
intrinsics that the compiler will notice the side effects for...
/Per W
On Fri, 9 Jul 2004, [ISO-8859-2] OROSZI Bal=E1zs wrote:
> Hi!
>
> Per Westermark wrote:
>
> > clock returns amount of time consumed by your process. Obviously the fi=
rst
> > call to clock() should be zero since your program hasn't done anything
> > yet.
> >
> > When you write empty for() loops - without any actual work in them - th=
e
> > compiler optimization will completely remove your loop. The result is t=
hat
> > your second call to clock() will be made immediately after the first ca=
ll,
> > and give the value zero.
>
> This is a very interesting question, that I have been pondering on for so=
me time now: what
> can you assume, that is NOT going to be removed by compiler optimization?=
This also arises
> a serious security issue: if you say "clear this block of memory" but the=
n you exit (or
> similar), and actually never use that memory, will the compiler optimize =
out the call, or
> let it work?
>
> I would like to get some thoughts about this.
> Thanks.
>
> --
> Greetings,
> Bal=E1zs
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> Dev-cpp-users mailing list
> Dev...@li...
> TO UNSUBSCRIBE: http://www23.brinkster.com/noicys/devcpp/ub.htm
> https://lists.sourceforge.net/lists/listinfo/dev-cpp-users
>
|
