That doesn't make sense to me. The security comes from always zeroing out
the memory when reallocating. The *Allocate* methods make this optional
with the fZeroOnRealloc parameter. If *Allocate* isn't working out, maybe
rename to StrAlloc*Core?
On Thu, Jun 19, 2014 at 10:13 AM, Heath Stewart <hea...@outlook.com> wrote:
> I meant that we should use *Secure in lieu of *Allocate*.
> StrAllocFormatted and StrAllocateFormatted, for example, are confusing if
> you don't know the code. What's the difference, one might ask? But
> StrAllocFormatted and StrAllocFormattedSecure are pretty obvious.
>
> I'm redoing some of them now and could rename them. The bug that broken
> related bundles is in there - namely a combination of MemAllocSecure (which
> can actually be greatly simplified) and StrAllocateFormattedArgs. I suppose
> if you want to go rename all the *Allocate* functions to *Secure that would
> be good.
>
> - Heath from his Surface Pro
>
> *From:* Sean Hall <r.sean.h...@gmail.com>
> *Sent:* Thursday, June 19, 2014 7:29 AM
> *To:* Windows Installer XML toolset developer mailing list
> <wix-devs@lists.sourceforge.net>
>
> When I created the StrAlloc*Secure functions, I had just copied the
> original StrAlloc* functions and modified them. The StrAllocate* functions
> were created so that the code wasn't duplicated. Why didn't I keep the
> StrAlloc*Secure functions as wrappers around the StrAllocate* functions? I
> don't remember, maybe because I thought StrAlloc*Secure also required a
> second look. Should I add them back?
>
>
> On Thu, Jun 19, 2014 at 2:28 AM, Heath Stewart <hea...@outlook.com> wrote:
>
>> While tracking down the root cause for the related bundle issue, I see
>> that the history of strutil originally used function names like
>> StrAlloc*Secure, which is rather self-explanatory and consistent with CRT
>> naming conventions. But in another change these were changed to
>> StrAllocate* which isn't self-explanatory and often requires a second look
>> to make sure you'll looking at Alloc or Allocate. Any reason for getting
>> rid of the original, self-explanatory function names?
>> *Heath Stewart*
>> Software Design Engineer
>> Visual Studio, Microsoft
>> http://blogs.msdn.com/heaths
>>
>>
>> ------------------------------------------------------------------------------
>> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
>> Find What Matters Most in Your Big Data with HPCC Systems
>> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
>> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
>> http://p.sf.net/sfu/hpccsystems
>> _______________________________________________
>> WiX-devs mailing list
>> WiX-devs@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wix-devs
>>
>>
>
>
> ------------------------------------------------------------------------------
> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
> Find What Matters Most in Your Big Data with HPCC Systems
> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> http://p.sf.net/sfu/hpccsystems
> _______________________________________________
> WiX-devs mailing list
> WiX-devs@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-devs
>
>
------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
WiX-devs mailing list
WiX-devs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-devs
