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: Sun, 2 Mar 2025 12:39:02 -0500
> From: Christos Zoulas
>
> Yes, unfortunately I committed the version from my tree by accident
> and not the one that was on the web server. I already fixed it.
No, you seem to have gotten it the wrong way around...
The original commit, rev. 1.8, had no a
Fixed now.
christos
> On Mar 3, 2025, at 10:41 AM, Taylor R Campbell wrote:
>
>> Date: Sun, 2 Mar 2025 12:39:02 -0500
>> From: Christos Zoulas
>>
>> Yes, unfortunately I committed the version from my tree by accident
>> and not the one that was on the web server. I already fixed it.
>
> No,
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
Yes, unfortunately I committed the version from my tree by accident and not the
one
that was on the web server. I already fixed it.
christos
signature.asc
Description: Message signed with OpenPGP
> Module Name:src
> Committed By: christos
> Date: Thu Feb 27 10:55:27 UTC 2025
>
> Modified Files:
> src/lib/libc/arch/arm/misc: arm_initfini.c
>
> Log Message:
> use the latest version that does not abort on error.
>
> @@ -46,6 +46,7 @@
> #include
> #include
> #inc
Taylor R Campbell wrote in
<20241221185628.a4efaf...@cvs.netbsd.org>:
|Module Name: src
|Committed By: riastradh
|Date: Sat Dec 21 18:56:28 UTC 2024
|
|Modified Files:
| src/lib/libc/sys: close.2
|
|Log Message:
|close(2): Document the finality of closing.
|
|Even if close(2) r
> Module Name:src
> Committed By: christos
> Date: Sat Sep 28 14:24:59 UTC 2024
>
> Modified Files:
> src/lib/libc/include: extern.h
>
> Log Message:
> need for __off_t in gnu11 mode.
Why do we need to use __off_t in particular here?
This file is purely internal to libc
> Date: Sat, 14 Sep 2024 22:26:37 - (UTC)
> From: chris...@astron.com (Christos Zoulas)
>
> In article ,
> Thomas Klausner wrote:
> >On Wed, Sep 11, 2024 at 09:50:35AM -0400, Christos Zoulas wrote:
> >> POSIX.1-2024 removes asctime_r and ctime_r and does not let
> >> libraries define
chris...@astron.com (Christos Zoulas) writes:
>>> POSIX.1-2024 removes asctime_r and ctime_r and does not let
>>> libraries define them, so remove them except when needed to
>>> conform to earlier POSIX. These functions are dangerous as they
>>> can overrun user buffers. If you s
In article ,
Thomas Klausner wrote:
>On Wed, Sep 11, 2024 at 09:50:35AM -0400, Christos Zoulas wrote:
>> Module Name: src
>> Committed By:christos
>> Date:Wed Sep 11 13:50:35 UTC 2024
>>
>> Modified Files:
>> src/lib/libc/compat/time: compat_localtime.c
>> src/l
On Wed, Sep 11, 2024 at 09:50:35AM -0400, Christos Zoulas wrote:
> Module Name: src
> Committed By: christos
> Date: Wed Sep 11 13:50:35 UTC 2024
>
> Modified Files:
> src/lib/libc/compat/time: compat_localtime.c
> src/lib/libc/time: CONTRIBUTING Makefile Makefile.inc NEWS asc
> Date: Sun, 18 Aug 2024 19:55:10 +0200
> From: Roland Illig
>
> Am 18.08.2024 um 15:39 schrieb Taylor R Campbell:
> > Please revert the casts and use `LINTFLAGS.mbrtoc8.c+= -X 132' instead
> > until it is fixed.
>
> It is fixed.
Awesome, thanks!
Am 18.08.2024 um 15:39 schrieb Taylor R Campbell:
>> Date: Sat, 17 Aug 2024 17:55:28 -0400
>> From: Christos Zoulas
>>
>> There is only one bug. I have sent mail to Roland about it and will revert
>> once it is fixed.
>>
>> The rest are:
>> - cast through (void *)
>> - add casts because __BITS re
> Date: Sat, 17 Aug 2024 17:55:28 -0400
> From: Christos Zoulas
>
> There is only one bug. I have sent mail to Roland about it and will revert
> once it is fixed.
>
> The rest are:
> - cast through (void *)
> - add casts because __BITS returns uintmax_t which is wider than the
> destination t
Hi,
For __CTASSERT v.s. case label:
https://nxr.netbsd.org/xref/src/lib/libc/locale/c8rtomb.c#225
not only lint(1), but also GCC 10.5 does not accept this, which
results in build failures for platforms still using gcc.old:
https://releng.netbsd.org/builds/HEAD/202408171750Z/
Can we just drop
> Date: Sat, 17 Aug 2024 17:55:28 -0400
> From: Christos Zoulas
>
> There is only one bug. I have sent mail to Roland about it and will revert
> once it is fixed.
>
> The rest are:
> - cast through (void *)
There is no need to cast through (void *) -- not in C, not in KNF, and
not for any oth
There is only one bug. I have sent mail to Roland about it and will revert once
it is fixed.
The rest are:
- cast through (void *)
- add casts because __BITS returns uintmax_t which is wider than the
destination types.
christos
> On Aug 17, 2024, at 5:29 PM, Taylor R Campbell wrote:
>
>> Mo
> Module Name:src
> Committed By: christos
> Date: Sat Aug 17 20:08:13 UTC 2024
>
> Modified Files:
> src/lib/libc/locale: c16rtomb.c c8rtomb.c mbrtoc16.c mbrtoc32.c
> mbrtoc8.c
>
> Log Message:
> pass lint, XXX see lint bug.
Can you please arrange to fix the
> Date: Sat, 8 Jun 2024 11:51:43 +0200
> From: Roland Illig
>
> Am 07.06.2024 um 22:50 schrieb Taylor R Campbell:
> > libc: Pacify lint on aarch64.
> >
> > +++ src/lib/libc/stdlib/Makefile.incFri Jun 7 20:50:13 2024
> > +# lint(1) spuriously complains about `*s == CHAR_MAX' even though *
Am 07.06.2024 um 22:50 schrieb Taylor R Campbell:
> libc: Pacify lint on aarch64.
>
> +++ src/lib/libc/stdlib/Makefile.inc Fri Jun 7 20:50:13 2024
> +# lint(1) spuriously complains about `*s == CHAR_MAX' even though *s
> +# has type char.
> +LINTFLAGS.strfmon.c += -X 230
I guess the "spuriously"
Valery Ushakov wrote in
:
|On Fri, Dec 08, 2023 at 01:32:49 +0300, Valery Ushakov wrote:
|
|> On Thu, Dec 07, 2023 at 20:13:37 +, Robert Elz wrote:
|>
|>> While here, consistemntly use minus when minus is meant, rather that
|>> just using a hyphen.
|>
|> One has to be careful with this
On Fri, Dec 08, 2023 at 01:32:49 +0300, Valery Ushakov wrote:
> On Thu, Dec 07, 2023 at 20:13:37 +, Robert Elz wrote:
>
> > While here, consistemntly use minus when minus is meant, rather that
> > just using a hyphen.
>
> One has to be careful with this.
And to have this on record for refernc
On Thu, Dec 07, 2023 at 20:13:37 +, Robert Elz wrote:
> While here, consistemntly use minus when minus is meant, rather that
> just using a hyphen.
One has to be careful with this. In the literal context (Ql, Li, etc)
the ascii minus-hyphen in the input is preserved as such. In other
contex
On Wednesday, November 15, 2023 4:15:28 AM CET you wrote:
> Module Name: src
> Committed By: christos
> Date: Wed Nov 15 03:15:28 UTC 2023
>
> Modified Files:
> src/lib/libc/ssp: Makefile.inc
> Added Files:
> src/lib/libc/ssp: ssp_redirect.c
>
> Log Message:
> provide materia
> Minor changes to jemalloc100 (the old one that only vax etc currently uses).
thanks.
i'm still using this version on a bunch of modern machines.
new jemalloc was problematic for a few things for me a
number of years ago and i keep meaning to test again, but
for now i'm still mostly using this
Date:Wed, 26 Oct 2022 10:42:15 -0400
From:Jan Schaumann
Message-ID:
| New proposal:
That looks better (it needs some minor wording changes,
there are too many indefinite articles ('a') which aren't
needed, and there midnight should be just that, no hyphen
or space
Robert Elz wrote:
> Date:Sun, 23 Oct 2022 13:53:01 -0400
> From:Jan Schaumann
> Message-ID:
>
> | Hmm, maybe something like this?
>
> I think there is still too much there, you don't have
> to explain everything (or almost anything), but it is
> in the right dire
Taylor R Campbell wrote in
<20221023170035.2542f60...@jupiter.mumble.net>:
...
|If you use a monotonic timer to sample the POSIX clock before and
|after a leap second, the POSIX clock will appear to have taken twice
|as long as it should to pass the leap second.
Just to note that the next lea
Date:Sun, 23 Oct 2022 13:53:01 -0400
From:Jan Schaumann
Message-ID:
| Hmm, maybe something like this?
I think there is still too much there, you don't have
to explain everything (or almost anything), but it is
in the right direction I think.
| For example, cons
On Sun, Oct 23, 2022 at 11:00 AM Taylor R Campbell <
campbell+netbsd-source-change...@mumble.net> wrote:
> > Date: Sun, 23 Oct 2022 07:39:25 -0600
> > From: Warner Losh
> >
> > I guess a more accurate way of saying this is that leap seconds simply
> > aren't reliable, cannot be made reliable, and
> Date: Sun, 23 Oct 2022 12:19:37 -0600
> From: Warner Losh
>
> You must have a table of all past
> leap seconds to do any kind of sensible mapping. And you also must
> have some way to keep that up to date, [...]
It's the same for all civil calendar matters
Robert Elz wrote:
> Date:Sat, 22 Oct 2022 13:42:54 -0400
> From:Jan Schaumann
> Message-ID:
>
> | A full set of examples strikes me as too much here
>
> A full set would be yes, but I think we could handle 3.
Hmm, maybe something like this?
...and will be
> Date: Sun, 23 Oct 2022 07:39:25 -0600
> From: Warner Losh
>
> I guess a more accurate way of saying this is that leap seconds simply
> aren't reliable, cannot be made reliable, and this affects normalization
> in ways too numerous to mention due to the details of the tz files, bugs
> in the sys
On Sat, Oct 22, 2022 at 10:55 PM Robert Elz wrote:
> Date:Sat, 22 Oct 2022 20:17:57 -0600
> From:Warner Losh
> Message-ID: <
> canczdfqhkz0xs7lf6lmjveontc5dgsonons_ug6fzsf30og...@mail.gmail.com>
>
>
> | On the other hand, adding a caveat that leap seconds don't exi
On Sat, Oct 22, 2022, 8:05 PM Robert Elz wrote:
> Date:Sat, 22 Oct 2022 13:42:54 -0400
> From:Jan Schaumann
> Message-ID:
>
> | A full set of examples strikes me as too much here
>
> A full set would be yes, but I think we could handle 3.
> They don't need to be C
Date:Sat, 22 Oct 2022 20:17:57 -0600
From:Warner Losh
Message-ID:
| On the other hand, adding a caveat that leap seconds don't exist in a POSIX
| time_t and that's necessarily reflected in the normalization wouldn't be
| bad.
The problem with doing that is t
Date:Sun, 23 Oct 2022 08:33:18 +0700
From:Robert Elz
Message-ID: <7638.1666488...@jacaranda.noi.kre.to>
| and tm_min was incremented as tm_min+=180, and then
| mktime() called upon the result, the struct tm would
| now have tm_min==1 tm_hour==24 and tm_mday==20,
Date:Sat, 22 Oct 2022 13:42:54 -0400
From:Jan Schaumann
Message-ID:
| A full set of examples strikes me as too much here
A full set would be yes, but I think we could handle 3.
They don't need to be C code examples, just something
like
if tm_year==2022 tm_
Robert Elz wrote:
> jo...@bec.de said:
> | I'd actually weasle out a bit
>
> Yes, I would too, but
A full set of examples strikes me as too much here
still, and I do like the idea of weaseling out.
Perhaps:
This normalization is done in order from tm_sec up to
tm_year, possibly leading to ca
Date:Fri, 21 Oct 2022 15:00:41 -0400
From:Jan Schaumann
Message-ID:
| I believe that it's useful for people to know that
| values outside the normal ranges are normalized,
Agreed.
| as well as what that might look like.
The problem with trying to specify tha
Am Fri, Oct 21, 2022 at 02:06:32PM +0700 schrieb Robert Elz:
> Date:Fri, 21 Oct 2022 03:05:15 +
> From:"Jan Schaumann"
> Message-ID: <20221021030515.cdc9df...@cvs.netbsd.org>
>
> | Note normalizing behavior of mktime(3) using language from FreeBSD.
>
> If we ar
Robert Elz wrote:
> Date:Fri, 21 Oct 2022 11:54:08 -0400
> From:Jan Schaumann
> Message-ID:
>
> | Right, but all that strikes me as too much to put into
> | the manual page here.
>
> I agree, which is why I wondered if we should be giving any
> details about ho
Date:Fri, 21 Oct 2022 11:54:08 -0400
From:Jan Schaumann
Message-ID:
| Right, but all that strikes me as too much to put into
| the manual page here.
I agree, which is why I wondered if we should be giving any
details about how it is done at all.
| I think wha
Robert Elz wrote:
> Date:Fri, 21 Oct 2022 10:36:23 -0400
> From:Jan Schaumann
> Message-ID:
>
>
> | Perhaps like this?
>
> Like that, yes, but as you wrote it isn't how it is actually
> done I believe.
>
> The order looks to be secs, mins, hours, month, day(of
Date:Fri, 21 Oct 2022 10:36:23 -0400
From:Jan Schaumann
Message-ID:
| Perhaps like this?
Like that, yes, but as you wrote it isn't how it is actually
done I believe.
The order looks to be secs, mins, hours, month, day(of month).
There's no normalisation of the
Robert Elz wrote:
> Date:Fri, 21 Oct 2022 03:05:15 +
> From:"Jan Schaumann"
> Message-ID: <20221021030515.cdc9df...@cvs.netbsd.org>
>
> | Note normalizing behavior of mktime(3) using language from FreeBSD.
>
> If we are going to start specifying what happens (
Date:Fri, 21 Oct 2022 03:05:15 +
From:"Jan Schaumann"
Message-ID: <20221021030515.cdc9df...@cvs.netbsd.org>
| Note normalizing behavior of mktime(3) using language from FreeBSD.
If we are going to start specifying what happens (how the struct tm
is normalised)
Date:Thu, 29 Sep 2022 08:18:49 -0400
From:Christos Zoulas
Message-ID:
| Yes, I had forgotten about the need to do this explicitly...
| > On Sep 28, 2022, at 10:23 PM, Robert Elz wrote:
| >
| > Apologies, I did not read the code closely enough, there must b
Yes, I had forgotten about the need to do this explicitly...
christos
> On Sep 28, 2022, at 10:23 PM, Robert Elz wrote:
>
> Apologies, I did not read the code closely enough, there must be a bug
> in the way the clone file descriptor is created.
>
> kre
signature.asc
Description: Message si
Apologies, I did not read the code closely enough, there must be a bug
in the way the clone file descriptor is created.
kre
Date:Wed, 28 Sep 2022 20:48:53 -0400
From:"David H. Gutteridge"
Message-ID: <9c9c8e9d9384338320b47dabfdc94...@gutteridge.ca>
| (O_CLOEXEC, on the other hand, is ignored, at the moment.)
No it isn't, your test is faulty, O_CLOEXEC is a different
kind of flag, ap
On Wed, 28 Sep 2022, at 15:07:41 - (UTC), Christos Zoulas wrote:
In article <20220928003547.D2375FA92%cvs.NetBSD.org@localhost>,
David H. Gutteridge wrote:
-=-=-=-=-=-
Module Name:src
Committed By: gutteridge
Date: Wed Sep 28 00:35:47 UTC 2022
Modified Files:
src/l
In article <20220928003547.d2375f...@cvs.netbsd.org>,
David H. Gutteridge wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: gutteridge
>Date: Wed Sep 28 00:35:47 UTC 2022
>
>Modified Files:
> src/lib/libc/stdlib: posix_openpt.3
>
>Log Message:
>posix_openpt.3: reflect flag c
> 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
In article <977b81a4-d330-6722-7ce4-cc4e61011...@gmx.de>,
Roland Illig wrote:
>Am 25.03.2022 um 22:25 schrieb Christos Zoulas:
>> In article <20220325183551.0f039f...@cvs.netbsd.org>,
>> Roland Illig wrote:
>>> -=-=-=-=-=-
>>>
>>> Module Name:src
>>> Committed By: rillig
>>> Date:
Am 26.03.2022 um 00:50 schrieb Tobias Nygren:
On Sat, 26 Mar 2022 00:31:45 +0100
Roland Illig wrote:
localtime.c: add back storage class 'register'
This reduces the differences to the upstream code.
I don't know why you did that. It is as simple to sed -e 's/register //g'
in upstream when y
On Sat, 26 Mar 2022 00:31:45 +0100
Roland Illig wrote:
> >> localtime.c: add back storage class 'register'
> >>
> >> This reduces the differences to the upstream code.
> >
> > I don't know why you did that. It is as simple to sed -e 's/register //g'
> > in upstream when you diff. Adding register
Am 25.03.2022 um 22:25 schrieb Christos Zoulas:
In article <20220325183551.0f039f...@cvs.netbsd.org>,
Roland Illig wrote:
-=-=-=-=-=-
Module Name:src
Committed By: rillig
Date: Fri Mar 25 18:35:50 UTC 2022
Modified Files:
src/lib/libc/time: localtime.c
Log Message:
lo
In article ,
Roland Illig wrote:
>
>The mess with the indentation comes from upstream. In our copy it's a
>bit worth than upstream, but not much.
I've asked upstream to indent consistently in the past. It has not happened.
I try to minimize the diffs with upstream so that we can keep patching i
In article <20220325183551.0f039f...@cvs.netbsd.org>,
Roland Illig wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: rillig
>Date: Fri Mar 25 18:35:50 UTC 2022
>
>Modified Files:
> src/lib/libc/time: localtime.c
>
>Log Message:
>localtime.c: add back storage class 'register'
In article <20220325190016.15114f...@cvs.netbsd.org>,
Roland Illig wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: rillig
>Date: Fri Mar 25 19:00:16 UTC 2022
>
>Modified Files:
> src/lib/libc/time: localtime.c
>
>Log Message:
>localtime.c: take indentation style from upstr
Am 25.03.2022 um 13:59 schrieb Robert Elz:
Date:Thu, 24 Mar 2022 23:32:30 +0100
From:Roland Illig
Message-ID: <6bb00924-edaf-a4c8-348e-ba1304d57...@gmx.de>
| Someone should clean up this mess.
No, they probabky shouldn't, in general.
That source comes from t
Date:Thu, 24 Mar 2022 23:32:30 +0100
From:Roland Illig
Message-ID: <6bb00924-edaf-a4c8-348e-ba1304d57...@gmx.de>
| Someone should clean up this mess.
No, they probabky shouldn't, in general.
That source comes from the tz project (currently from
tzcode2022a) with l
Am 24.03.2022 um 17:15 schrieb Christos Zoulas:
Module Name:src
Committed By: christos
Date: Thu Mar 24 16:15:05 UTC 2022
Modified Files:
src/lib/libc/time: localtime.c
Log Message:
put back the 2022a changes and fix the misplaced brace.
To generate a diff of this comm
On Wed, Mar 23, 2022 at 02:00:29PM +0100, Tobias Nygren wrote:
> I think this commit broke something.
> date(1) no longer reports a time zone and is stuck at GMT time:
>
> $ ls -l /etc/localtime
> lrwxr-xr-x 1 root wheel 36 Mar 22 08:47 /etc/localtime ->
> /usr/share/zoneinfo/Europe/Stockholm
On Tue, 22 Mar 2022 13:48:39 -0400
Christos Zoulas wrote:
> Modified Files:
> src/lib/libc/time: CONTRIBUTING Makefile NEWS localtime.c private.h
> theory.html tz-link.html tzselect.8 tzselect.ksh version zdump.c
> zic.c
>
> Log Message:
> welcome to tzcode-2022a
Hi,
On Sat, 12 Mar 2022 08:26:01 +
Nia Alarie wrote:
> Module Name: src
> Committed By: nia
> Date: Sat Mar 12 08:26:01 UTC 2022
>
> Modified Files:
> src/lib/libc/stdlib: hcreate.c
>
> Log Message:
> hcreate(3): use reallocarr instead of malloc(x * y)
Caution: malloc(0) and rea
On Sat, Feb 12, 2022, 11:52 AM Taylor R Campbell <
campbell+netbsd-source-change...@mumble.net> wrote:
> > Date: Sun, 13 Feb 2022 05:44:38 +1100
> > from: matthew green
> >
> > "Roland Illig" writes:
> > > Module Name:src
> > > Committed By: rillig
> > > Date: Fri Feb
Am 12.02.2022 um 20:10 schrieb Warner Losh:
I thought the rule was don't make purely whitespace changes UNLESS you
plan on making other changes to (or are fixing an oops you just made).
If that's the case, separate the two commits.
That sounds like a useful rule, I'll stick to it.
Roland
> Date: Sun, 13 Feb 2022 05:44:38 +1100
> from: matthew green
>
> "Roland Illig" writes:
> > Module Name:src
> > Committed By: rillig
> > Date: Fri Feb 11 21:36:46 UTC 2022
> >
> > Modified Files:
> > src/lib/libc/stdlib: getenv.c
> >
> > Log Message:
> > libc/gete
"Roland Illig" writes:
> Module Name: src
> Committed By: rillig
> Date: Fri Feb 11 21:36:46 UTC 2022
>
> Modified Files:
> src/lib/libc/stdlib: getenv.c
>
> Log Message:
> libc/getenv: remove trailing whitespace
>
> No binary change.
please avoid purely whitespace changes unless yo
On Fri, Oct 29, 2021 at 10:11:57AM +, Nia Alarie wrote:
> Module Name: src
> Committed By: nia
> Date: Fri Oct 29 10:11:57 UTC 2021
>
> Modified Files:
> src/lib/libc/string: wcsdup.c
>
> Log Message:
> wcsdup(3): use reallocarr to catch integer overflow
Except that no such in
On 2021/07/25 6:32, Joerg Sonnenberger wrote:
On Sat, Jul 24, 2021 at 05:27:26AM +, Rin Okuyama wrote:
Module Name:src
Committed By: rin
Date: Sat Jul 24 05:27:26 UTC 2021
Modified Files:
src/lib/libc/arch/powerpc/string: Makefile.inc
Log Message:
For evbppc, use C
On Sat, Jul 24, 2021 at 05:27:26AM +, Rin Okuyama wrote:
> Module Name: src
> Committed By: rin
> Date: Sat Jul 24 05:27:26 UTC 2021
>
> Modified Files:
> src/lib/libc/arch/powerpc/string: Makefile.inc
>
> Log Message:
> For evbppc, use C version of bcopy(3), memcpy(3), memcmp(
Oops, this is broken. I will fix shortly...
rin
On 2021/06/30 8:29, Rin Okuyama wrote:
Module Name:src
Committed By: rin
Date: Tue Jun 29 23:29:12 UTC 2021
Modified Files:
src/lib/libc/arch/arm/gen: swapcontext.S
src/lib/libc/arch/arm/sys: __clone.S
Log Message
Date:Mon, 14 Jun 2021 03:56:48 +0200
From:Joerg Sonnenberger
Message-ID:
| This is even more true for multi-threaded applications
| (where POSIX explicitly suggests that requirement).
Sure, anything with fork() and threads has issues, that's messy.
Even I know t
On Mon, Jun 14, 2021 at 01:33:51AM +0700, Robert Elz wrote:
> Date:Sat, 12 Jun 2021 23:13:54 +0200
> From:Joerg Sonnenberger
> Message-ID:
>
> Sorry, missed this message when I was cherry picking messages to read in
> a timely fashion.
>
> | On Wed, Jun 09, 2021 a
Date:Sat, 12 Jun 2021 23:13:54 +0200
From:Joerg Sonnenberger
Message-ID:
Sorry, missed this message when I was cherry picking messages to read in
a timely fashion.
| On Wed, Jun 09, 2021 at 01:03:20AM +0700, Robert Elz wrote:
| > after a vfork() the child can do
On Wed, Jun 09, 2021 at 01:03:20AM +0700, Robert Elz wrote:
> It should, when it is workable for the application, make things
> faster, while also avoiding the vfork() perils. But only when
> it works -- after a vfork() the child can do anything (it should
> avoid touching its parent's state, but
Date:Tue, 8 Jun 2021 16:15:12 +
From:"Nia Alarie"
Message-ID: <20210608161512.1d7c3f...@cvs.netbsd.org>
| vfork.2: recommend posix_spawn instead
You might want to reconsider the wording there, posix_spawn() is
an alternative to [v]fork() + exec*(). Not just v
In article <5c9e716-7ec1-9c7d-a7cb-21f08946...@invisible.ca>,
Jared McNeill wrote:
>Building tools on macOS:
>
>/Users/jmcneill/netbsd/git-src/tools/compat/../../lib/libc/regex/regcomp.c:1585:8:
>
>error: implicit declaration of function 'reallocarray' is invalid
> in C99 [-Werror,-Wimplic
Building tools on macOS:
/Users/jmcneill/netbsd/git-src/tools/compat/../../lib/libc/regex/regcomp.c:1585:8:
error: implicit declaration of function 'reallocarray' is invalid
in C99 [-Werror,-Wimplicit-function-declaration]
ncs = reallocarray(p->g->sets, p->g->ncsets + 1, sizeof(*n
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 Mon, Feb 15, 2021 at 04:37:15PM +0100, Thomas Klausner wrote:
> Hi!
>
> Thanks for the man pages.
>
> There is none for uselocale(3), which is heavily referenced from
> these, nor do I find a prototype in /usr/include...
> so how does one use these? :)
We don't support uselocale. You use this
Hi!
Thanks for the man pages.
There is none for uselocale(3), which is heavily referenced from
these, nor do I find a prototype in /usr/include...
so how does one use these? :)
Thomas
On Mon, Feb 15, 2021 at 09:35:04AM -0500, Christos Zoulas wrote:
> Module Name: src
> Committed By: christos
>
Date:Mon, 1 Feb 2021 17:50:54 +
From:"Jaromir Dolecek"
Message-ID: <20210201175054.112e7f...@cvs.netbsd.org>
| FreeBSD has a similar check, but they return EINVAL instead, feel
| free to adjust if SUS or other standard mandates specific value
Not currently (u
Date:Sun, 31 Jan 2021 18:34:22 +0100
From:Joerg Sonnenberger
Message-ID:
| That makes no sense. Just turn them into a short read, which is
| something users have to deal with anyway.
I'm not sure I agree with that one. If the user's size * nmemb
overflows a si
On 31.01.2021 18:34, Joerg Sonnenberger wrote:
> On Sun, Jan 31, 2021 at 05:27:28PM +0100, Kamil Rytarowski wrote:
>> On 31.01.2021 17:18, Jaromir Dolecek wrote:
>>> Module Name:src
>>> Committed By: jdolecek
>>> Date: Sun Jan 31 16:18:22 UTC 2021
>>>
>>> Modified Files:
1 - 100 of 574 matches
Mail list logo
