On Mon, Mar 03, 2025 at 06:08:17PM +, Taylor R Campbell wrote:
> > Please everyone, avoid implementing hasty solutions, just because we
> > seem to need a solution to something today - we don't - a few days more
> > consideration and discussion can make solutions much more sane, and less
> > li
Date:Mon, 3 Mar 2025 17:20:57 +
From:Taylor R Campbell
Message-ID: <20250303172102.41b6b84...@mail.netbsd.org>
| It's not `wrong'; it's a legitimate way to eliminate unnecessary
| failure modes, weighing costs of one approach vs costs of another.
It is a very
Date:Mon, 3 Mar 2025 18:08:17 +
From:Taylor R Campbell
Message-ID: <20250303180830.d601784...@mail.netbsd.org>
| I did test build, and I ran the arc4random tests, including the test I
| added to verify the new more-graceful failure mode. I just forgot to
|
> Date: Mon, 03 Mar 2025 07:39:55 +0700
> From: Robert Elz
>
> Date:Mon, 03 Mar 2025 06:50:47 +0700
> From:Robert Elz
> Message-ID: <13328.1740959...@jacaranda.noi.kre.to>
>
> | This is the wrong solution,
>
> Further, given that it doesn't even build, please rev
> Date: Mon, 03 Mar 2025 06:50:47 +0700
> From: Robert Elz
>
> Date:Sun, 2 Mar 2025 22:46:24 +
> From:"Taylor R Campbell"
> Message-ID: <20250302224624.1a707f...@cvs.netbsd.org>
>
> | Log Message:
> | libc: New __libc_atfork.
> |
> | This uses caller-pro
Date:Mon, 03 Mar 2025 06:50:47 +0700
From:Robert Elz
Message-ID: <13328.1740959...@jacaranda.noi.kre.to>
| This is the wrong solution,
Further, given that it doesn't even build, please revert it.
I will implement a sane solution in the next day or two (I'll
even t
Date:Sun, 2 Mar 2025 22:46:24 +
From:"Taylor R Campbell"
Message-ID: <20250302224624.1a707f...@cvs.netbsd.org>
| Log Message:
| libc: New __libc_atfork.
|
| This uses caller-provided storage for the callback queues.
|
| Use it in arc4random(3) in order
> On Mar 26, 2022, at 9:39 AM, Taylor R Campbell
> wrote:
>
> `C string' is ambiguous because there are also char arrays that
> function as strings but which are not guaranteed to be NUL-terminated,
> as strncpy is intended for.
A non-terminated char array is not a C-string. The term C-strin
> On Mar 26, 2022, at 9:09 AM, Warner Losh wrote:
>
> Since all the 'C' standards[*] use "null-terminated" and "null character",
> it's likely best to use that terminology because there is a source of truth
> for its definition in case of ambiguity or doubt.
Ah, but you're giving up the oppo
On Sat, Mar 26, 2022 at 9:53 AM Roland Illig wrote:
> Am 24.03.2022 um 02:55 schrieb David H. Gutteridge:
> > Module Name: src
> > Committed By: gutteridge
> > Date: Thu Mar 24 01:55:15 UTC 2022
> >
> > Modified Files:
> > src/lib/libc/gen: popen.3
> >
> > Log Message:
> > popen.3:
> Date: Sat, 26 Mar 2022 16:53:19 +0100
> From: Roland Illig
>
> The term "null-terminated string" is quite common when talking about C.
> In contrast, the word "nul" in "nul-terminated" always reminds me of
> the character abbreviation in ASCII, which has a narrower scope than C.
> I prefer
> On Mar 26, 2022, at 9:17 AM, Martin Husemann wrote:
> When talking about it I prefer "zero terminated", or C-string, in
> contrast to C++ std::string (which are objects) or Pascal strings
> (which have an explicit length at the beginning).
Yes, I also prefer the term “C-string"
-- thorpej
On Sat, Mar 26, 2022 at 04:53:19PM +0100, Roland Illig wrote:
> The term "null-terminated string" is quite common when talking about C.
NULL terminated lists/array are quite common, but NULL is a pointer and
the string is terminated by a 0 char (sometimes spelled as \0 in a string
literal, but imp
Am 24.03.2022 um 02:55 schrieb David H. Gutteridge:
Module Name:src
Committed By: gutteridge
Date: Thu Mar 24 01:55:15 UTC 2022
Modified Files:
src/lib/libc/gen: popen.3
Log Message:
popen.3: minor spelling, grammar, style, and xref tweaks
To generate a diff of this co
On Wed, Feb 17, 2021 at 11:51:04PM +, David A. Holland wrote:
> Also, Someone(TM) should check if POSIX permits this or if we ought to
> improve the implementation.
Unsurprisingly, POSIX is silent. It just says "rewinddir shall also
cause the directory stream to refer to the current state of
On 03.02.2020 17:24, Kamil Rytarowski wrote:
> On 03.02.2020 17:21, Joerg Sonnenberger wrote:
>> On Sat, Feb 01, 2020 at 03:38:46PM +, Kamil Rytarowski wrote:
>>> Module Name:src
>>> Committed By: kamil
>>> Date: Sat Feb 1 15:38:46 UTC 2020
>>>
>>> Modified Files:
>
On 03.02.2020 17:21, Joerg Sonnenberger wrote:
> On Sat, Feb 01, 2020 at 03:38:46PM +, Kamil Rytarowski wrote:
>> Module Name: src
>> Committed By:kamil
>> Date:Sat Feb 1 15:38:46 UTC 2020
>>
>> Modified Files:
>> src/lib/libc/gen: pthread_atfork.c
>>
>> Log Messag
On Sat, Feb 01, 2020 at 03:38:46PM +, Kamil Rytarowski wrote:
> Module Name: src
> Committed By: kamil
> Date: Sat Feb 1 15:38:46 UTC 2020
>
> Modified Files:
> src/lib/libc/gen: pthread_atfork.c
>
> Log Message:
> Switch atform allocations from malloc()+free() to mmap()+munma
On 27.09.2017 11:23, m...@netbsd.org wrote:
> On Wed, Sep 27, 2017 at 09:04:30AM +, Maya Rashish wrote:
>> Module Name: src
>> Committed By:maya
>> Date:Wed Sep 27 09:04:30 UTC 2017
>>
>> Modified Files:
>> src/lib/libc/gen: isinf.3
>>
>> Log Message:
>> Move VAX no
On Wed, Sep 27, 2017 at 09:04:30AM +, Maya Rashish wrote:
> Module Name: src
> Committed By: maya
> Date: Wed Sep 27 09:04:30 UTC 2017
>
> Modified Files:
> src/lib/libc/gen: isinf.3
>
> Log Message:
> Move VAX notes to CAVEATS, clarify that it just returns zero
>
> The VAX is
Date:Sat, 9 Sep 2017 18:00:40 +
From:"Kamil Rytarowski"
Message-ID: <20170909180040.222c2f...@cvs.netbsd.org>
| Not that devname(3) does not set errno on failure and document it as a bug.
Not everything in libc is expected to set errno on failure - in fact
most
On Mon, Feb 13, 2017 at 12:04:02PM +, co...@sdf.org wrote:
> ASan is wrong about where the problem happens,
This can be dealt with -fno-omit-frame-pointer.
On Sun, Feb 12, 2017 at 05:37:49PM -0500, Christos Zoulas wrote:
> Module Name: src
> Committed By: christos
> Date: Sun Feb 12 22:37:49 UTC 2017
>
> Modified Files:
> src/lib/libc/gen: vis.c
>
> Log Message:
> fix off-by-one, found by asan.
>
It fails in another case, attached
On Sat, May 23, 2015 at 10:01:08AM -0400, Christos Zoulas wrote:
> Module Name: src
> Committed By: christos
> Date: Sat May 23 14:01:08 UTC 2015
>
> Modified Files:
> src/lib/libc/gen: vis.c
>
> Log Message:
> Grr need to deal with isgraph(3). Is there a better way?
Non-compat ca
In article <20141126164843.5cdd...@cvs.netbsd.org>,
Christos Zoulas wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: christos
>Date: Wed Nov 26 16:48:43 UTC 2014
>
>Modified Files:
> src/lib/libc/gen: opendir.c
>
>Log Message:
>- Use O_DIRECTORY to open the file, so that we
On Saturday 27 Sep 2014 11:04:09 Alan Barrett wrote:
> On Fri, 26 Sep 2014, Roy Marples wrote:
> >>>Log Message:
> >>>Remove \$ as a hidden marker as vis(3) wasn't setting it
> >>>and it clobbered VIS_SHELL | VIS_CSTYLE.
> >>>
> >> This is wrong. "vis -l" outputs \$, and with this change,
> >> unv
On Fri, 26 Sep 2014, Roy Marples wrote:
Log Message:
Remove \$ as a hidden marker as vis(3) wasn't setting it
and it clobbered VIS_SHELL | VIS_CSTYLE.
This is wrong. "vis -l" outputs \$, and with this change,
unvis won't correctly handle it.
unvis is not intended to reverse shell-style esca
On 2014-09-26 15:09, Alan Barrett wrote:
On Fri, 26 Sep 2014, Roy Marples wrote:
Modified Files:
src/lib/libc/gen: unvis.c
Log Message:
Remove \$ as a hidden marker as vis(3) wasn't setting it
and it clobbered VIS_SHELL | VIS_CSTYLE.
This is wrong. "vis -l" outputs \$, and with this
On Fri, 26 Sep 2014, Roy Marples wrote:
Modified Files:
src/lib/libc/gen: unvis.c
Log Message:
Remove \$ as a hidden marker as vis(3) wasn't setting it
and it clobbered VIS_SHELL | VIS_CSTYLE.
This is wrong. "vis -l" outputs \$, and with this change, unvis won't
correctly handle it.
In article <20140908174838.ga25...@britannica.bec.de>,
Joerg Sonnenberger wrote:
>On Mon, Sep 08, 2014 at 01:35:01PM -0400, Christos Zoulas wrote:
>> Module Name: src
>> Committed By:christos
>> Date:Mon Sep 8 17:35:01 UTC 2014
>>
>> Modified Files:
>> src/lib/libc/
On Mon, Sep 08, 2014 at 01:35:01PM -0400, Christos Zoulas wrote:
> Module Name: src
> Committed By: christos
> Date: Mon Sep 8 17:35:01 UTC 2014
>
> Modified Files:
> src/lib/libc/gen: vis.c
>
> Log Message:
> get rid of MB_STRZ as suggested by joerg.
Thanks. Can the NULL pointer
On Mon, Sep 08, 2014 at 12:42:09PM -0400, Christos Zoulas wrote:
> Module Name: src
> Committed By: christos
> Date: Mon Sep 8 16:42:09 UTC 2014
>
> Modified Files:
> src/lib/libc/gen: vis.c
>
> Log Message:
> PR/49185: Conrad Meyer: strvisx: Handle zero-length input strings grace
On Thu, Oct 17, 2013 at 07:56:17PM -0400, Christos Zoulas wrote:
> Module Name: src
> Committed By: christos
> Date: Thu Oct 17 23:56:17 UTC 2013
>
> Modified Files:
> src/lib/libc/gen: arc4random.c
>
> Log Message:
> remove always inline because new gcc bitches.
In that function
On Thu, 22 Mar 2012, Havard Eidnes wrote:
Module Name:src
Committed By: he
Date: Thu Mar 22 13:42:36 UTC 2012
Modified Files:
src/lib/libc/gen: nlist_coff.c
Log Message:
Make this lint-free (only built for real for the __sh__ ports):
* Mark some code after goto as /* NOT
On Thu, 22 Mar 2012, Havard Eidnes wrote:
Modified Files:
src/lib/libc/gen: modf_ieee754.c
Log Message:
Add a pair of casts to silence lint about conversion possibly losing bits.
- v.dblu_dbl.dbl_fracl = frac & 0x;
- v.dblu_dbl.dbl_frach = frac >> 32;
+ v.dbl
On Wed, Mar 21, 2012 at 10:28:32AM -0400, Christos Zoulas wrote:
> Module Name: src
> Committed By: christos
> Date: Wed Mar 21 14:28:32 UTC 2012
>
> Modified Files:
> src/lib/libc/gen: setmode.c
>
> Log Message:
> fix argument order.
Matt should have used my sed script ...
On Tue, Mar 15, 2011 at 12:26:05PM +0100, Joerg Sonnenberger wrote:
> On Tue, Mar 15, 2011 at 11:26:05AM +0100, Joerg Sonnenberger wrote:
> > On Tue, Mar 15, 2011 at 03:47:04AM +, Eric Haszlakiewicz wrote:
> > > Module Name: src
> > > Committed By: erh
> > > Date: Tue Mar 1
> On Tue, Mar 15, 2011 at 11:26:05AM +0100, Joerg Sonnenberger wrote:
> > On Tue, Mar 15, 2011 at 03:47:04AM +, Eric Haszlakiewicz wrote:
> > > Module Name: src
> > > Committed By: erh
> > > Date: Tue Mar 15 03:47:04 UTC 2011
> > >
> > > Modified Files:
> > > src/lib/li
> Module Name: src
> Committed By: erh
> Date: Tue Mar 15 03:47:04 UTC 2011
>
> Modified Files:
> src/lib/libc/gen: Makefile.inc
> Added Files:
> src/lib/libc/gen: commaize_number.3 commaize_number.c
>
> Log Message:
> PR#7540, add a commaize_number function, which inserts c
On Tue, Mar 15, 2011 at 11:26:05AM +0100, Joerg Sonnenberger wrote:
> On Tue, Mar 15, 2011 at 03:47:04AM +, Eric Haszlakiewicz wrote:
> > Module Name:src
> > Committed By: erh
> > Date: Tue Mar 15 03:47:04 UTC 2011
> >
> > Modified Files:
> > src/lib/libc/gen: M
On Tue, Mar 15, 2011 at 03:47:04AM +, Eric Haszlakiewicz wrote:
> Module Name: src
> Committed By: erh
> Date: Tue Mar 15 03:47:04 UTC 2011
>
> Modified Files:
> src/lib/libc/gen: Makefile.inc
> Added Files:
> src/lib/libc/gen: commaize_number.3 commaize_number.c
>
> Log
On Tue, Mar 15, 2011 at 07:12:57AM +0200, Jukka Ruohonen wrote:
> Wouldn't libutil be a better place than libc for something like this?
Why not just in ls? Seems to be non-standard, so not much software will
use it.
Martin
On Tue, Mar 15, 2011 at 03:47:04AM +, Eric Haszlakiewicz wrote:
> Module Name: src
> Committed By: erh
> Date: Tue Mar 15 03:47:04 UTC 2011
>
> Modified Files:
> src/lib/libc/gen: Makefile.inc
> Added Files:
> src/lib/libc/gen: commaize_number.3 commaize_number.c
>
> Log
Hmmm, guess I should have waited for the commit to ls, where it does
indicate locale-awareness.
Thanks!
On Mon, 14 Mar 2011, Paul Goyette wrote:
Is it locale-aware? Will it always insert a comma, or can it be conditioned
to insert a period if the locale so indicates?
On Tue, 15 Mar 2011,
Is it locale-aware? Will it always insert a comma, or can it be
conditioned to insert a period if the locale so indicates?
On Tue, 15 Mar 2011, Eric Haszlakiewicz wrote:
Module Name:src
Committed By: erh
Date: Tue Mar 15 03:47:04 UTC 2011
Modified Files:
src/lib/libc/
David Laight writes:
> On Sun, Mar 13, 2011 at 07:40:45AM +, matthew green wrote:
>> src/lib/libc/gen: unvis.c
>>
>> Log Message:
>> cast "~0" to (size_t) when passing to a size_t taking function.
>> fixes lint build errors.
>
> Is that right? My C promotion rules are getting rusty...
On Sun, Mar 13, 2011 at 07:40:45AM +, matthew green wrote:
> src/lib/libc/gen: unvis.c
>
> Log Message:
> cast "~0" to (size_t) when passing to a size_t taking function.
> fixes lint build errors.
Is that right? My C promotion rules are getting rusty...
~0 is of type 'int', 'size_t' is
In article <20110215.215643.260798087.nakay...@leto.eonet.ne.jp>,
NAKAJIMA Yoshihiro wrote:
>> Module Name: src
>> Committed By:christos
>> Date:Thu Jan 20 02:57:00 UTC 2011
>>
>> Modified Files:
>> src/lib/libc/gen: getcwd.c
>>
>> Log Message:
>> provide a _sys_get
> Module Name: src
> Committed By: christos
> Date: Thu Jan 20 02:57:00 UTC 2011
>
> Modified Files:
> src/lib/libc/gen: getcwd.c
>
> Log Message:
> provide a _sys_getcwd() entry like all the rest of the system calls to be
> used by SSP.
>
>
> To generate a diff of this commit:
>
On Sun, Dec 12, 2010 at 08:34:25AM +, David Holland wrote:
>
> Also, if we're going to be extracting strings anyway, errlist.c and
> whatever else ought to be built from errno.h.
Look at the cpp 'abose' I put into (IIRC) disklabel.h so that single
lines can be expanded in different ways.
(Hmm
On Sun, Dec 12, 2010 at 08:34:25AM +, David Holland wrote:
> On Thu, Dec 09, 2010 at 09:27:32PM +, Joerg Sonnenberger wrote:
> > Log Message:
> > Wrap sys_errlist constants in a macro to make it easier to extract
> > the strings reliably with sed/awk.
>
> Why two layers of parentheses?
On Thu, Dec 09, 2010 at 09:27:32PM +, Joerg Sonnenberger wrote:
> Log Message:
> Wrap sys_errlist constants in a macro to make it easier to extract
> the strings reliably with sed/awk.
Why two layers of parentheses?
Also, if we're going to be extracting strings anyway, errlist.c and
whatev
52 matches
Mail list logo
