CVS commit: src/common/lib/libc/stdlib

[Roy Marples]

Module Name:src
Committed By:   roy
Date:   Thu Nov 28 12:33:23 UTC 2019

Modified Files:
src/common/lib/libc/stdlib: strtoi.c strtou.c

Log Message:
Make it easier to use strtoi and strtou in downsteam applications
without the need to define HAVE_NBTOOL_CONFIG_H and yet allow -Wundef
not to log any warnings.


To generate a diff of this commit:
cvs rdiff -u -r1.2 -r1.3 src/common/lib/libc/stdlib/strtoi.c \
src/common/lib/libc/stdlib/strtou.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

Modified files:

Index: src/common/lib/libc/stdlib/strtoi.c
diff -u src/common/lib/libc/stdlib/strtoi.c:1.2 src/common/lib/libc/stdlib/strtoi.c:1.3
--- src/common/lib/libc/stdlib/strtoi.c:1.2	Fri May  1 14:17:56 2015
+++ src/common/lib/libc/stdlib/strtoi.c	Thu Nov 28 12:33:23 2019
@@ -1,4 +1,4 @@
-/*	$NetBSD: strtoi.c,v 1.2 2015/05/01 14:17:56 christos Exp $	*/
+/*	$NetBSD: strtoi.c,v 1.3 2019/11/28 12:33:23 roy Exp $	*/
 
 /*-
  * Copyright (c) 2005 The DragonFly Project.  All rights reserved.
@@ -30,12 +30,12 @@
  * NetBSD: src/common/lib/libc/stdlib/strtoul.c,v 1.3 2008/08/20 19:58:34 oster Exp
  */
 
-#if HAVE_NBTOOL_CONFIG_H
+#if defined(HAVE_NBTOOL_CONFIG_H) && HAVE_NBTOOL_CONFIG_H
 #include "nbtool_config.h"
 #endif
 
 #include 
-__RCSID("$NetBSD: strtoi.c,v 1.2 2015/05/01 14:17:56 christos Exp $");
+__RCSID("$NetBSD: strtoi.c,v 1.3 2019/11/28 12:33:23 roy Exp $");
 
 #ifdef _LIBC
 #include "namespace.h"
Index: src/common/lib/libc/stdlib/strtou.c
diff -u src/common/lib/libc/stdlib/strtou.c:1.2 src/common/lib/libc/stdlib/strtou.c:1.3
--- src/common/lib/libc/stdlib/strtou.c:1.2	Fri May  1 14:17:56 2015
+++ src/common/lib/libc/stdlib/strtou.c	Thu Nov 28 12:33:23 2019
@@ -1,4 +1,4 @@
-/*	$NetBSD: strtou.c,v 1.2 2015/05/01 14:17:56 christos Exp $	*/
+/*	$NetBSD: strtou.c,v 1.3 2019/11/28 12:33:23 roy Exp $	*/
 
 /*-
  * Copyright (c) 2005 The DragonFly Project.  All rights reserved.
@@ -30,12 +30,12 @@
  * NetBSD: src/common/lib/libc/stdlib/strtoul.c,v 1.3 2008/08/20 19:58:34 oster Exp
  */
 
-#if HAVE_NBTOOL_CONFIG_H
+#if defined(HAVE_NBTOOL_CONFIG_H) && HAVE_NBTOOL_CONFIG_H
 #include "nbtool_config.h"
 #endif
 
 #include 
-__RCSID("$NetBSD: strtou.c,v 1.2 2015/05/01 14:17:56 christos Exp $");
+__RCSID("$NetBSD: strtou.c,v 1.3 2019/11/28 12:33:23 roy Exp $");
 
 #ifdef _LIBC
 #include "namespace.h"

CVS commit: src/common/lib/libc/stdlib

[Roy Marples]

Module Name:src
Committed By:   roy
Date:   Thu Nov 28 12:33:23 UTC 2019

Modified Files:
src/common/lib/libc/stdlib: strtoi.c strtou.c

Log Message:
Make it easier to use strtoi and strtou in downsteam applications
without the need to define HAVE_NBTOOL_CONFIG_H and yet allow -Wundef
not to log any warnings.


To generate a diff of this commit:
cvs rdiff -u -r1.2 -r1.3 src/common/lib/libc/stdlib/strtoi.c \
src/common/lib/libc/stdlib/strtou.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

Re: CVS commit: src/common/lib/libc/stdlib

[Kamil Rytarowski]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 12.01.2016 22:43, David Laight wrote:
> On Sat, Nov 14, 2015 at 06:40:21AM +1100, matthew green wrote:
>> Christos Zoulas writes:
>>> In article <2015111344.ga13...@britannica.bec.de>, Joerg
>>> Sonnenberger   wrote:
 On Thu, Nov 12, 2015 at 12:23:51PM -0500, Christos Zoulas
 wrote:
