> 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
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
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
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
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
> 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
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
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
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,
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,
> 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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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:
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
> 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
> 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
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:
> >
> 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
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
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
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:
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
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
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
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
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
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
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
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:
> >
"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
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
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),
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
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
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
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
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,
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
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
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,
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
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
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
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
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
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:
> > src/lib/libc/stdio: fread.c
> >
> >
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:
> src/lib/libc/stdio: fread.c
>
> Log Message:
> for unbuffered I/O arrange for the destination buffer to be filled in one
> go, instead
Date:Sat, 4 Apr 2020 21:16:45 +
From:David Holland
Message-ID: <20200404211645.ga19...@netbsd.org>
| I fail to see any scenario in which it's legitimate for an application
| to scribble in internal data belonging to libc. Why should this be
| permitted?
On Thu, Mar 26, 2020 at 10:54:21AM +0700, Robert Elz wrote:
> | I don't agree -- because applications shouldn't attempt to modify the
> | result, it should be const.
>
> The only reason apps shouldn't modify the string is in case of
> porting the app to an (well, some) ancient
On Thu, Mar 26, 2020 at 10:54:21AM +0700, Robert Elz wrote:
> Date:Wed, 25 Mar 2020 20:51:25 +
> From:David Holland
> Message-ID: <20200325205125.ga11...@netbsd.org>
>
> | I don't agree -- because applications shouldn't attempt to modify the
> | result, it
Date:Wed, 25 Mar 2020 20:51:25 +
From:David Holland
Message-ID: <20200325205125.ga11...@netbsd.org>
| I don't agree -- because applications shouldn't attempt to modify the
| result, it should be const.
The only reason apps shouldn't modify the string is in
On Wed, Mar 25, 2020 at 06:50:47PM +, Robert Elz wrote:
> Modified Files:
> src/lib/libc/string: strerror.3
>
> Log Message:
> Delete the BUGS paragraph about the "missing" const qualifier for the
> result type of strerror() (and strerror_l()). While that once should
> really
(added port-sun2@)
On 2020/03/09 3:33, Joerg Sonnenberger wrote:
On Sun, Mar 08, 2020 at 06:30:06AM +, Rin Okuyama wrote:
Module Name:src
Committed By: rin
Date: Sun Mar 8 06:30:06 UTC 2020
Modified Files:
src/lib/libc/compiler_rt: Makefile.inc
Log Message:
Fix
On Sun, Mar 08, 2020 at 06:30:06AM +, Rin Okuyama wrote:
> Module Name: src
> Committed By: rin
> Date: Sun Mar 8 06:30:06 UTC 2020
>
> Modified Files:
> src/lib/libc/compiler_rt: Makefile.inc
>
> Log Message:
> Fix broken printf(3) %d output for numbers more than two digits,
Oops, forgot to note that this is only for 68010, and other
systems including m68k are not affected.
Thanks,
rin
On 2020/03/08 15:30, Rin Okuyama wrote:
Module Name:src
Committed By: rin
Date: Sun Mar 8 06:30:06 UTC 2020
Modified Files:
src/lib/libc/compiler_rt:
On Sun, Feb 23, 2020 at 10:57:28 +0100, Kamil Rytarowski wrote:
> On 23.02.2020 08:46, Martin Husemann wrote:
>
> > Source code consistency is a very important stylistic plus, every break of
> > that should be accompanied by a comment.
>
> Done.
Thank you.
-uwe
On 23.02.2020 08:46, Martin Husemann wrote:
> On Sun, Feb 23, 2020 at 03:35:19AM +0100, Kamil Rytarowski wrote:
>> Algorithm would be changed from calculating on 32bit numbers with signed
>> integer overflows to an algorithm calculating on 64bit numbers. The
>> __dorand48() function truncates the
On Sun, Feb 23, 2020 at 03:35:19AM +0100, Kamil Rytarowski wrote:
> Algorithm would be changed from calculating on 32bit numbers with signed
> integer overflows to an algorithm calculating on 64bit numbers. The
> __dorand48() function truncates the result to least significant 16bits
> only so it
On Sun, Feb 23, 2020 at 03:35:19 +0100, Kamil Rytarowski wrote:
> On 23.02.2020 03:20, Valery Ushakov wrote:
> > On Sun, Feb 23, 2020 at 02:51:49 +0100, Kamil Rytarowski wrote:
> >
> >> On 23.02.2020 02:29, Valery Ushakov wrote:
> >>> On Sat, Feb 22, 2020 at 14:07:57 +, Kamil Rytarowski
On 23.02.2020 03:20, Valery Ushakov wrote:
> On Sun, Feb 23, 2020 at 02:51:49 +0100, Kamil Rytarowski wrote:
>
>> On 23.02.2020 02:29, Valery Ushakov wrote:
>>> On Sat, Feb 22, 2020 at 14:07:57 +, Kamil Rytarowski wrote:
>>>
Module Name: src
Committed By: kamil
Date:
On Sun, Feb 23, 2020 at 02:51:49 +0100, Kamil Rytarowski wrote:
> On 23.02.2020 02:29, Valery Ushakov wrote:
> > On Sat, Feb 22, 2020 at 14:07:57 +, Kamil Rytarowski wrote:
> >
> >> Module Name: src
> >> Committed By: kamil
> >> Date: Sat Feb 22 14:07:57 UTC 2020
> >>
On 23.02.2020 02:29, Valery Ushakov wrote:
> On Sat, Feb 22, 2020 at 14:07:57 +, Kamil Rytarowski wrote:
>
>> Module Name: src
>> Committed By:kamil
>> Date:Sat Feb 22 14:07:57 UTC 2020
>>
>> Modified Files:
>> src/lib/libc/stdlib: _rand48.c
>>
>> Log Message:
>>
On Sat, Feb 22, 2020 at 14:07:57 +, Kamil Rytarowski wrote:
> Module Name: src
> Committed By: kamil
> Date: Sat Feb 22 14:07:57 UTC 2020
>
> Modified Files:
> src/lib/libc/stdlib: _rand48.c
>
> Log Message:
> Avoid undefined behavior in the rand48(3) implementation
>
>
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
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
In article <20200104044017.c44aef...@cvs.netbsd.org>,
Kamil Rytarowski wrote:
>-=-=-=-=-=-
>
>Module Name: src
>Committed By: kamil
>Date: Sat Jan 4 04:40:17 UTC 2020
>
>Modified Files:
> src/lib/libc/sys: ptrace.2
>
>Log Message:
>/tmp/cvsbigmGa
You need to read the commit
On 04.01.2020 05:40, Kamil Rytarowski wrote:
> Module Name: src
> Committed By: kamil
> Date: Sat Jan 4 04:40:17 UTC 2020
>
> Modified Files:
> src/lib/libc/sys: ptrace.2
>
> Log Message:
> /tmp/cvsbigmGa
>
Document PT_LWPSTATUS and PT_LWPNEXT in ptrace(2)
Remove mentions of
>>> Joerg Sonnenberger wrote
>
> On Fri, Nov 22, 2019 at 08:53:25AM +0900, Takeshi Nakayama wrote:
> > >>> Takeshi Nakayama wrote
> >
> > > >>> Joerg Sonnenberger wrote
> > >
> > > > On Thu, Nov 21, 2019 at 11:06:16PM +, Takeshi Nakayama wrote:
> > > > > Module Name: src
> > > > >
1 - 100 of 463 matches
Mail list logo
