Tim Peters wrote: > > [MAL] > > How about always enabling our version in the alpha cycle and then > > reverting back to the native one in the betas ? > > If we have to ship our own code for it anyway, why ever revert to the native > one? Historically, all that gives us is boundless opportunities to catalog > and #ifdef our way around gratuitous discrepancies among platform C > libraries. > > since-we-switched-to-our-own-getopt-everywhere-we-no-longer-get- > getopt-bug-reports-anywhere-ly y'rs - tim Well, the emulation is not as robust and fast as the native implementation is, plus it cannot recover from a buffer overrun; such an overrun is likely to cause a core dump due to sprintf() writing into the heap -- still better than allowing a cracker to hack your system by exploiting a stack overrun, but not as good as a true snprintf() implementation will do. If we do get complaints about snprintf() failures on systems which do have a native API, then we can still switch to the emulation for all platforms. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Consulting & Company: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4