On 11.07.2021 08:50, Martin Husemann wrote:
> On Sun, Jul 11, 2021 at 12:47:53AM -0400, Mouse wrote:
>> I'm not sure to what extent use of uninitialized memory is considered a
>> bug when, as here, the code is correct regardless of what value it
>> contains.
>
> It is a bug (and should be
On 16.01.2021 14:29, Taylor R Campbell wrote:
>> Date: Sat, 16 Jan 2021 13:21:21 +0100
>> From: Kamil Rytarowski
>>
>> On 11.01.2021 02:25, Taylor R Campbell wrote:
>>> Many of you have no doubt noticed that a lot more things hang waiting
>>> for entropy
On 11.01.2021 02:25, Taylor R Campbell wrote:
> Many of you have no doubt noticed that a lot more things hang waiting
> for entropy than used to on machines without hardware random number
> generators (even as we've added a bunch of new drivers for HWRNGs) --
> e.g., python, firefox.
Can we
I propose to drop .me from man.conf(5):
http://netbsd.org/~kamil/patch-00288-drop-me-from-man.conf.txt
There is no evidence that it has any users and unclear whether there
were ever any.
It removed a direct usage of nroff (groff) from man.conf(5).
signature.asc
Description: OpenPGP digital
Hello,
I apologize for nerves and words that could be avoided.
I'm going to summarize the situation with formatters in the NetBSD base.
1. NetBSD base ships with two programs that can format manual pages from
base and most 3rd party software: BSD mandoc (newest) and GPLv2 groff
1.19.2 (old,
On 11.11.2020 14:42, Kamil Rytarowski wrote:
> On 11.11.2020 06:33, Valery Ushakov wrote:
>> Kamil, you keep confusing mechanism and policy.
>
> I note that some people still missed that after marking the MKCATPAGES
> files obsolete, every NetBSD/z80 users relying on catman(8)
On 11.11.2020 06:33, Valery Ushakov wrote:
> Kamil, you keep confusing mechanism and policy.
I note that some people still missed that after marking the MKCATPAGES
files obsolete, every NetBSD/z80 users relying on catman(8) (thus even
FUZIX/z80 uses dynamic man-pages formatting!) will wipe cat
On 11.11.2020 01:18, Greg Troxel wrote:
>
> Kamil Rytarowski writes:
>
>> I wish good luck finding user-base/target-audience (if you like, in any
>> age) that relies on the slowest of slow hardware and cannot use anything
>> else to study the system documentation.
>
On 11.11.2020 00:16, Greg Troxel wrote:
>
> Kamil Rytarowski writes:
>
>> I am surprised that the proposal to remove MK${FOO} is read as removal
>> of the Makefile conditionals and keep ${FOO} in the base. With that
>> bizarre interpretation the whole proposal renders
On 10.11.2020 23:04, Robert Elz wrote:
> Date:Tue, 10 Nov 2020 19:28:41 +0100
> From: Kamil Rytarowski
> Message-ID:
>
> | I hope this is a typo, and not the indication that you forgot how to use
> | the cat-pages at all and miss a computer
On 10.11.2020 12:59, Robert Elz wrote:
> Date:Tue, 10 Nov 2020 11:14:12 +0100
> From: Kamil Rytarowski
> Message-ID:
>
> | If you still can find any man-page that is unsupported by mandoc, please
> | let me know and I will report it.
On 10.11.2020 10:30, Robert Elz wrote:
> Date:Tue, 10 Nov 2020 00:05:32 +0100
> From: Kamil Rytarowski
> Message-ID:
>
> | Do you use it? Do you know anybody who uses it on NetBSD-current?
>
> I might start. Particularly for the pages tha
On 10.11.2020 01:18, Mouse wrote:
>>> [...]
>> It's not a selling point to any regular user, born after A.D. 2000 to
>> optimize reading man pages.
>
> (a) So what? Neither, I daresay, is, oh, say, fpr, which is still
> present in 9.1
>
We might want to see fortran back. I have got no
On 10.11.2020 01:05, Paul Goyette wrote:
> On Tue, 10 Nov 2020, Kamil Rytarowski wrote:
>
>
>>
>> It's not a selling point to any regular user, born after A.D. 2000 to
>> optimize reading man pages.
>
> Whoa there. Don't put down us older folks. And why
On 09.11.2020 21:46, Robert Elz wrote:
> Date:Mon, 9 Nov 2020 19:05:23 +0100
> From: Kamil Rytarowski
> Message-ID: <04c9e1ad-df4e-1372-74d3-a17fdd5dd...@netbsd.org>
>
> | I propose to remove catman(8).
>
> Don't.
Do you use it? D
I propose to remove catman(8).
The removal of all cat-man remnants was already implied during the
proposal of drop MKCATPAGES, but it apparently was not clear enough.
Rationale:
- cat pages are not generated by default since 2012 and almost nobody
(except me?) used them in the past few years.
On 09.11.2020 09:56, Thomas Klausner wrote:
> On Mon, Nov 09, 2020 at 04:55:14AM +0300, Valeriy E. Ushakov wrote:
>> Hold your horses! This started with MKCATPAGES which is ability to
>> pre-generate cat pages as part of the build.
>>
>> Now it's suddenly about eliminatiing support for cat pages
On 08.11.2020 23:20, Valery Ushakov wrote:
> It's (partially) past-tensed, which looks stupid and cripples the
> joke.
catman has zero to do with current UNIX or any other standard I checked
(SVID, XPG, POSIX, XNS, SUS, ISO, ANSI). It was a historical utility.
I've changed it to be relatively
On 08.11.2020 22:46, Valery Ushakov wrote:
> On Sun, Nov 08, 2020 at 17:37:30 +0000, Kamil Rytarowski wrote:
>
>> Module Name: src
>> Committed By:kamil
>> Date:Sun Nov 8 17:37:30 UTC 2020
>>
>> Modified Files:
>> src/
On 25.10.2020 02:35, Thor Lancelot Simon wrote:
> On Sun, Oct 25, 2020 at 02:13:47AM +0200, Kamil Rytarowski wrote:
>>
>> I recall catpages to used in 80286 UNIX (Coherent) and the catpages are
>> probably just applicable for such constrained environments that cannot
>&g
I propose to drop the support for MKCATPAGES=yes. catpages are
preformatted .txt files that happen to contain manual pages and are
cat(1)able.
Over the past more than 5 years, I was the only person reporting any
fallout and fixing the regressions in the MKCATPAGES=yes build failures.
I'm going
I propose to import window(1) into the base.
tmux is a similar program to tmux, but much simpler and traditional in
the BSD environment. Personally I use tmux as a screen replacement for
detached consoles, but for management of windows I prefer window(1).
window(1) does one thing and does it
On 14.09.2020 10:49, Edgar Fuß wrote:
> Is there a way to make a process dump core on exit no matter what?
> I have a deamon dying (or whatever) from time to time with no trace to the
> cause and guess a backtrace from a dump would help.
>
Start under a debugger, break on 'exit'.
On 09.09.2020 10:57, Paul Ripke wrote:
> TL;DR: Our dirfd(3) is a macro, boost expects a function. POSIX
> appears to require a function but allow an additional macro.
> FreeBSD, OpenBSD & Linux all provide functions. Perhaps we should,
> too?
>
> Additional details are in my msg to tech-pkg@:
>
On 23.05.2020 02:38, Kamil Rytarowski wrote:
> On 01.05.2020 21:19, Taylor R Campbell wrote:
>> I propose that we additionally adopt getrandom and getentropy, two C
>> APIs the world is converging on.
>
> I propose to import the getrandom code with the Linux sema
On 14.07.2020 06:28, Martin Husemann wrote:
> On Tue, Jul 14, 2020 at 02:49:00AM +0200, Joerg Sonnenberger wrote:
>> Replacing malloc is just as invalid from a strict standard compliance
>> perspective, so *shrug*
>
> Why is that?
>
> We have e.g. shells/standalone-tcsh that does it. Is it
On 05.06.2020 01:44, Simon Burge wrote:
> Kamil Rytarowski wrote:
>
>> I find this program useful, however it should be refreshed or rewritten
>> for modern times. Its switches and usage is not compatible with modern
>> grep(1) and the implementation is pretty simplistic
I've discovered and ported cgrep from Coherent to NetBSD.
https://github.com/krytarowski/cgrep
It's a grep-like program for discovering C identifiers.
$ ./cgrep usage /usr/src/bin/ls/*.c
/usr/src/bin/ls/ls.c: usage(void)
/usr/src/bin/ls/ls.c: usage();
$ ./cgrep x
.txt
http://netbsd.org/~kamil/patch-00264-ppoll-0005-Rename-pollts-to-ppoll.patch.txt
Is this OK to merge?
On 01.06.2020 18:26, Kamil Rytarowski wrote:
> On 01.06.2020 18:20, Kamil Rytarowski wrote:
>> On 01.06.2020 18:03, Joerg Sonnenberger wrote:
>>> On Tue, May 26, 2020 at 06:50:32AM
On 01.06.2020 18:20, Kamil Rytarowski wrote:
> On 01.06.2020 18:03, Joerg Sonnenberger wrote:
>> 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.
>
On 01.06.2020 18:03, Joerg Sonnenberger wrote:
> 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 ad
Hello,
I'm sharing the current status of UBSan reports under MKLIBCSANITIZER.
http://netbsd.org/~kamil/mksanitizer-reports/MKLIBCSANITIZER-UBSan-2020-05-31.txt
LLVM + GCC
I've filtered out libc++ and src/lib/libc/compat/../locale/multibyte.h
ones that are worked on (by Joerg).
We are down to
I will hold on, as Joerg wants to look into it.
On 29.05.2020 15:35, Kamil Rytarowski wrote:
> I've double checked that multibyte.h is not leaked into other DSOs other
> than libc (especially citrus ones). Everything is safe.
>
> I'm landing this now.
>
> On 13.05.2020 18:55
I've double checked that multibyte.h is not leaked into other DSOs other
than libc (especially citrus ones). Everything is safe.
I'm landing this now.
On 13.05.2020 18:55, Kamil Rytarowski wrote:
> I propose the following patch to remove attribute setting maximum target
> specific ali
There was an announcement that bind will be not updated.
Topic "bind -> unbound/nsd "
"Hello,
The recent change of ISC/bind licensing from BSD to MPL for the
next release has provided us with an opportunity to re-evaluate
the preferred daemon status for NetBSD and DNS resolution. Board/Core
On 25.05.2020 13:15, Joerg Sonnenberger wrote:
> 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
On 25.05.2020 06:06, Martin Husemann wrote:
> On Mon, May 25, 2020 at 04:32:14AM +0530, Apurva Nandan wrote:
>> Hi all,
>> I have added ppoll(2) implementation to libc/sys, which is a wrapper around
>> pollts(2) function (basically, pollts(2) and ppoll(2) are aliases, and
>> NetBSD has pollts(2)).
On 13.05.2020 19:07, Kamil Rytarowski wrote:
> I propose to pass -fno-delete-null-pointer-checks to Clang under
> MKSANITIZER/MKLIBCSANITIZER.
>
> http://netbsd.org/~kamil/patch-00251-rump-fno-delete-null-pointer-checks.txt
>
> This disabled alerts from Clang and permits to
On 23.05.2020 02:38, Kamil Rytarowski wrote:
> On 01.05.2020 21:19, Taylor R Campbell wrote:
>> I propose that we additionally adopt getrandom and getentropy, two C
>> APIs the world is converging on.
>
> I propose to import the getrandom code with the Linux sema
On 13.05.2020 19:07, Kamil Rytarowski wrote:
> I propose to pass -fno-delete-null-pointer-checks to Clang under
> MKSANITIZER/MKLIBCSANITIZER.
>
> http://netbsd.org/~kamil/patch-00251-rump-fno-delete-null-pointer-checks.txt
>
> This disabled alerts from Clang and permits to
On 01.05.2020 21:19, Taylor R Campbell wrote:
> I propose that we additionally adopt getrandom and getentropy
I propose to import the getrandom code with the Linux semantics and
integrate into compat_linux(8). More and more software expects that in
place.
For the native (NetBSD) ABI,
I propose the following patch to remove attribute setting maximum target
specific alignment:
http://netbsd.org/~kamil/patch-00252-avoid-maximum-alignment.txt
mbstate_t has 64-bit alignment, __attribute__ ((aligned)) sets 128-bit
alignment and this leads to a lot of reports of UBSan on
I propose to pass -fno-delete-null-pointer-checks to Clang under
MKSANITIZER/MKLIBCSANITIZER.
http://netbsd.org/~kamil/patch-00251-rump-fno-delete-null-pointer-checks.txt
This disabled alerts from Clang and permits to run sanitized rump.
Meanwhile as far as I am aware, the C committee was
On 11.05.2020 16:19, Joerg Sonnenberger wrote:
> 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
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 to avoid atomics.
>> I have checked LLDB and std::atomic is used on purpose and was
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-project/commit/f9d16476573e16856bdb3250c817b0a2c631d2b1
Revert
On 10.05.2020 20:25, Joerg Sonnenberger wrote:
> 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
On 09.05.2020 18:51, Christos Zoulas wrote:
> I am with Martin here. This belongs in pkgsrc and not in base. There is
> an overhead using libatomic and we should not be penalizing everyone.
> There are very few cases where applications should be using raw atomics,
> and in these situations the
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 available and used on relatively all
>> relevant gene
On 08.05.2020 14:44, 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 th
On 08.05.2020 14:12, Joerg Sonnenberger wrote:
> 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 wor
On 08.05.2020 00:49, 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 means libatomic needs to:
>
> - Optimize: we can runtime detect, which emitted code cannot do.
>
>
On 07.05.2020 22:45, Joerg Sonnenberger wrote:
> 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 libatomi
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
>> implements function calls for atomic operations.
>
> I'm sure you have done the researc
On 07.05.2020 05:56, Martin Husemann wrote:
> On Thu, May 07, 2020 at 05:43:02AM +0200, Kamil Rytarowski wrote:
>> I propose the following patch:
>>
>> http://netbsd.org/~kamil/patch-00250-libatomic.txt
>
> +__inline static int
> +__futex(volatile uint32_t *uaddr,
Lack of libatomic is increasingly hard to deal with. This library
implements function calls for atomic operations.
Personally I stopped testing sanitizers year ago as they required
libatomic. We want libatomic for LLDB in base. Rewritting everything to
stop using libatomic is no viable as this is
ollute the namespace and we try to adhere with the standards. Exposing
> "max_align_t" where we should not goes against our principles.
>
> christos
>
>> On Mar 10, 2020, at 7:54 AM, Kamil Rytarowski wrote:
>>
>> Signed PGP part
>> _t is a reserved name
rward seems to
> be:
>
> 1. sed -i -e s/max_align_t/__max_align_t/g *.h
> 2. edit the file where the typedef is defined and expose "max_align_t" if you
> are
> compiling the library or if >= c++11
>
> I don't see what all the fuss is about.
>
> christos
&g
On 09.03.2020 18:09, Joerg Sonnenberger wrote:
> 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.
On 10.03.2020 00:07, Greg Troxel wrote:
> Kamil Rytarowski writes:
>
>> On 09.03.2020 20:05, Martin Husemann wrote:
>>> This is pretty stupid, but IMHO no big deal. We can
>>>
>> [...]
>>> - just not support (i.e. #error) on older C++ standard
On 09.03.2020 20:05, Martin Husemann wrote:
> This is pretty stupid, but IMHO no big deal. We can
>
[...]
> - just not support (i.e. #error) on older C++ standard compiles
There are still many programs in pkgsrc that set older C++ release. Some
of them are hard to upgrade.
$ git grep c++03|wc
On 26.02.2020 23:47, Kamil Rytarowski wrote:
> On 26.02.2020 14:49, Joerg Sonnenberger wrote:
>> 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 intr
On 26.02.2020 14:49, Joerg Sonnenberger wrote:
> 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
&g
On 26.02.2020 14:00, Michał Górny wrote:
> On Wed, 2020-02-26 at 12:37 +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 formall
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
unconditionally).
http://netbsd.org/~kamil/patch-00237-max_align_t.txt
Instead of
I propose to separate the pthread_atfork(3) call from pthread_tsd_init()
and move it into a distinct function.
I propose to call late TSD initialization after "pthread_atfork(NULL,
NULL, pthread__fork_callback);" from pthread__init().
This change:
1. Stops initializing jemalloc prematurely and
On 07.02.2020 23:13, Christos Zoulas wrote:
> In article
> ,
> Santhosh Raju wrote:
>> -=-=-=-=-=-
>>
>> Hello
>>
>> While working with kamil@ on MKLIBCSANITIZER based build, I came
>> across a compile error in pam_krb5.c
>>
>> --- dependall-pam_krb5 ---
>>
IOn 30.01.2020 08:27, tlaro...@polynum.com wrote:
> On Wed, Jan 29, 2020 at 10:47:51PM +0100, Kamil Rytarowski wrote:
>> On 29.01.2020 22:32, Alexander Nasonov wrote:
>>> Thor Lancelot Simon wrote:
>>>> On Wed, Jan 29, 2020 at 11:33:22AM +0100, Joerg Sonnenberger wro
On 29.01.2020 22:32, Alexander Nasonov wrote:
> Thor Lancelot Simon wrote:
>> On Wed, Jan 29, 2020 at 11:33:22AM +0100, Joerg Sonnenberger wrote:
>>> On Tue, Jan 28, 2020 at 09:21:23PM +, Roy Marples wrote:
To fix this, I suggest that we split syslogd into syslogd and
I propose to import realpath(1) from FreeBSD.
It is a small program with less than 100 LOC.
https://github.com/freebsd/freebsd/tree/master/bin/realpath
The FreeBSD version works as-is (after patching __FBSDID and __dead2).
realpath(1) is a part of coreutils on Linux and sometimes programs use
On 30.12.2019 19:23, Christos Zoulas wrote:
> Hello,
>
> As promised, I've submitted two pull requests for upstream libarchive.
> I submitted the second one just today because I was waiting for almost
> a month to hear feedback for the first one, and now I've given up waiting.
>
> Here they are:
On 25.12.2019 02:57, Joerg Sonnenberger wrote:
> On Wed, Dec 25, 2019 at 02:47:45AM +0100, Kamil Rytarowski wrote:
>> On 25.12.2019 02:45, Kamil Rytarowski wrote:
>>> 1. or1k + riscv define both __lwp_getprivate_fast() and __lwp_gettcb_fast().
>>>
>>> Is ther
1. or1k + riscv define both __lwp_getprivate_fast() and __lwp_gettcb_fast().
Is there a point? Unless it is some ABI nit, it looks like a bug to me?
2. Harmonize namespacing __lwp_getprivate_fast() and __lwp_gettcb_fast().
This is known issue to me abd it bites me from time to time, working for
On 25.12.2019 02:45, Kamil Rytarowski wrote:
> 1. or1k + riscv define both __lwp_getprivate_fast() and __lwp_gettcb_fast().
>
> Is there a point? Unless it is some ABI nit, it looks like a bug to me?
>
> 2. Harmonize namespacing __lwp_getprivate_fast() and __lwp_gettcb_fast().
>
On 24.11.2019 08:56, Alexander Kuleshov wrote:
> I sorry for noise, but wrong artifact hit to the first one patch,
> here is the update:
>
strtoi(3) is easier here than strtol(3).
>
> diff --git a/usr.sbin/usbdevs/usbdevs.c b/usr.sbin/usbdevs/usbdevs.c
> index e8fe1e7e6f4..526c1eade38 100644
>
On 22.09.2019 18:22, Christos Zoulas wrote:
> On Sep 22, 5:58pm, n...@gmx.com (Kamil Rytarowski) wrote:
> -- Subject: Re: wedge device to name
>
> | I understand and I know. Unfortunately (or fortunately) we will need to
> | live with the old syscall forever.
>
> Yes, but
you get to kill the old
> versions if you want, with
> sysctl you are left with the mess.
>
> christos
>
>> On Sep 22, 2019, at 11:42 AM, Kamil Rytarowski > <mailto:n...@gmx.com>> wrote:
>>
>> ,
>
I understand and I know. Unfortunately (or
On 02.09.2019 15:11, Valery Ushakov wrote:
> On Mon, Sep 02, 2019 at 12:32:51 +0300, Valery Ushakov wrote:
>
>> Why would we ever want to report this completely random and unrelated
>> fact?!
>>
>> There were years when curses in the tree was unchanged. In the mean
>> time we have churned
On 30.08.2019 19:22, Roy Marples wrote:
> On 30/08/2019 18:09, Kamil Rytarowski wrote:
>> On 30.08.2019 18:55, Roy Marples wrote:
>>> return "NetBSD-Curses " CURSES_VERSION
>>
>>
>> I propose to go for:
>>
>> return "
On 30.08.2019 18:55, Roy Marples wrote:
> return "NetBSD-Curses " CURSES_VERSION
I propose to go for:
return "NetBSD-" CURSES_VERSION " Curses";
With removed __DATE__ that is not MKREPRO friendly.
The rest looks fine.
signature.asc
Description: OpenPGP digital signature
On 29.08.2019 15:23, Roy Marples wrote:
> On 29/08/2019 14:19, Kamil Rytarowski wrote:
>> In my opinion artificial versioning (1.0.0) of native code adds no
>> interesting information and adds burden on us for superfluous versioning
>> model, orthogonal to __NetBSD_Version_
On 29.08.2019 13:55, Roy Marples wrote:
> On 29/08/2019 03:45, Thor Lancelot Simon wrote:
>> On Wed, Aug 28, 2019 at 10:42:13PM -0400, Thor Lancelot Simon wrote:
>>> On Wed, Aug 28, 2019 at 01:54:54AM +0100, Roy Marples wrote:
>>>
>>> Where 8.2 is taken from the .so version?
>>>
On 28.08.2019 21:58, Joerg Sonnenberger wrote:
> On Wed, Aug 28, 2019 at 08:59:32PM +0200, Kamil Rytarowski wrote:
>> On 28.08.2019 14:50, Joerg Sonnenberger wrote:
>>> On Wed, Aug 28, 2019 at 11:00:55AM +0930, Brett Lymn wrote:
>>>> I agree with Roy here, if we a
On 28.08.2019 14:50, Joerg Sonnenberger wrote:
> On Wed, Aug 28, 2019 at 11:00:55AM +0930, Brett Lymn wrote:
>> I agree with Roy here, if we add the call we should spit out the
>> version of the curses lib.
>
> The ELF version has no meaning though. If anything, keep a date of the
> last visible
On 27.08.2019 19:29, Roy Marples wrote:
> Using Blymns correct email :)
>
> On 27/08/2019 18:28, Roy Marples wrote:
>> On 27/08/2019 17:24, Kamil Rytarowski wrote:
>>> Last year, I wrote this patch to add curses_version() for curses(3).
>>>
>>> h
Last year, I wrote this patch to add curses_version() for curses(3).
http://netbsd.org/~kamil/patch-00073-curses-version.txt
The only purpose of this function is to get better compat with ncurses
software.
I needed it originally in qemu. It's sometimes used in the wild.
Is it fine to merge it
On 25.08.2019 18:10, Joerg Sonnenberger wrote:
> On Sun, Aug 25, 2019 at 04:59:41PM +0100, Roy Marples wrote:
>> On 25/08/2019 16:48, Joerg Sonnenberger wrote:
>>> On Sun, Aug 25, 2019 at 04:43:51PM +0100, Roy Marples wrote:
On 25/08/2019 15:39, Joerg Sonnenberger wrote:
> There is no
On 25.08.2019 17:38, Joerg Sonnenberger wrote:
> On Sun, Aug 25, 2019 at 05:12:26PM +0200, Kamil Rytarowski wrote:
>> I want to see the original state of void* so all casts will be unneded.
>
> But it doesn't. Casts are *still* necesseary when using integer indices
> as data
On 25.08.2019 16:39, Joerg Sonnenberger wrote:
> On Sun, Aug 18, 2019 at 08:58:15PM -, Valery Ushakov wrote:
>> Joerg Sonnenberger wrote:
>>
>>> On Sun, Aug 18, 2019 at 05:05:33PM +0200, Kamil Rytarowski wrote:
>>>> Ping? Can we switch from intptr_t t
On 18.08.2019 17:21, Joerg Sonnenberger wrote:
> On Sun, Aug 18, 2019 at 05:05:33PM +0200, Kamil Rytarowski wrote:
>> Ping? Can we switch from intptr_t to void*?
>
> Can we just go back to the original state?
>
> Joerg
>
Which original? intptr_t and caller level casts f
Ping? Can we switch from intptr_t to void*?
I declare to fix fallout for it.
signature.asc
Description: OpenPGP digital signature
On 13.08.2019 21:21, Joerg Sonnenberger wrote:
> On Tue, Aug 13, 2019 at 08:44:04PM +0200, Kamil Rytarowski wrote:
>> void* does not prevent storing inside it numbers.
>
> While not necessarily relevant in the NetBSD context, this is generally
> false. Casting random values
On 13.08.2019 20:22, Jaromir Dolecek wrote:
> I think the rationale was to make it possible to use for integer values and
> operations without cast. And make it clear it can hold arbitrary value, not
> necessarily pointer. Unfortunately intptr_t has different size in 32 vs 64
> bit same as void
A number of the remaining reported ptrace(2) bugs are GDB related. The
previous support for GDB in NetBSD was in need for refreshment, as it
had no support for gdbserver capabilities. The GDB Server is an
execution mode of the debugger, which spawns a dedicated process that
interacts with its
On 12.08.2019 05:56, Christos Zoulas wrote:
>
>> The original problem is udata of intptr_t insted of void* (like in
>> FreeBSD) and with C++ compilers it's not possible to cast it cleanly to
>> intptr_t without alternative approaches.
>>
>> This keeps breaking C++ users and we need to patch 3rd
On 11.08.2019 19:19, Kamil Rytarowski wrote:
> On 11.08.2019 19:17, Christos Zoulas wrote:
>> Did you use -Wold-style-cast? We've come full circle now, and what we have
>> seems
>> to be more complicated than what we had before and I am not sure what was the
>> proble
On 11.08.2019 19:22, Christos Zoulas wrote:
> Ok, with what version of event.h, the template specialization?
> I don't see how it is possible to not warn for (cast)foo
>
> christos
>
This is for:
http://netbsd.org/~kamil/patch-00138-EV_SET-CPP-cast.txt
No templates.
signature.asc
On 11.08.2019 19:17, Christos Zoulas wrote:
> Did you use -Wold-style-cast? We've come full circle now, and what we have
> seems
> to be more complicated than what we had before and I am not sure what was the
> problem in the first place... Can we just step back and understand what is
> the
On 11.08.2019 19:08, Christos Zoulas wrote:
> Now you get warnings with -Wold-style-cast (which is the reason for __CAST()
> in the first place).
>
> christos
>
For: http://netbsd.org/~kamil/patch-00138-EV_SET-CPP-cast.txt ?
I don't see any related warnings with any C++ -pedantic -Wall
On 11.08.2019 17:21, Kamil Rytarowski wrote:
> On 11.08.2019 14:34, Christos Zoulas wrote:
>> In article <3ebcc5d1-a57d-a290-72d8-6efc73025...@gmx.com>,
>> Kamil Rytarowski wrote:
>>> -=-=-=-=-=-
>>> -=-=-=-=-=-
>>>
>>> On 11.08.2019
1 - 100 of 245 matches
Mail list logo