> Module Name:  src Committed By:   christos Date:  Thu Nov 
> 12
> 17:23:51 UTC 2015
> 
> Modified Files: src/common/lib/libc/stdlib: _strtol.h
> _strtoul.h
> 
> Log Message: Recognize 0[bB] as binary (base 2)
 
 Based on what authority? This is a ISO C function and that
 doesn't allow binary input. I am quite concerned about
 changing a function used that often, especially as it can
 break a lot of existing code.
>>> 
>>> I don't think it will since it will only affect conversions
>>> with 0[bB], and the OS/X code is doing the same, but I will
>>> revert it until others catch up.
>> 
>> the problem is that something that was "0b" always
>> came out as 0 before, but now it doesn't.
>> 
>> that's a fairly major semantic change, i think i agree with joerg
>> that it has a high chance of breaking existing usage.
> 
> Worse that that, some code might be relying on getting a pointer to
> the 'b' and continuing to parse the buffer.
> 
> Not a good idea to change it.
> 
> David
> 

The 0B or 0b syntax is a part of C++14 and part of C compilers
recognize it for at least a decade. It's common in other languages
(Java, D, Ruby, Python)

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3472.pdf

But it's still not officially supported by strtol(3)-like functions in
C/C++.

I would support it as a local extensions, it makes sense to me.

There might be a conflict with strsuftoll(3) (hopefully once replaced
by strsuftoi(3)) for '0b' but it's a narrow-case and not from a
real-life usage.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJWlqd1AAoJEEuzCOmwLnZss/oQAMLZVikU+NlqrC+j5Qyq8w/J
u7KEvgXP4j/uo6tWkc1q9sbMDyrH9FIF1T+wtpAppmxU1k2B2rFTSs/sqcDq+B1V
8pJBZt97+eyra7fbc9uy6pP8jZu9Wuvay+Uu0zoJxSlvThmF5+uPpLPA8D/lvKcP
Gvnx9aBDk01Hloltyg7D1A7VpH0zcc+EH+f3oIe4Jckkkm06OulhN5YacXszyaF2
14X77cqFVTsB5v1+UWDoi95e10X8My5UAYgn9efJHk+b75BxQAggm4kJ8YG84OyV
CjuqpuakWQ+N/3tQarV7laLjCxwuX7CVe5qDpzmCcCTLO6wIIk6gXOqOwQHn9/Qm
0SFW/aHhocXn7l4eTjMd/rjpuzScgrt21PB+UcrHQAkBjaXZB1w1MvvgYsHcseWm
OXSVeR0W+wPplgegs2dCpUa9VGh/m3fxbHOTW+Ac4rBwRKk9BjalOUhj/IG7Acy5
5pl+YAwmCsIcSsHI1JUsL+aJVgLz0jsC+oqT3VyV7txz7Z5OXpRB+j/LW7tHYg0F
gIXLGwka8mToTtRxuNeVby4vITsjR3qaJmhVlX8j0mqHsbWxwnc83mUcmmT6vnkc
tvDbLt022FS1TvEEFEInDeMhe0QX5j+rqTb3ft5rYww4CmEnOiTvYRAsh2LqLPhJ
3VLpHPeT9ouMUwVzHIrm
=fXts
-END PGP SIGNATURE-

Re: CVS commit: src/common/lib/libc/stdlib

[David Laight]

On Sat, Nov 14, 2015 at 06:40:21AM +1100, matthew green wrote:
> Christos Zoulas writes:
> > In article <2015111344.ga13...@britannica.bec.de>,
> > Joerg Sonnenberger   wrote:
> > >On Thu, Nov 12, 2015 at 12:23:51PM -0500, Christos Zoulas wrote:
> > >> Module Name: src
> > >> Committed By:christos
> > >> Date:Thu Nov 12 17:23:51 UTC 2015
> > >> 
> > >> Modified Files:
> > >>  src/common/lib/libc/stdlib: _strtol.h _strtoul.h
> > >> 
> > >> Log Message:
> > >> Recognize 0[bB] as binary (base 2)
> > >
> > >Based on what authority? This is a ISO C function and that doesn't allow
> > >binary input. I am quite concerned about changing a function used that
> > >often, especially as it can break a lot of existing code.
> > 
> > I don't think it will since it will only affect conversions with 0[bB],
> > and the OS/X code is doing the same, but I will revert it until others
> > catch up.
> 
> the problem is that something that was "0b" always came out
> as 0 before, but now it doesn't.
> 
> that's a fairly major semantic change, i think i agree with joerg that
> it has a high chance of breaking existing usage.

