[Owasp-esapi-c++] Boost::Test nil_t warnings

[David Anderson]

On Aug 29, 2011, at 11:38 AM, "Kevin W. Wall" <kevin.w.wall at gmail.com> wrote:

> David,
> 
> On Mon, Aug 29, 2011 at 11:05 AM, David Anderson
> <david.anderson at aspectsecurity.com> wrote:
>> It's Bimap, for bidirectional map.  The ESAPI object reference map interface can be implemented neatly using such a container.
> 
> Thanks for the clarification.
> 
>> I had Program Options in mind for Security Configuration and Encrypted
>> Properties.  I think when I listed System, I was really thinking of Process.
> 
> Actually, because C++ is used to write so many stand-alone programs,
> things like getopts(3C) or GNU's GetOpt class are commonly used. I
> was thinking outside of the ESAPI 2.0 box and thinking perhaps we
> could use Boost's "Program Options" to help us build a safer, more
> secure replacement for GetOpt & friends to process program arguments.
> I did this once back in 1988 for C. Had a Prolog program that parsed
> a man page like syntax and produced C code. I added an extension
> to the standard man page syntax though, so one could tag file names
> with things like file names with attributes such as "readable", "notwritable",
> "fullpath", "canonicalized", "notsymlink", etc. I also had tags for min/max
> for integer. The Prolog parser created C code that would do all the checking.
> All a developer had to do was to specify something like thi (don't recall
> the exact syntax I used):
> 
>    myprog [-f filename{readable,notsymlink,fullpath} ]
>           --pid=pid{int:min=1,max=65535}
> 
> etc. Building all those checks into your code is tedious and many
> developers skip them. It then comes back to bite them in the ass.
> 
> So it would be nice if we could provide some assistance along
> those lines too.

Neat idea.  Having the parser generate accurate usage documentation would be nice too, although it would be somewhat platform dependent.

> 
> -kevin
> -- 
> Blog: http://off-the-wall-security.blogspot.com/
> "The most likely way for the world to be destroyed, most experts agree,
> is by accident. That's where we come in; we're computer professionals.
> We *cause* accidents."        -- Nathaniel Borenstein