On Thursday, April 4, 2024 11:28:13 PM CEST Robert Elz wrote:
> Yes, in cases where temp files are actually needed, using mmap() is a
> very minor gain indeed - the buffering cost might be saved, but sorting
> a large file is a cpu costly endeavour (lots of comparisons, lots of times
> even with th
On Wednesday, November 15, 2023 3:20:45 PM CET Christos Zoulas wrote:
> On 2023-11-14 10:31 pm, Jörg Sonnenberger wrote:
> > On Wednesday, November 15, 2023 4:15:28 AM CET you wrote:
>
> > The functions are supposed to be transparent and they used to be. Can
> > we
> > please just go back to the
On Sunday, October 29, 2023 2:29:47 AM CET Mouse wrote:
> > I don't think any one else cares about pre-ustar. Pretty much any
> > reader and writer around uses at least ustar and generally wants to
> > have extended POSIX as well when caring about large files.
>
> So there _is_ a POSIX spec for t
On Sunday, October 29, 2023 12:40:06 AM CEST RVP wrote:
> On Sat, 28 Oct 2023, Mouse wrote:
> > I'm having trouble seeing what's responsible, and in particular am
> > wondering whether this is my bug or /bin/tar's bug or what. (It
> > doesn't help that I haven't managed to find a clear spec for ta
On Tue, Jul 04, 2023 at 12:31:33PM +, RVP wrote:
> On Tue, 4 Jul 2023, RVP wrote:
>
> > I think lld(1) does things differently. I'll check this later...
> >
>
> And I was right! On Linux (what I have at hand now):
>
> ```
> $ clang -fuse-ld=lld -Wl,-Map=map.txt -static -s -o foo foo.c -L. -
On Tue, Jul 04, 2023 at 08:38:22AM +, RVP wrote:
> b) the alloc functions in libc.a not being marked as being "weak".
This doesn't really matter at all, in fact, it is likely going to make
the situation *worse*. The linker errors happen because you are trying
to mix and match malloc implementa
On Sun, Jul 02, 2023 at 06:52:55PM -0400, Mouse wrote:
> > The CSU code has pretty much no idea on what the rest of the world is
> > going to do. It does: [...]
>
> > There is no way with ELF to decide at link time which of those
> > features are used by the program and therefore no way to remove
On Sun, Jul 02, 2023 at 05:04:10PM +0200, Martin Husemann wrote:
> The other things that we *might* look into (if someone volunteers) is to
> better modularize the CSU code, but it is not immediately clear how
> that could/should be done.
The CSU code has pretty much no idea on what the rest of th
On Sun, Jul 02, 2023 at 01:20:51AM +, Emmanuel Dreyfus wrote:
> On Sat, Jul 01, 2023 at 02:25:03PM +, RVP wrote:
> > Not to forget the code for C++ support. And, of course even static
> > binaries may call dlopen() and friends. So that dl*() and the ELF bits
> > right there.
>
> At least i
On Sun, Jun 04, 2023 at 07:20:05AM +1000, Luke Mewburn wrote:
> Does anything in-tree use libarchive's mtree implementation?
tar?
Joerg
Am Fri, Apr 28, 2023 at 11:25:03PM + schrieb RVP:
> On Fri, 28 Apr 2023, Paul Goyette wrote:
>
> > I propose the attached enhancement to chown/chgrp to avoid setting
> > a new user/group value if the desired values are already set. The
> > change is pretty simple.
> >
>
> I don't think we n
Am Mon, Apr 17, 2023 at 01:23:48AM + schrieb David Holland:
> Otherwise sooner or later you'll get bitten by a main() that expects
> the env argument.
I don't think I've *ever* seen that used.
Joerg
On Mon, Apr 17, 2023 at 12:55:13AM +, David Holland wrote:
> On Sat, Apr 15, 2023 at 11:47:08AM +0200, Roland Illig wrote:
> > Since C90, function prototypes are available. They have become so common
> > now that mentioning them is more confusing than helpful. I suggest
> > removing these tw
Am Wed, Apr 12, 2023 at 05:16:55AM -0700 schrieb Carlo Arenas:
> On Wed, Apr 12, 2023 at 5:07 AM Joerg Sonnenberger wrote:
> >
> > Am Wed, Apr 12, 2023 at 09:17:49AM - schrieb Michael van Elst:
> > > jo...@bec.de (Joerg Sonnenberger) writes:
> > >
> &
Am Wed, Apr 12, 2023 at 09:17:49AM - schrieb Michael van Elst:
> jo...@bec.de (Joerg Sonnenberger) writes:
>
> >Which compiler from this century doesn't allocate stack space
> >independent from the source order?
>
> gcc with -O0 and -O1 allocates variables in so
Am Wed, Apr 12, 2023 at 07:53:23AM +0930 schrieb Brett Lymn:
> On Tue, Apr 11, 2023 at 08:30:19PM +0200, Roland Illig wrote:
> >
> > The style guide says:
> > > When declaring variables in functions declare them sorted by size
> >
> > What is the purpose of this rule, and is it still useful? I'd
Am Fri, Oct 07, 2022 at 06:40:19AM -0400 schrieb Greg Troxel:
> autoconf has a macro AC_PROG_MKDIR_P that sets MKDIR_P. However it is
> all paranoid about races, wanting two simultaneous 'mkdir -p foo'
> invocations to result in foo being created and neither returning
> failure, because... speccu
Am Fri, Oct 07, 2022 at 06:40:19AM -0400 schrieb Greg Troxel:
> autoconf rejects NetBSD mkdir -p and thus there is some install-sh and
> that would have been ok but this somehow interacts with pgxs and blows
> up.
>
> So my real questions are:
>
> 1) Is NetBSD's mkdir -p safe, in that it is imm
Am Wed, Oct 05, 2022 at 12:06:10PM + schrieb nia:
> On Tue, Oct 04, 2022 at 12:21:08AM +0200, Joerg Sonnenberger wrote:
> > On Mon, Oct 03, 2022 at 12:31:42PM +, nia wrote:
> > > I'd argue that providing alloca(3) as anything except a compiler
> > > builtin
On Mon, Oct 03, 2022 at 12:31:42PM +, nia wrote:
> I'd argue that providing alloca(3) as anything except a compiler
> builtin is a bug, and that kind of thing should never be used.
Well, if you are in strict C/C++ standard mode, alloca should not exist
because it is not part of the standard. I
Am Wed, Aug 31, 2022 at 08:33:18PM +0700 schrieb Robert Elz:
> This is all, according to the application usage section, because of what
> the C standard is planning to do:
>
>The description of realloc( ) has been modified from previous versions
>of this standard to align with the ISO/IEC
Am Wed, Aug 31, 2022 at 05:36:56PM +0700 schrieb Robert Elz:
> The man page for reallocarray() says that reallocarr() was created
> to avoid the ambiguity with 0 sized allocations (which stems from
> realloc() in posix - because some realloc() implementations behaved
> differently than others).
So
On Sat, Aug 13, 2022 at 08:59:07PM +, nia wrote:
> A problem many new NetBSD users encounter is that a default shell
> without an initialized home directory containing a ~/.profile
> does not include some system PATH entries that would otherwise be
> provided from /etc/skel/.profile.
Garbage I
On Sat, Jul 02, 2022 at 12:02:49AM +0700, Robert Elz wrote:
> Date:Fri, 1 Jul 2022 17:46:06 +0200
> From:Edgar =?iso-8859-1?B?RnXf?=
> Message-ID:
>
> | What I don't understand is why it dumps core while reporting an error.
>
> Perhaps NetBSD 6 required an explici
Am Mon, May 23, 2022 at 01:15:36PM +0530 schrieb ga...@iitk.ac.in:
> Could you please give me a bit more context regarding the project and
> possibly a few links or documents that I can get started with? I look
> forward to hearing from you and work for NetBSD.
One possible (sub)project would be t
Am Tue, Apr 12, 2022 at 07:19:59AM +0700 schrieb Robert Elz:
> Can we please just stop wasting everyone's time with this?
I'm stopping my participation in this thread here, because it has become
completely pointless and frankly, depressing. NetBSD is not a museum,
even if it supports hardware that
Am Sun, Apr 10, 2022 at 09:30:19PM +0700 schrieb Robert Elz:
> Date:Sat, 9 Apr 2022 21:33:36 +0200
> From: Joerg Sonnenberger
> Message-ID:
>
> | wtf is this still being installed on most NetBSD systems?
>
> Can you demonstrate that Net
Am Sat, Apr 09, 2022 at 10:49:55PM +0700 schrieb Robert Elz:
> | Therefore I don't see any reason to keep it.
>
> And I have seen no reason to remove it. Not even a hint of one.
It is clearly meant as a hack to workaround limitations of an
architecture that went out of service a quarter decade
Am Thu, Feb 24, 2022 at 08:17:30AM -0500 schrieb Greg Troxel:
>
> Joerg Sonnenberger writes:
>
> > Am Thu, Feb 24, 2022 at 07:59:22AM -0500 schrieb Greg Troxel:
> >>
> >> I'm trying to build wip/ocaml on NetBSD 9 amd64 and came across:
> >>
Am Thu, Feb 24, 2022 at 07:59:22AM -0500 schrieb Greg Troxel:
>
> I'm trying to build wip/ocaml on NetBSD 9 amd64 and came across:
>
> gcc -c -O2 -fno-strict-aliasing -fwrapv -pthread -Wall
> -Wdeclaration-after-statement -Werror -fno-common -fexcess-precision=standard
> -fno-tree-vrp -fPIC
Am Tue, Feb 15, 2022 at 05:25:10PM -0800 schrieb Konrad Schroder:
> Of course the clearest use-case for crypt_r(3) is a password cracker: each
> thread sets up its own local memory and blasts through calls to crypt_r(3)
> as fast as it can. I've run a cracker as a white-hat. But I can see not
> w
Am Tue, Feb 15, 2022 at 08:04:29PM -0500 schrieb Mouse:
> > Given that the goal of the crypt(3) interface is to be slow,
> > optimizing a memory allocation away saves nothing, except making a
> > more complicated interface.
>
> I disagree. It saves a bunch of error paths. Many (most? all?) of th
Am Tue, Feb 15, 2022 at 03:58:30PM -0800 schrieb Jason Thorpe:
> There really should be a function that takes a user name or ID and a
> cleartext password string, and IPCs to another (trusted system) process
> to do the verification, so that programs that want to verify passwords
> don’t need root
Am Wed, Feb 16, 2022 at 12:04:16AM +0100 schrieb Niclas Rosenvik:
> do you mean that the interface should be
> crypt_r(const char *key, const char setting, char * storage, size_t
> *storage_len)
> where storage can be set to NULL to return the needed storage size in
> storage_len?
No. There are t
Am Sat, Feb 12, 2022 at 05:25:11PM +0100 schrieb Niclas Rosenvik:
> On Mon, 7 Feb 2022 16:12:17 +0100
> Thomas Klausner wrote:
>
> > Hi!
> >
> > I've been asked by the filezilla software developer if NetBSD will add
> > crypt_r() as a thread-safe crypt() replacement.
> >
> > Is anyone intereste
Am Mon, Feb 07, 2022 at 04:12:17PM +0100 schrieb Thomas Klausner:
> I've been asked by the filezilla software developer if NetBSD will add
> crypt_r() as a thread-safe crypt() replacement.
I don't exactly see the point. If I wanted to provide a more modern
interface, it would be for password verif
On Wed, Jan 19, 2022 at 11:15:50AM +0100, Hauke Fath wrote:
> On Tue, 18 Jan 2022 20:33:47 - (UTC), Christos Zoulas wrote:
> >>
> >> Since it is such a niche tool, I would add it to pkgsrc (but base doesn't
> >> hurt much either).
> >
> > I think that if FreeBSD has it in base, we should too
On Tue, Jan 18, 2022 at 08:33:47PM -, Christos Zoulas wrote:
> In article <20220117123329.ga19...@mail.duskware.de>,
> Martin Husemann wrote:
> >On Mon, Jan 17, 2022 at 12:28:51PM +0100, Manuel Bouyer wrote:
> >> Hello,
> >> so, to be able to run linux binaries with don't have the Linux type
On Thu, Jan 13, 2022 at 10:20:53AM +0900, PHO wrote:
> +/* The documentation for FUSE is not clear as to what "struct
> + * fuse_session" is, why it exists, or how it's different from "struct
> + * fuse". For now we define it as an empty struct and treat "struct
> + * fuse_session *" as being ident
On Mon, Nov 29, 2021 at 06:31:30PM +0100, Steffen Nurpmeso wrote:
> Joerg Sonnenberger wrote in
> :
> |On Mon, Nov 29, 2021 at 08:38:35PM +0700, Robert Elz wrote:
> |> DNS queries (via UDP) are limited to max 512, as that is what the
> |> protocol always required,
On Mon, Nov 29, 2021 at 08:38:35PM +0700, Robert Elz wrote:
> DNS queries (via UDP) are limited to max 512, as that is what the
> protocol always required, so can be handled by everything (or should be).
Strictly speaking, it is the minimum MTU every IPv4 implementation is
supposed to allow. IPv6
On Fri, Oct 29, 2021 at 01:10:24PM +0200, Edgar Fuß wrote:
> I just stumbled over the fact that NetBSD userland seems to be missing the
> fuser(1) command mandated by (the XSI extension of) POSIX.
> Is there any reason (other than "nobody cared") for that?
It's only been added in Issue 5, it's an
On Thu, Jun 03, 2021 at 11:57:50AM -0700, Jason Thorpe wrote:
>
> > On Jun 3, 2021, at 7:19 AM, Emmanuel Dreyfus wrote:
> >
> > Is there any reason not to fix it?
>
> Seems like it would be a bad idea NOT to fix it. I assume one of the goals
> of librefuse was to be ABI compatible?
It depend
On Wed, May 19, 2021 at 09:56:23AM +, nia wrote:
> The current situation in pkgsrc (where lots of software using alloca
> needs to be BUILDLINK_TRANSFORMED to use the -std=gnu... variant, or
> is patched to use the builtin directly) is not really one I'm happy
> with.
For most software it is e
On Thu, May 13, 2021 at 09:58:50PM +0200, Jaromír Doleček wrote:
> Le jeu. 13 mai 2021 à 21:44, Joerg Sonnenberger a écrit :
> > > No we don't, unless you are using PCC :D
> > >
> > > The block in only provides an alloca(3) prototype, and only
> > >
On Thu, May 13, 2021 at 12:51:45PM +0200, Jaromír Doleček wrote:
> Le jeu. 13 mai 2021 à 01:04, Joerg Sonnenberger a écrit :
> >
> > On Wed, May 12, 2021 at 08:32:20PM +0200, Jaromír Doleček wrote:
> > > Le mer. 12 mai 2021 à 13:50, Joerg Sonnenberger a écrit :
> &
On Wed, May 12, 2021 at 08:32:20PM +0200, Jaromír Doleček wrote:
> Le mer. 12 mai 2021 à 13:50, Joerg Sonnenberger a écrit :
> >
> > On Wed, May 12, 2021 at 08:38:39AM +0200, Jaromír Doleček wrote:
> > > would it be a bad thing to add a compatibility which would
>
On Wed, May 12, 2021 at 08:38:39AM +0200, Jaromír Doleček wrote:
> would it be a bad thing to add a compatibility which would
> use the builtin alloca() instead of the libc one when available?
>
> e.g. MySQL 8.0.* seems to rely on this.
We provide it in stdlib.h as long as a standard mode is not
On Wed, Mar 17, 2021 at 02:32:25PM +0100, Hauke Fath wrote:
> On Wed, 17 Mar 2021 00:55:03 +0100, Roland Illig wrote:
> > when I run lint with the -t flag for traditional C (which means before
> > C90), I always get these warnings:
> >
> > [...]
>
> > Any objections to removing the -t flag and ev
On Mon, Feb 15, 2021 at 12:15:28PM -0500, Mouse wrote:
> Back in the day, I added a pseudo-device that gave userland the ability
> to watch the autoconf device tree.
devpubd does that in-tree.
Joerg
On Thu, Jan 14, 2021 at 12:28:57PM +0100, Manuel Bouyer wrote:
> On Thu, Jan 14, 2021 at 12:19:39PM +0100, Martin Husemann wrote:
> > On Thu, Jan 14, 2021 at 12:14:28PM +0100, Manuel Bouyer wrote:
> > > Any comment about this ? I'm not familiar with these details ...
> >
> > man ctype and search f
On Wed, Dec 02, 2020 at 02:04:42AM +0700, Robert Elz wrote:
> A very old enhancement request for the posix specification of make
> (old as in submitted in 2011) is now under discussion ... the delay
> as being an enhancement, it couldn't be added in a "technical corrigenda"
> update, which is all t
On Tue, Nov 17, 2020 at 03:07:05PM -0500, Mouse wrote:
> >> But [...] __ssp_overlap succeeded to pinpoint the overlap with the
> >> buffer declared as an (fixed size) array but not when it was
> >> dynamically allocated.
> > Correct, the SSP primitives will only ever work for static buffers.
>
> B
On Tue, Nov 17, 2020 at 02:11:15PM +0100, tlaro...@polynum.com wrote:
> But the lesson was that the __ssp_overlap succeeded to pinpoint the
> overlap with the buffer declared as an (fixed size) array but not when
> it was dynamically allocated.
Correct, the SSP primitives will only ever work for s
On Sun, Oct 25, 2020 at 11:41:16AM -0400, Mouse wrote:
> >> Of course groff's even slower, but mandoc is faster -- than groff,
> >> at least, dunno about heritage nroff. Is there a noticeable delay
> >> with mandoc even on our slowest supported hardware? It might very
> >> well be fine.
> > Last
On Sat, Oct 24, 2020 at 08:35:47PM -0400, Thor Lancelot Simon wrote:
> Of course groff's even slower, but mandoc is faster -- than groff, at
> least, dunno about heritage nroff. Is there a noticeable delay with
> mandoc even on our slowest supported hardware? It might very well be
> fine.
Last t
On Sun, Aug 30, 2020 at 05:18:43PM +, m...@netbsd.org wrote:
> On Sun, Aug 30, 2020 at 06:09:47PM +0200, Joerg Sonnenberger wrote:
> > On Sun, Aug 30, 2020 at 12:00:33PM +, co...@sdf.org wrote:
> > > Move the big "if _NETBSD_SOURCE" chunk to the "Imple
On Sun, Aug 30, 2020 at 12:00:33PM +, co...@sdf.org wrote:
> Move the big "if _NETBSD_SOURCE" chunk to the "Implementation defined"
> section.
> Makes "at_quick_exit" and others visible for strict C/C++.
alloca is not part of POSIX.
Joerg
On Thu, Jul 16, 2020 at 08:28:29PM +0100, David Brownlee wrote:
> On Thu, 16 Jul 2020 at 15:40, Christos Zoulas wrote:
> >
> > In article <7171.1594774...@splode.eterna.com.au>,
> > matthew green wrote:
> > >Martin Husemann writes:
> > >>
On Mon, Jul 13, 2020 at 04:28:56PM -0700, Greg A. Woods wrote:
> At Tue, 14 Jul 2020 00:28:46 +0200, Joerg Sonnenberger wrote:
> Subject: Re: recent changes to pthread_fork.c:fork() cause static linking to
> fail if the app provides its own malloc()
> >
> > On Mon, Jul 1
On Mon, Jul 13, 2020 at 03:05:17PM -0700, Greg A. Woods wrote:
> I think it is the following change (and perhaps more similar/related
> changes) which breaks static linking of applications which wish to
> supply their own implementation of malloc(), and which call, e.g.,
> fork():
I consider it a
On Mon, Jul 13, 2020 at 09:18:18AM -0400, Ted Lemon wrote:
> On Jul 13, 2020, at 9:13 AM, Mouse wrote:
> > . I find the braces pure visual clutter in the latter.
>
> What really bugs me is when my code winds up with a security fail because I
> wasn’t careful.
If only we had compilers that coul
On Wed, Jun 03, 2020 at 05:22:39PM +, nia wrote:
> While trying to accurately replicate NetBSD's struct addrinfo for
> crystal[0], I noticed this pattern occurs twice in netdb.h...
>
> #if defined(__alpha__) || (defined(__i386__) && defined(_LP64))
> int __ai_pad0; /*
On Tue, May 26, 2020 at 06:50:32AM +0200, Martin Husemann wrote:
> On Tue, May 26, 2020 at 01:37:41AM +0200, Kamil Rytarowski wrote:
> > I agree here with Joerg.
> >
> > At this point it's good to just add a wrapper as in the proposed patch.
> > Once we will bump libc major, we can rename the sysc
On Thu, May 28, 2020 at 06:04:23PM -, Christos Zoulas wrote:
> In article <20200527141158.ga16...@bec.de>,
> Joerg Sonnenberger wrote:
> >- Forwarded message from Christos Zoulas -
> >
> >Date: Sun, 24 May 2020 15:26:41 -0400
> >From:
- Forwarded message from Christos Zoulas -
Date: Sun, 24 May 2020 15:26:41 -0400
From: Christos Zoulas
To: source-chan...@netbsd.org
Subject: CVS import: src/external/mit/libuv/dist
Reply-To: source-change...@netbsd.org
Module Name:src
Committed By: christos
Date: Sun Ma
On Mon, May 25, 2020 at 12:05:44PM +0200, Martin Husemann wrote:
> On Mon, May 25, 2020 at 03:09:09PM +0530, Apurva Nandan wrote:
> > I meant that I can't create a __weak_alias ppoll(2) to pollts(2) in libc as
> > pollts(2) has its definition in sys/sys. But yes the resulting weak alias
> > symbol
On Mon, May 25, 2020 at 10:06:22AM +0200, Martin Husemann wrote:
> On Mon, May 25, 2020 at 12:20:53PM +0530, Apurva Nandan wrote:
> > The problem with __weak_alias is that they only work inside the same C file
> > where the original symbol is defined, and don't work outside that file for
> > that s
On Thu, May 14, 2020 at 08:11:32PM +0300, Andreas Gustafsson wrote:
> Joerg Sonnenberger wrote:
> > On Thu, May 14, 2020 at 05:29:39PM +0300, Andreas Gustafsson wrote:
> > > Joerg Sonnenberger wrote:
> > > > > > > There's nothing wrong with the general
On Thu, May 14, 2020 at 05:29:39PM +0300, Andreas Gustafsson wrote:
> Joerg Sonnenberger wrote:
> > > > > There's nothing wrong with the general idea of entropy estimation as
> > > > > implemented in NetBSD-current. If you run -current on your
> > &g
On Thu, May 14, 2020 at 10:35:48AM +0300, Andreas Gustafsson wrote:
> Joerg Sonnenberger wrote:
> > > There's nothing wrong with the general idea of entropy estimation as
> > > implemented in NetBSD-current. If you run -current on your hypothetical
> > > emu
On Wed, May 13, 2020 at 12:19:06PM +0300, Andreas Gustafsson wrote:
> Joerg Sonnenberger wrote:
> > On Tue, May 12, 2020 at 04:59:52PM +0300, Andreas Gustafsson wrote:
> > > I don't particularly care if we require 100 or 384 bits of estimated
> > > entropy, n
On Tue, May 12, 2020 at 04:59:52PM +0300, Andreas Gustafsson wrote:
> I don't particularly care if we require 100 or 384 bits of estimated
> entropy, nor do I particularly care if the entropy estimate of a
> keystroke timestamp is 0 or 1 bit. But I do very much care that if I
> accidentally try to
On Mon, May 11, 2020 at 05:58:21PM +0300, Andreas Gustafsson wrote:
> Joerg Sonnenberger wrote:
> > > For the OpenBSD strategy to work, the system needs to actually refuse
> > > to run if the seed can't be loaded (or full entropy achieved in some
> > > other way)
On Mon, May 11, 2020 at 11:38:28AM +0200, Kamil Rytarowski wrote:
> On 11.05.2020 01:49, Joerg Sonnenberger wrote:
> > On Mon, May 11, 2020 at 01:11:32AM +0200, Kamil Rytarowski wrote:
> >> On 10.05.2020 18:38, Kamil Rytarowski wrote:
> >>> LLDB will be patched
On Mon, May 11, 2020 at 04:28:51PM +0300, Andreas Gustafsson wrote:
> nia wrote:
> > > OpenBSD guarantees that there is an entropy seed from the boot loader,
> > > which is very different from NetBSD's "best effort". Was this not
> > > already the case when the getentropy API was introduced?
> >
On Mon, May 11, 2020 at 01:11:32AM +0200, Kamil Rytarowski wrote:
> On 10.05.2020 18:38, Kamil Rytarowski wrote:
> > LLDB will be patched to avoid atomics.
> I have checked LLDB and std::atomic is used on purpose and was
> switched from mutexes 3 years ago.
>
> https://github.com/llvm/llvm-projec
On Sun, May 10, 2020 at 10:03:27PM +0200, Jaromír Doleček wrote:
> Le dim. 10 mai 2020 à 20:25, Joerg Sonnenberger a écrit :
> > I find it funny that you pick an example where correctly working
> > atomic implementation is essential and where the only reason it is
> > pull
On Sun, May 10, 2020 at 06:16:49PM +0200, Kamil Rytarowski wrote:
> On 08.05.2020 21:33, m...@netbsd.org wrote:
> > On Fri, May 08, 2020 at 04:09:02PM +0200, Kamil Rytarowski wrote:
> >> I object to opinions that libatomic is generally broken, if that would
> >> be the cause, it wouldn't be availab
On Sun, May 10, 2020 at 02:24:00PM +0300, Andreas Gustafsson wrote:
> The getentropy() man pages on OpenBSD, FreeBSD, and Linux all say it
> returns "high-quality" entropy, and do not caution against using it
> for security critical purposes such as key generation, so presumably
> applications do i
On Sat, May 09, 2020 at 03:25:25PM +, nia wrote:
> On Sat, May 09, 2020 at 01:13:44PM +, nia wrote:
> > Right, yes, the CPUID stuff wasn't being defined when builing EVP which
> > meant the dumb asm implementation was being used instead of HW/VP/BSAES.
> >
> > That's fixed now. Everything
On Fri, May 08, 2020 at 02:44:14PM +0200, Martin Husemann wrote:
> On Fri, May 08, 2020 at 02:26:45PM +0200, Kamil Rytarowski wrote:
> > With _Atomic() we can mark any arbitrary struct to have serialized
> > accesses. As I said, with your attitude we shall remove FPU support (and
> > softfloat) as
On Thu, May 07, 2020 at 10:49:39PM +, m...@netbsd.org wrote:
> I am under the impression that (at least GCC) compilers will not emit
> intrinsic calls if they are guaranteed to be available on the target.
This is true, but only a minor complication compared to the rest.
Joerg
On Thu, May 07, 2020 at 11:09:03PM +0200, Kamil Rytarowski wrote:
> > (1) They introduce non-trivial blocking conditions, often defeating the
> > reason for using atomics in first place.
> > (2) They don't work in a constrained environment and are broken by
> > common UNIX primitives like memory ma
On Thu, May 07, 2020 at 10:13:30PM +0200, Kamil Rytarowski wrote:
> On 07.05.2020 21:45, Joerg Sonnenberger wrote:
> > On Thu, May 07, 2020 at 05:43:02AM +0200, Kamil Rytarowski wrote:
> >> Lack of libatomic is increasingly hard to deal with. This library
> >> implement
On Thu, May 07, 2020 at 05:43:02AM +0200, Kamil Rytarowski wrote:
> Lack of libatomic is increasingly hard to deal with. This library
> implements function calls for atomic operations.
I'm sure you have done the research on why the existing arguments
against providing libatomic are wrong. For some
On Wed, May 06, 2020 at 10:03:54PM +0700, Robert Elz wrote:
> | We have a summer of code project that can cover this part.
>
> Thanks for the info, which project is that, and who is mentoring it,
> if you know? (I am woefully ignorant of everything related to GSoC).
See https://summerofcode.w
On Wed, May 06, 2020 at 02:31:32PM +0200, Martin Husemann wrote:
> On Wed, May 06, 2020 at 02:29:07PM +0200, Joerg Sonnenberger wrote:
> > I'm not sure. There is normally no way to force an empty environment
> > variable, so if you want to not use PATH, the behavior of the curr
On Wed, May 06, 2020 at 02:29:07PM +0200, Joerg Sonnenberger wrote:
> On Wed, May 06, 2020 at 10:43:05AM +0200, Martin Husemann wrote:
> > On Wed, May 06, 2020 at 02:33:41PM +0700, Robert Elz wrote:
> > > Either of those is fine with POSIX - but we should really have one
On Wed, May 06, 2020 at 02:33:41PM +0700, Robert Elz wrote:
> Aside: I started looking because POSIX is adding a "chdir" file action
> to posix_spawn and posix_spawnp - and the path search (for relative paths)
> done by posix_spawnp is to be applied after the effects of the chdir, which
> would mea
On Wed, May 06, 2020 at 10:43:05AM +0200, Martin Husemann wrote:
> On Wed, May 06, 2020 at 02:33:41PM +0700, Robert Elz wrote:
> > Either of those is fine with POSIX - but we should really have one
> > consistent
> > policy. Changing either the manual or the code to match the other is also
> > e
On Fri, May 01, 2020 at 07:19:09PM +, Taylor R Campbell wrote:
> I propose that we additionally adopt getrandom and getentropy, two C
> APIs the world is converging on. For getentropy, this can be a simple
> userland wrapper in libc; for getrandom, this requires a new path into
> the kernel, a
On Mon, Mar 09, 2020 at 08:28:58PM +0100, Michał Górny wrote:
> To be honest, this is NetBSD-specific problem. Upstream has a fallback
> for other platforms but it was explicitly disabled on NetBSD (Kamil or
> Joerg will probably know why).
No, it is not a NetBSD-specific problem. Guys, please st
On Mon, Mar 09, 2020 at 08:05:41PM +0100, Martin Husemann wrote:
> On Mon, Mar 09, 2020 at 02:49:23PM -0400, Greg Troxel wrote:
> > I am not really following the issue, but I don't understand why what the
> > default C++ sublanguage is matters. It would seem that behavior should
> > be correct for
On Mon, Mar 09, 2020 at 01:16:58PM +0100, Kamil Rytarowski wrote:
> Upstream libc++ maintainers are against patching libc++.
I'm buffled how you are arriving at this conclusion. Let me reiterate:
STOP MESSING UP THE TREE.
Joerg
On Wed, Feb 26, 2020 at 02:00:08PM +0100, Michał Górny wrote:
> While we're already touching this, I wonder if we should extend it to
> cover alignment for AVX types. In particular __m512i requires 512-bit
> alignment while our max_align_t currently has 128-bit alignment
> on amd64.
We do not gua
On Wed, Feb 26, 2020 at 12:37:06PM +0100, Kamil Rytarowski wrote:
> I propose to expose max_align_t unconditionally to C and C++ namespaces.
>
> It was introduced in C11/C++11, but in practice it is used in C++ code
> that formally builds in the C++03/older mode (llvm libc++ expects it
> unconditi
On Fri, Jan 31, 2020 at 01:07:21PM +0700, Robert Elz wrote:
> | I'm not sure what filesystem attributes you want to apply to /
> | that don't also apply to /usr just as well.
>
> Aside from readonly, which you comment on below (and I will return to
> there) there's also the block'frag sizes, n
On Thu, Jan 30, 2020 at 11:50:47AM -0500, Greg Troxel wrote:
> Piotr Meyer writes:
>
> > On Wed, Jan 29, 2020 at 09:32:30PM +, Alexander Nasonov wrote:
> > [...]
> >
> >> I like it when fsck doesn't take ages to check /. With bigger /,
> >> it's going to be problematic.
> >
> > IMVHO moving /
On Thu, Jan 30, 2020 at 09:29:52AM +0700, Robert Elz wrote:
> Date:Wed, 29 Jan 2020 19:33:56 - (UTC)
> From:chris...@astron.com (Christos Zoulas)
> Message-ID:
>
> | Having a split /usr makes little sense today though as joerg mentioned,
> | even in the space-
1 - 100 of 219 matches
Mail list logo
