RTFM :-) Basically, it's not handled right now. You can essentially use it to manage arbitrary binary buffers, but there is no explicit support for it otherwise. It's somewhere way down on the TODO list, but if someone's interested in contributing it, contact us privately; we should talk about the way we'd prefer to see it done. John On Monday, February 10, 2003, at 09:05 PM, Matt McClellan wrote: > What about wchar? > >> -----Original Message----- >> From: John Viega [mailto:viegaat_private] >> Sent: Monday, February 10, 2003 8:10 PM >> To: secprogat_private >> Subject: safestr alpha (Safe C String Library) >> >> >> The first alpha version of the Secure C String Library (safestr) is >> available at: >> >> http://www.zork.org/safestr.html >> >> Please DO NOT publicize this project while it is in alpha, even though >> we're making it available under the BSD license. >> >> Feedback is welcome. Send it to myself and Matt Messier (mmessier AT >> securesoftware.com). >> >> Currently, there is extensive documentation in the README file. >> >> ---------------------------------------------------------------------- >> -- >> ---- >> >> The goal of the safestr library is to provide a rich string-handling >> library >> or C that has safe semantics, yet interoperates with legacy library >> code in >> a straightforward manner. Additionally, porting code that using >> standard C >> string handling should be straightforward. The library should work on >> all >> modern Unix-like platforms, as well as any post-Win95 Microsoft OS. >> >> The overt security goals of the library are as follows: >> >> 1) Buffer overflows should not be possible when using the API. >> 2) Format string problems should be impossible when using the API. >> 3) The API should be capable of tracking whether strings are >> "trusted", >> a la Perl's taint mode. >> >> The API is meant to provide rich functionality and be easy to use, all >> the while improving security. >> >> To achieve interoperability with legacy code where you do not have the >> source or are unwilling to change it, the safestr_t type we define is >> completely compatible with type char *. That is, you can cast >> safestr_t objects to char *, and then they will act as a char * in >> every way. Without the explicit cast, the compiler will generate >> either a warning or an error (depending on how strict your compiler >> is). >> >> John >> >> >
This archive was generated by hypermail 2b30 : Mon Feb 10 2003 - 22:19:43 PST