On Sun, Apr 06, 2025 at 03:27:23AM +, Taylor R Campbell wrote:
> FYI, this was not an accidental local change; I deliberately committed
> this so that it would run on the releng testbed because I was unable
> to reproduce the problem locally.
But it broke the build, so the testbed could not ru
> Module Name:src
> Committed By: martin
> Date: Wed Apr 2 07:25:42 UTC 2025
>
> Modified Files:
> src/lib/librumpuser: sp_common.c
>
> Log Message:
> Revert accidental local test change from previous - the DEBUG define
> is passed on the command line already.
FYI, this
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
On Mon, Feb 24, 2025 at 12:28:22AM +0100, Joerg Sonnenberger wrote:
>
>
> On 2/23/25 8:34 PM, Thomas Klausner wrote:
> > On Mon, Feb 24, 2025 at 06:32:09AM +1100, Matthew Green wrote:
> > > > Log Message:
> > > > Add LIBRARY section and explicitly mention that these interfaces
> > > > require sup
On 2/23/25 8:34 PM, Thomas Klausner wrote:
On Mon, Feb 24, 2025 at 06:32:09AM +1100, Matthew Green wrote:
Log Message:
Add LIBRARY section and explicitly mention that these interfaces
require super-user privileges.
this can be relaxed with the
security.models.extensions.user_set_cpu_affinit
On Mon, Feb 24, 2025 at 06:32:09AM +1100, Matthew Green wrote:
> > Log Message:
> > Add LIBRARY section and explicitly mention that these interfaces
> > require super-user privileges.
>
> this can be relaxed with the
> security.models.extensions.user_set_cpu_affinity sysctl.
I found this and wond
> Log Message:
> Add LIBRARY section and explicitly mention that these interfaces
> require super-user privileges.
this can be relaxed with the
security.models.extensions.user_set_cpu_affinity sysctl.
.mrg.
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
On Wed, 30 Oct 2024 06:59:45 Taylor R Campbell wrote:
> > Date: Wed, 30 Oct 2024 04:30:44 +0900
> > From: Izumi Tsutsui
> >
> > riastradh@ wrote:
> > > Is this configuration
> > > relevant for real-world hardware or is it more of a `for fun' option?
> >
> > The only use case is to run NetBSD/mac
On Tue, Oct 29, 2024 at 07:59:45PM +, Taylor R Campbell wrote:
> Yes, I think we need a new MACHINE_ARCH for that, maybe m68ksf. But
> maybe effort is better spent on making FPU_EMULATE work than on
> dealing with a new ABI.
I think this is impossible w/o compiler/linker support and doing spe
> Date: Wed, 30 Oct 2024 04:30:44 +0900
> From: Izumi Tsutsui
>
> riastradh@ wrote:
>
> > Is this configuration
> > relevant for real-world hardware or is it more of a `for fun' option?
>
> The only use case is to run NetBSD/mac68k on XC68LC040 machines.
>
> It looks he "options FPU_EMULATE" f
riastradh@ wrote:
> Interesting, thanks, so that means we don't have any automatic builds
> (let alone tests) of m68k MKSOFTFLOAT=yes?
Currently no m68k architecture that use softfloat by default,
so MKSOFTFLOAT is optional.
> Is this configuration
> relevant for real-world hardware or is it mor
> Date: Wed, 30 Oct 2024 01:45:45 +1100
> From: Nathanial Sloss
>
> On Tue, 29 Oct 2024 23:30:47 Taylor R Campbell wrote:
> > > Pull in missing functions for MKSOFTFLOAT.
> >
> > That's interesting, how did you notice these were missing? What build
> > does this affect?
>
> mac68k MKSOFTFLOAT.
On Tue, 29 Oct 2024 23:30:47 Taylor R Campbell wrote:
> > Module Name:src
> > Committed By: nat
> > Date: Tue Oct 29 01:34:18 UTC 2024
> >
> > Modified Files:
> > src/lib/libm: Makefile
> >
> > Log Message:
> > Pull in missing functions for MKSOFTFLOAT.
>
> That's interes
> Module Name:src
> Committed By: nat
> Date: Tue Oct 29 01:34:18 UTC 2024
>
> Modified Files:
> src/lib/libm: Makefile
>
> Log Message:
> Pull in missing functions for MKSOFTFLOAT.
That's interesting, how did you notice these were missing? What build
does this affect?
> 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"
Date:Wed, 1 May 2024 22:27:02 +0200
From:Roland Illig
Message-ID: <754bd755-be0a-4eff-aa7b-d53fce9b4...@gmx.de>
| > Log Message:
| > next should increement by 1 not 2.
|
| Are you sure?
I agree, that change should be reverted.
"next" is even documented to be
Am 01.05.2024 um 21:59 schrieb Christos Zoulas:
> Module Name: src
> Committed By: christos
> Date: Wed May 1 19:59:08 UTC 2024
>
> Modified Files:
> src/lib/libutil: parsedate.y
>
> Log Message:
> next should increement by 1 not 2.
Are you sure? I get these test results:
> t_pars
On Mon, Apr 08, 2024 at 23:31:16 +0200, Roland Illig wrote:
> Am 08.04.2024 um 21:18 schrieb Valery Ushakov:
> > "=\017FIFTEEN\0"
> >
> > with its result a few lines below that has:
> >
> > BURST=0xf=FIFTEEN
>
> Thank you for explaining this example. I had a gut feeling that there
> would be
Am 08.04.2024 um 21:18 schrieb Valery Ushakov:
> "=\017FIFTEEN\0"
>
> with its result a few lines below that has:
>
> BURST=0xf=FIFTEEN
Thank you for explaining this example. I had a gut feeling that there
would be some hidden correlation between some octal/hexadecimal
combinations, but I coul
On Mon, Apr 08, 2024 at 20:21:07 +0200, Roland Illig wrote:
> I didn't eradicate _all_ hexadecimal examples, I just made each example
> use only one number base, not mix them both. There are both octal and
> hexadecimal examples in the manual page.
That's not what "prefer octal in examples" conve
Am 08.04.2024 um 03:24 schrieb Valery Ushakov:
> On Sun, Apr 07, 2024 at 14:28:27 +, Roland Illig wrote:
>
>> Log Message:
>> snprintb.3: clean up formatting and wording, prefer octal in examples
>>
>> Using hexadecimal character escapes requires separate string literals if
>> the description s
On Sun, Apr 07, 2024 at 14:28:27 +, Roland Illig wrote:
> Log Message:
> snprintb.3: clean up formatting and wording, prefer octal in examples
>
> Using hexadecimal character escapes requires separate string literals if
> the description starts with one of the letters A-F; octal character
> e
On Sun, Jan 21, 2024 at 21:31:23 +, Roland Illig wrote:
> and also didn't make it clear that a few bits were omitted from
> having descriptions.
I dislike this part. It's internally inconsistent as it doesn't add
the placeholders for the low bits; and in many real-life scenarios
there will b
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
"Taylor R Campbell" writes:
> Module Name: src
> Committed By: riastradh
> Date: Mon Mar 13 18:18:36 UTC 2023
>
> Modified Files:
> src/lib/libm/src: ldbl_dummy.c
>
> Log Message:
> libm: Fill in more dummy long double transcendental functions.
>
> This should cover everything from C
Hi,
r1.125 of refresh.c breaks /usr/bin/vi for me.
When scrolling down long file with 'j' key and reaches the bottom
line, screen is not scrolled up and new lines are displayed
over the previous bottom line.
Could you take a look at my problem?
Thank you very much.
"Brett Lymn" writes:
> Modu
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
1 - 100 of 1036 matches
Mail list logo
