From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-workers-return-33793-mason-zsh=primenet.com.au@zsh.org>
Received: (qmail 12389 invoked by alias); 25 Nov 2014 16:07:24 -0000
Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
List-Id: Zsh Workers List <zsh-workers.zsh.org>
List-Post: <mailto:zsh-workers@zsh.org>
List-Help: <mailto:zsh-workers-help@zsh.org>
X-Seq: 33793
Received: (qmail 23076 invoked from network); 25 Nov 2014 16:07:22 -0000
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI,
	SPF_HELO_PASS,T_HDRS_LCASE,T_MANY_HDRS_LCASE autolearn=ham version=3.3.2
X-AuditID: cbfec7f4-b7f126d000001e9a-2d-5474a935fd37
Date: Tue, 25 Nov 2014 16:07:18 +0000
From: Peter Stephenson <p.stephenson@samsung.com>
To: Zsh Hackers' List <zsh-workers@zsh.org>
Subject: 0b numeric prefix
Message-id: <20141125160718.01444ac8@pwslap01u.europe.root.pri>
Organization: Samsung Cambridge Solution Centre
X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.0; i386-redhat-linux-gnu)
MIME-version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7bit
X-Brightmail-Tracker:
 H4sIAAAAAAAAA+NgFvrMJMWRmVeSWpSXmKPExsVy+t/xq7qmK0tCDPZMMLA42PyQyYHRY9XB
	D0wBjFFcNimpOZllqUX6dglcGQc39rAXLBeseP3aroFxLW8XIyeHhICJxIIvH5ggbDGJC/fW
	s3UxcnEICSxllLh3uZMZwlnOJNG1bg1YFYuAqsSld09ZQWw2AUOJqZtmM3YxcnCICGhLtH8U
	AwkLC0hJfGzpYgSxeQXsJVrn7wUr5xfQl7j69xPUMnuJmVfOQNUISvyYfI8FxGYW0JLYvK2J
	FcKWl9i85i3zBEa+WUjKZiEpm4WkbAEj8ypG0dTS5ILipPRcQ73ixNzi0rx0veT83E2MkID6
	soNx8TGrQ4wCHIxKPLwGiSUhQqyJZcWVuYcYJTiYlUR4g3qBQrwpiZVVqUX58UWlOanFhxiZ
	ODilGhgnLnGcprY44jDzo7ApE99X1DTs3moS81csRiokw2jCBVmmhqLVcv86dG4dnBnd8o3/
	pltr2b2YsF0fNzpdk8vsDQtt1eJhSp7HqpLuzswaEn9fwIGvofFnZVUvU57CrQNboznUpRYW
	ZekxztEyrdr/VdvV30P8oc0+Rf+Fu4+GuTdu3VYfo8RSnJFoqMVcVJwIAJYuICkGAgAA

This adds the fairly common (but certainly far from universal) 0b prefix
to denote binary on input.  I think numeric parsing is designed so this
can't conflict with anything existing that's valid.

I'm not sure whether to output this form in C_BASES mode.  On the one
hand, it's more likely to be understood on input in utilities other than
shells than 2#blah; on the other, it won't work with older versions of
zsh or other shells (not that C_BASES is designed with other shells in
mind).  Because of the latter I'm not intending to do this.  It would
also be a perversion of the name of the option.

I'll add some tests later.

pws


diff --git a/Doc/Zsh/arith.yo b/Doc/Zsh/arith.yo
index 96dc2dc..a620b73 100644
--- a/Doc/Zsh/arith.yo
+++ b/Doc/Zsh/arith.yo
@@ -39,7 +39,8 @@ zero status.
 cindex(arithmetic base)
 cindex(bases, in arithmetic)
 Integers can be in bases other than 10.
-A leading `tt(0x)' or `tt(0X)' denotes hexadecimal.
+A leading `tt(0x)' or `tt(0X)' denotes hexadecimal and a leading
+`tt(0b)' or `tt(0B) binary.
 Integers may also be of the form `var(base)tt(#)var(n)',
 where var(base) is a decimal number between two and thirty-six
 representing the arithmetic base and var(n)
diff --git a/Src/math.c b/Src/math.c
index 2665698..438a170 100644
--- a/Src/math.c
+++ b/Src/math.c
@@ -449,12 +449,14 @@ lexconstant(void)
 	nptr++;
 
     if (*nptr == '0') {
+	int lowchar;
 	nptr++;
-	if (*nptr == 'x' || *nptr == 'X') {
+	lowchar = tolower(*nptr);
+	if (lowchar == 'x' || lowchar == 'b') {
 	    /* Let zstrtol parse number with base */
 	    yyval.u.l = zstrtol_underscore(ptr, &ptr, 0, 1);
 	    /* Should we set lastbase here? */
-	    lastbase = 16;
+	    lastbase = (lowchar == 'b') ? 2 : 16;
 	    if (isset(FORCEFLOAT))
 	    {
 		yyval.type = MN_FLOAT;
diff --git a/Src/utils.c b/Src/utils.c
index c6e7aed..5f0c106 100644
--- a/Src/utils.c
+++ b/Src/utils.c
@@ -2082,6 +2082,8 @@ zstrtol_underscore(const char *s, char **t, int base, int underscore)
 	    base = 10;
 	else if (*++s == 'x' || *s == 'X')
 	    base = 16, s++;
+	else if (*s == 'b' || *s == 'B')
+	    base = 2, s++;
 	else
 	    base = 8;
     }

pws