[C-safe-secure-studygroup] Dead store optimization

Robert Seacord rcseacord at gmail.com
Fri May 5 14:44:23 UTC 2017


I always assume the solution is to use the memset_s() function that was
added to C11 Annex K, but I seem to frequently be alone in this assumption.

rCs

On Fri, May 5, 2017 at 8:02 AM, Aaron Ballman <aaron at aaronballman.com>
wrote:

> On Fri, May 5, 2017 at 6:43 AM, Clive Pygott <clivepygott at gmail.com>
> wrote:
> > I assume its clear that the solution is to declare ptr as   volatile TYPE
> > *ptr;   as the compiler can't then ignore memset
>
> I believe the compiler still can in this situation, because memset()
> doesn't take its pointer value as a volatile pointer. This means
> volatile is dropped at the call site to memset() (and indeed,
> compilers diagnose this as; see
> -Wincompatible-pointer-types-discards-qualifiers), which does not
> access the underlying volatile object at that moment. Thus, the call
> to memset() can be elided.
>
> Indeed, this example demonstrates that your suggestion does not have
> the desired effect: https://godbolt.org/g/sGGL6c (there's a lot of
> bunk code in there to get the compiler to actually *generate* some
> code other than just returning 0 from main()).
>
> ~Aaron
>
> >
> >     Clive
> >
> > On Thu, May 4, 2017 at 8:16 PM, Robert Seacord <rcseacord at gmail.com>
> wrote:
> >>
> >> BECAUSE IT CAN!
> >>
> >> It's a dead code store, because you are writing to an object that is
> never
> >> read again.
> >>
> >> rCs
> >>
> >> On Thu, May 4, 2017 at 3:08 PM, Barton Miller <bart at cs.wisc.edu> wrote:
> >>>
> >>> Why would the compiler eliminate memset?
> >>>
> >>> --bart
> >>>
> >>>
> >>> On 5/4/2017 8:56 AM, Robert Seacord wrote:
> >>>
> >>>
> >>> The following code is commonly written for security purposes (to clear
> >>> sensitive information before freeing dynamically allocated storage):
> >>>
> >>> memset(ptr,0,size);
> >>>
> >>> free(ptr);
> >>>
> >>>
> >>> But compilers almost always eliminate the memset() as a dead code
> store.
> >>>
> >>>
> >>> Has anyone written or know of a static analyzer who can detect these
> >>> problems?
> >>>
> >>>
> >>> Also, maybe something to add to our rule list, if it's not already
> there.
> >>>
> >>>
> >>> Thanks,
> >>>
> >>> rCs
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> C-safe-secure-studygroup mailing list
> >>> C-safe-secure-studygroup at lists.trustable.io
> >>>
> >>> https://lists.trustable.io/cgi-bin/mailman/listinfo/c-
> safe-secure-studygroup
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> C-safe-secure-studygroup mailing list
> >>> C-safe-secure-studygroup at lists.trustable.io
> >>>
> >>> https://lists.trustable.io/cgi-bin/mailman/listinfo/c-
> safe-secure-studygroup
> >>>
> >>
> >>
> >> _______________________________________________
> >> C-safe-secure-studygroup mailing list
> >> C-safe-secure-studygroup at lists.trustable.io
> >>
> >> https://lists.trustable.io/cgi-bin/mailman/listinfo/c-
> safe-secure-studygroup
> >>
> >
> >
> > _______________________________________________
> > C-safe-secure-studygroup mailing list
> > C-safe-secure-studygroup at lists.trustable.io
> > https://lists.trustable.io/cgi-bin/mailman/listinfo/c-
> safe-secure-studygroup
> >
>
> _______________________________________________
> C-safe-secure-studygroup mailing list
> C-safe-secure-studygroup at lists.trustable.io
> https://lists.trustable.io/cgi-bin/mailman/listinfo/c-
> safe-secure-studygroup
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.trustable.io/pipermail/c-safe-secure-studygroup/attachments/20170505/002b61b3/attachment.html>


More information about the C-safe-secure-studygroup mailing list