lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 30 Sep 2015 04:40:56 +0000
From: Jean-Philippe Aumasson <>
Subject: Re: [PHC] Specification of a modular crypt format (2)

Code up at

You can comment and edit

On Wed, Sep 30, 2015 at 6:29 AM Solar Designer <> wrote:

> On Wed, Sep 30, 2015 at 04:18:28AM +0000, Peter Gutmann wrote:
> > Solar Designer <> writes:
> >
> > >That's true, and your code works, but I gave strtoul() a try anyway.
> >
> > It has the same problem as atol(), it uses in-band signalling for errors
> > (which means, at least for my purposes, that I consider it unusable).
> It also has out-of-band if you don't mind resetting errno to zero before
> calling strtoul(), like POSIX explicitly recommends:
> "Since 0, {ULONG_MAX}, and {ULLONG_MAX} are returned on error and are
> also valid returns on success, an application wishing to check for error
> situations should set errno to 0, then call strtoul() or strtoull(),
> then check errno."
> The code I posted does just that.
> > Thomas' version (and mine) don't.
> Sure.  My wrapper function around strtoul() doesn't, either.  It has
> the side-effect of clobbering errno even when there's no error, though;
> but I could save and restore errno to avoid that if we care.
> Anyway, it was just an experiment to see how bad strtoul() is, and the
> answer is: pretty bad, yet repairable with a wrapper.  This experiment
> also happened to test Thomas' code.
> Alexander

Content of type "text/html" skipped

Powered by blists - more mailing lists