From: Rich Felker <dalias@aerifal.cx>
To: musl@lists.openwall.com
Subject: Re: FreeSec crypt()
Date: Wed, 13 Jun 2012 13:27:11 -0400 [thread overview]
Message-ID: <20120613172711.GF163@brightrain.aerifal.cx> (raw)
In-Reply-To: <20120613164546.GA23407@openwall.com>
On Wed, Jun 13, 2012 at 08:45:46PM +0400, Solar Designer wrote:
> On Wed, Jun 13, 2012 at 10:56:03AM -0400, Rich Felker wrote:
> > On Wed, Jun 13, 2012 at 05:18:07PM +0400, Solar Designer wrote:
> > > > Note that even if the behavior were defined, this code seems to have
> > > > different behavior for high bytes depending on the signedness of char.
> ....
> > > Why would signedness of char matter
> > > if the behavior of the signed char overflowing left shift were defined?
> >
> > Well if char is signed, (char)0x80 << 1 is -256. If char is unsigned,
> > (char)0x80 << 1 is 256.
>
> Sure, but we had:
>
> const char *key;
> u_char *q;
> *q++ = *key << 1;
>
> so while *key << 1 is either -256 or 256 (promoted to int or unsigned
> int), those high bits get dropped on the assignment to *q anyway,
> resulting in the same value there either way. No?
You're right on that. Ideally the functions should just take arguments
of type unsigned char *, and the crypt/crypt_r wrapper should cast the
original char * to unsigned char *. This is the same way all the
standard string functions (like strcmp) are required to work.
Casting/converting the _value_ after reading it also happens to work,
and is sufficient for musl's purposes (we assume, per POSIX, that
CHAR_BIT is 8, but also that signed types are twos complement), but
only reinterpreting by casting the pointer before reading it is 100%
portable. On a non-twos-complement machine, reading a signed char is
lossy (it can only obtain 255 possible values, not 256).
Rich
next prev parent reply other threads:[~2012-06-13 17:27 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-12 23:51 Solar Designer
2012-06-13 1:18 ` Rich Felker
2012-06-13 6:10 ` Szabolcs Nagy
2012-06-13 12:43 ` Solar Designer
2012-06-13 12:58 ` Rich Felker
2012-06-13 13:18 ` Solar Designer
2012-06-13 14:56 ` Rich Felker
2012-06-13 16:45 ` Solar Designer
2012-06-13 17:27 ` Rich Felker [this message]
2012-06-13 17:32 ` Szabolcs Nagy
2012-06-13 17:36 ` Rich Felker
2012-06-13 12:07 ` Solar Designer
2012-06-13 14:53 ` Rich Felker
2012-06-24 7:21 ` Solar Designer
2012-06-24 7:32 ` Solar Designer
2012-06-25 3:51 ` Rich Felker
2012-06-29 5:25 ` Rich Felker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120613172711.GF163@brightrain.aerifal.cx \
--to=dalias@aerifal.cx \
--cc=musl@lists.openwall.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).