Worse that that, some code might be relying on getting a pointer
to the 'b' and continuing to parse the buffer.

Not a good idea to change it.

David

-- 
David Laight: da...@l8s.co.uk

Re: CVS commit: src/common/lib/libc/stdlib

[Joerg Sonnenberger]

On Thu, Nov 12, 2015 at 12:23:51PM -0500, Christos Zoulas wrote:
> Module Name:  src
> Committed By: christos
> Date: Thu Nov 12 17:23:51 UTC 2015
> 
> Modified Files:
>   src/common/lib/libc/stdlib: _strtol.h _strtoul.h
> 
> Log Message:
> Recognize 0[bB] as binary (base 2)

Based on what authority? This is a ISO C function and that doesn't allow
binary input. I am quite concerned about changing a function used that
often, especially as it can break a lot of existing code.

Joerg

Re: CVS commit: src/common/lib/libc/stdlib

[Christos Zoulas]

In article <2015111344.ga13...@britannica.bec.de>,
Joerg Sonnenberger   wrote:
>On Thu, Nov 12, 2015 at 12:23:51PM -0500, Christos Zoulas wrote:
>> Module Name: src
>> Committed By:christos
>> Date:Thu Nov 12 17:23:51 UTC 2015
>> 
>> Modified Files:
>>  src/common/lib/libc/stdlib: _strtol.h _strtoul.h
>> 
>> Log Message:
>> Recognize 0[bB] as binary (base 2)
>
>Based on what authority? This is a ISO C function and that doesn't allow
>binary input. I am quite concerned about changing a function used that
>often, especially as it can break a lot of existing code.

I don't think it will since it will only affect conversions with 0[bB],
and the OS/X code is doing the same, but I will revert it until others
catch up.

christos

re: CVS commit: src/common/lib/libc/stdlib

[matthew green]

Christos Zoulas writes:
> In article <2015111344.ga13...@britannica.bec.de>,
> Joerg Sonnenberger   wrote:
> >On Thu, Nov 12, 2015 at 12:23:51PM -0500, Christos Zoulas wrote:
> >> Module Name:   src
> >> Committed By:  christos
> >> Date:  Thu Nov 12 17:23:51 UTC 2015
> >> 
> >> Modified Files:
> >>src/common/lib/libc/stdlib: _strtol.h _strtoul.h
> >> 
> >> Log Message:
> >> Recognize 0[bB] as binary (base 2)
> >
> >Based on what authority? This is a ISO C function and that doesn't allow
> >binary input. I am quite concerned about changing a function used that
> >often, especially as it can break a lot of existing code.
> 
> I don't think it will since it will only affect conversions with 0[bB],
> and the OS/X code is doing the same, but I will revert it until others
> catch up.

the problem is that something that was "0b" always came out
as 0 before, but now it doesn't.

that's a fairly major semantic change, i think i agree with joerg that
it has a high chance of breaking existing usage.


.mrg.

Re: CVS commit: src/common/lib/libc/stdlib

[Lourival Vieira Neto]

 Module Name:src
 Committed By:   joerg
 Date:   Mon Dec  2 12:20:44 UTC 2013

 Modified Files:
src/common/lib/libc/stdlib: strtoimax.c

 Log Message:
 Fix aliases.

Sorry about that.. my bad!

Regards,
-- 
Lourival Vieira Neto

Re: CVS commit: src/common/lib/libc/stdlib

[David Laight]

On Tue, Apr 16, 2013 at 07:34:58PM +, Joerg Sonnenberger wrote:
 Module Name:  src
 Committed By: joerg
 Date: Tue Apr 16 19:34:58 UTC 2013
 
 Modified Files:
   src/common/lib/libc/stdlib: _strtol.h _strtoul.h
 
 Log Message:
 Do not use isalpha here, since we explicitly only support the Portable
 Character Set as base and in theory a locale could define a ASCII
 control character as letter, resulting in negations. Also avoid isdigit
 here to give the compiler a better chance of deciding whether an
 unsigned compare or a jump table is a better option, both are very
 likely better choices than the memory indirection.

There really ought to be a way of requesting the straight ASCII
versions of the is functions even after a local has been set.
A lot of code will use isalpha() to check for valid variable names (etc)
and really doesn't want locale-specific alpha characters be valid.
(Otherwise scripts become non-portable.)

OTOH (unsigned)(ch - '0') = 9 is probably the fastest isdigit()
on any modern cpu.

David

-- 
David Laight: da...@l8s.co.uk