[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGiyFdcjD2iJACbFTicUtopjkcWs3FhNJML2KAx06nBCHCf+Kw@mail.gmail.com>
Date: Wed, 30 Sep 2015 04:40:56 +0000
From: Jean-Philippe Aumasson <jeanphilippe.aumasson@...il.com>
To: discussions@...sword-hashing.net
Subject: Re: [PHC] Specification of a modular crypt format (2)
Code up at
https://docs.google.com/document/d/13bv-3HarFpQOD1PayJ2hMvRtVIs5QPu1FZ5XonEv57c/edit?usp=sharing
You can comment and edit
On Wed, Sep 30, 2015 at 6:29 AM Solar Designer <solar@...nwall.com> wrote:
> On Wed, Sep 30, 2015 at 04:18:28AM +0000, Peter Gutmann wrote:
> > Solar Designer <solar@...nwall.com> 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:
>
> http://pubs.opengroup.org/onlinepubs/009695399/functions/strtoul.html
>
> "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