>> I've been asked by the filezilla software developer if NetBSD will >> add crypt_r() as a thread-safe crypt() replacement. > I don't exactly see the point.
Thread safety, presumably. crypt(3) returns a pointer into a static buffer. I daresay it could be made to return a pointer into TLS when running threaded, but I think crypt_r makes more sense. I even have, on some small number of occasions, wanted a crypt_r without threads (though without threads or at least signals it's just a strcpy or strdup away). > If I wanted to provide a more modern interface, it would be for > password verification only and include constant time guarantees, > which the existing interface can't provide. Nobody's stopping you. For many purposes, crypt_r has the major advantage over what you describe that it is trivial changes to existing code. (In most cases, I suspect using what you're thinking of would be almost as trivial. But without a design to look at it's hard to tell. Admittedly, crypt_r _could_ mean pretty much anything, but it strikes me as unlikely wiz would use that name without meaning exactly what I daresay everybody here takes it to mean.) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
