Re: new tool: nbupgrade(8)

On Fri, May 03, 2024 at 22:25:38 +, nia wrote: > Here is an updated version based on the feedback received so far - > thanks for the attention and fixes. In post_install explicitly calling "postinstall check" is redundant. It's the last thing etcupdate does automatically. -uwe

Re: mkcsmapper.1 manpage and NOMAN

On Fri, May 03, 2024 at 22:56:50 +, Jeremy C. Reed wrote: > manpage was added to source in > > revision 1.1 > date: 2016-06-27 20:07:26 +; author: maya; state: Exp; commitid: > 6ZGENVNUdTQBU8cz; > Add man page for mkcsmapper. > Imported from FreeBSD. > > And it has updates since

Re: new tool: nbupgrade(8)

On Thu, May 02, 2024 at 06:52:13 +, nia wrote: > hey, I wrote this script to replace sysupgrade (but maintainable and > not using a weird shell library), would be nice to import it. Just a quick drive-by question: [how] can one use it for self-compiled sets? -uwe

Re: CVS commit: src/tests/lib/libc/gen

On Sat, Apr 13, 2024 at 14:02:51 +, Roland Illig wrote: > Module Name: src > Committed By: rillig > Date: Sat Apr 13 14:02:51 UTC 2024 > > Modified Files: > src/tests/lib/libc/gen: t_fmtcheck.c > > Log Message: > tests/fmtcheck: show that fmtcheck does not support "%2$s"

Re: Lua binding for curses

On Mon, Aug 07, 2023 at 23:04:17 +, Charlotte Koch wrote: > I didn't realize that prior art actually mattered... > > I say this because our SQLite bindings in src/lib/lua/sqlite were > homegrown, despite the fact that official Lua-SQLite bindings > have always existed upstream: > >

Re: Lua binding for curses

On Mon, Aug 07, 2023 at 07:52:10 +0930, Brett Lymn wrote: > > It would be nice to be able to use the same lua binding with both our > > curses and ncurses. I have a simple screen grabber based on a > > rumpified wsvt25 that I wrote to test and debug the kernel terminal > > emulator(*) and it

Re: Lua binding for curses

On Sat, Aug 05, 2023 at 20:46:58 +, Charlotte Koch wrote: > I've been (slowly) working on a Lua binding for NetBSD curses, with the > intention of adding it to src alongside our other Lua libs (sqlite, > gpio, etc.) > > https://github.com/dressupgeekout/netbsd-lua-curses > > I finally have

old style tail(1) options and bin/57483

bin/57483 reports that tail(1) doesn't correctly handle old style options in all cases. The current approach taken by tail is to massage the command line to convert old style options into the new style options and then use getopt to parse only the new style. Unfortunately the code that does the

mtree(8) vs mtree(5)

We have mtree(8) man page for our mtree that documents the format of the mtree spec. We also have an mtree(5) page that documents the format of the mtree spec, but that pages comes from libarchive. This is kinda confusing. What is the relationship between the two? (libarchive borrowed bsd code?

mailx (Re: CVS commit: src/usr.bin/tip)

On Tue, Apr 25, 2023 at 01:48:37 +, David H. Gutteridge wrote: > Module Name: src > Committed By: gutteridge > Date: Tue Apr 25 01:48:37 UTC 2023 > > Modified Files: > src/usr.bin/tip: tip.1 > > Log Message: > tip.1: s/Mail.1/mail.1/ ("Mail" was removed in 9) We still

Re: style: clean up mentions of old-style C

On Sat, Apr 15, 2023 at 19:48:04 +0700, Robert Elz wrote: > So, what I think this is saying, in about the most obscure way possible, > is that the '{' for a function block goes on a line by itself, after > the function name & arg list, This is how I read it too. -uwe

Re: Rationale for some rules in style guide

On Wed, Apr 12, 2023 at 07:53:23 +0930, Brett Lymn wrote: > > > then in alphabetical order > > > > Why does it make sense to sort variables in the order 'bottom, left, > > right, top' instead of the natural pronunciation order 'top, left, > > bottom, right', for example? Or 'height, width, x, y'

Re: style(5) proposal: forbid extern in .c

On Wed, Mar 15, 2023 at 11:23:05 +, Taylor R Campbell wrote: > Proposal: Forbid extern declarations in .c files. > > extern declarations in .c files invite easily avoided bugs where the > definition and use have mismatched types, because the compiler doesn't > have an opportunity to check

mail(1) editline defaults to vi mode?

I had to use mail(1) recently (after ~30 years break :). To my surp^Wconfusion its editline inits itself to vi mode. I think no program should ever init editline to vi mode, unless specifically instructed too. :) PS: I had EDITOR=emacsclient on that system. But even EDITOR=vi is not an excuse

Re: split(1): add '-c' to continue creating files

On Tue, Feb 14, 2023 at 17:31:36 +0100, Martin Husemann wrote: > On Sun, Feb 12, 2023 at 04:05:20PM -0500, Jan Schaumann wrote: > > The attached diff adds a flag "-c" (mnemonic "create, > > don't overwrite" or "continue where you left off"): > > > > $ split file; ls > > xaa xab xac xad > > $

Re: strftime(3) oddities with %s, %z

On Tue, Nov 01, 2022 at 05:20:17 +0700, Robert Elz wrote: > How are you proposing that a portable implementation of strftime() > done today, before the next posix standard is released (maybe next > year, but perhaps not until 2024) would achieve what you're requesting? I think this is the point

Re: strftime(3) oddities with %s, %z

On Tue, Oct 25, 2022 at 23:07:56 +0700, Robert Elz wrote: > The standard is going to (as it should) say what works now, and what > applications and users can expect. In this case it is that > strftime("%s") gives the same thing as printf("%ld", mktime()) > when applied to the same tm. [...] >

Re: strftime(3) oddities with %s, %z

On Tue, Oct 25, 2022 at 14:56:23 +0700, Robert Elz wrote: > Date:Tue, 25 Oct 2022 04:08:13 +0300 > From: Valery Ushakov > Message-ID: > > | strftime(3) %s format is not in ISO C or POSIX, though the rumor is > | that it will be in the

Re: strftime(3) oddities with %s, %z

On Tue, Oct 25, 2022 at 04:08:13 +0300, Valery Ushakov wrote: > musl seems to do the right thing. Its mktime obeys the "expressed as > local time" requirement and ignores tz-related state in tm, but %s > gets you the original time_t back from the > > time_t -&g

strftime(3) oddities with %s, %z

strftime(3) %s format is not in ISO C or POSIX, though the rumor is that it will be in the next POSIX version. Our man page and Solaris man page both just say it's the number of seconds since the Epoch. glibc says (ubuntu 22.04): The number of seconds since the Epoch, 1970-01-01 00:00:00

Re: mkdir -p, autoconf

On Sat, Oct 08, 2022 at 02:45:39 +, David Holland wrote: > On Fri, Oct 07, 2022 at 02:31:28PM -0400, Greg Troxel wrote: > > The point is not that they exist, but that the program is robust against > > something else creating them. Given autoconf macros have concerns about > > parallel

Re: alloca again

On Wed, Oct 05, 2022 at 12:06:10 +, nia wrote: > 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 is a bug, and that kind of thing

Re: alloca again

On Mon, Oct 03, 2022 at 18:32:47 +, David Holland wrote: > On Mon, Oct 03, 2022 at 03:45:06PM +0200, Roland Illig wrote: > > > This is the current alloca definition in the libc headers: > > > > > > #if defined(_NETBSD_SOURCE) > > > #if defined(alloca) && (alloca == __builtin_alloca) && \

Re: clang man pages

On Wed, Sep 14, 2022 at 20:59:06 +0300, niko.nasto...@icloud.com wrote: > Not sure if this is the correct list, but here it is. > > When I install clang with pkgin, the package does not install man pages. > Is this expected behaviour? > I am running 9.3_STABLE on arm64. It's a package, so it's

Re: Permissions of the root dot files

[the bsd.link.mk part diverted to tech-toolchain] On Tue, Aug 30, 2022 at 02:27:34 +0300, Valery Ushakov wrote: > Is there any particular reason why /root/.profile and /root/.cshrc > (that have hard links in / too, for the single user mode i guess) are > not writable? So apparently

Re: Permissions of the root dot files

On Tue, Aug 30, 2022 at 08:38:02 +0700, Robert Elz wrote: > Date:Tue, 30 Aug 2022 02:27:33 +0300 > From: Valery Ushakov > Message-ID: > > | Is there any particular reason why /root/.profile and /root/.cshrc > | (that have hard links in / too, f

Permissions of the root dot files

Is there any particular reason why /root/.profile and /root/.cshrc (that have hard links in / too, for the single user mode i guess) are not writable? -uwe

Re: sh(1) and ksh(1) default PATH

On Sun, Aug 14, 2022 at 09:13:23 +0700, Robert Elz wrote: > The normal default path for sh comes from sysctl user.cs_path As you do the caretaking of our sh(1), please, can you drop a small note in syspath() as to why it uses sysctl() directly instead of confstr(). (I'm not sure I can properly

Re: Libc support for old BSD-style "sigcontext" signal handlers is broken, let's just kill it.

On Tue, Oct 26, 2021 at 06:56:54 -0700, Jason Thorpe wrote: > However, as I was adding an #ifdef conditional to the sigcontext > handling in the new unified __sigaction14_sigtramp.c (because new > architectures added after ?siginfo? support was added never really > needed it, and didn?t define a

Re: Summary of man-page formatting

On Sat, Mar 13, 2021 at 10:39:08 +0100, Anders Magnusson wrote: > Den 2021-03-13 kl. 10:03, skrev Valery Ushakov: > > On Fri, Mar 12, 2021 at 10:54:46 +0100, Reinoud Zandijk wrote: > > > > > Well, there is lout to consider. > > [...] > > > I've nev

Re: Summary of man-page formatting

On Fri, Mar 12, 2021 at 10:54:46 +0100, Reinoud Zandijk wrote: > Well, there is lout to consider. [...] > I've never used it for manpage rendering though! A simple `awk' > script could indeed do it as its format is quite easy. Uwe has > experience with it :) Right, and in my experience it would

Re: text layout in sysinst

On Sun, Feb 07, 2021 at 14:26:47 +0100, Roland Illig wrote: > On 07.02.2021 05:25, Valery Ushakov wrote: > > What's wrong is that for addstr we call _cursesi_addwchar with a > > pointer to a dummy variable, but for addch we call it with a pointer > > to win->curx, so we f

Re: text layout in sysinst

On Sat, Feb 06, 2021 at 20:58:49 +0100, Roland Illig wrote: > On 05.02.2021 21:12, Roland Illig wrote: > > > when I run sysinst from a boot CD, after pressing Enter 3 times in a > > row, I get the screen "You have chosen". This screen presents a menu. > > The items of the menu are indented with

Re: Convention in the output of service rcvar

Rocky Hotas wrote: > On dic 17 21:12, David Holland wrote: > >> My guess: someone was thinking in perl by accident and nobody's >> noticed it since, so it hasn't been fixed. > > It's probable, then. Thanks for your feedback, David and Jeremy. > > I would suggest, if possible and if you agree,

Re: Convention in the output of service rcvar

Valery Ushakov wrote: > David Holland wrote: > >> On Wed, Dec 16, 2020 at 07:43:20PM +0100, Rocky Hotas wrote: >> > # food >> > $food=YES >> >: >> > >> > Is there any reason for that? What do you think? >> >> My gu

Re: Convention in the output of service rcvar

David Holland wrote: > On Wed, Dec 16, 2020 at 07:43:20PM +0100, Rocky Hotas wrote: > > # food > > $food=YES > >: > > > > Is there any reason for that? What do you think? > > My guess: someone was thinking in perl by accident and nobody's > noticed it since, so it hasn't been fixed.

Re: Summary of man-page formatting

On Sun, Nov 15, 2020 at 03:10:08 +0100, Kamil Rytarowski wrote: > 10. I've suggested a MANWIDTH patch, which looked fine for upstream, but > it is not guaranteed to land upstream at all or in that form. > > http://netbsd.org/~kamil/patch-00287-mandoc-MANWIDTH.txt mandoc may support MANWIDTH as

Re: Proposal to remove catman(8)

On Wed, Nov 11, 2020 at 18:00:02 +0300, Valery Ushakov wrote: > - change a line in man.conf to obey MANWIDTH/COLUMNS: > > _build .[1-9ln] /usr/bin/mandoc ${COLUMNS+-Owidth=${MANWIDTH:-$COLUMNS}} > %s > And just for the record, the nroff equivalent for setting the width with

Re: Proposal to remove catman(8)

On Wed, Nov 11, 2020 at 14:42:04 +0100, 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 r

Re: Proposal to remove catman(8)

On Tue, Nov 10, 2020 at 23:31:12 +0100, Kamil Rytarowski wrote: > On 10.11.2020 23:04, Robert Elz wrote: > > Date:Tue, 10 Nov 2020 19:28:41 +0100 > > From:Kamil Rytarowski > > Message-ID: > > So you just confirmed to have a lot of opinions and just started to >

Re: Proposal to remove catman(8)

On Mon, Nov 09, 2020 at 21:12:10 +0100, Tobias Nygren wrote: > mandoc is used for everything that is in pkgsrc. For example: > $ mandoc /usr/pkg/man/man1/bash.1 | more > > If you want to make the argument that it cannot render certain > third-party manual pages in way that makes the content

Complete removal of support for cat-pages (Was: catman)

On Mon, Nov 09, 2020 at 09:56:33 +0100, 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

Re: catman (Was: CVS commit: src/games/fortune/datfiles)

On Mon, Nov 09, 2020 at 01:18:25 +0100, Kamil Rytarowski wrote: > 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 > (SV

Re: catman (Was: CVS commit: src/games/fortune/datfiles)

On Mon, Nov 09, 2020 at 01:05:02 +0100, Thomas Klausner wrote: > On Mon, Nov 09, 2020 at 12:46:42AM +0300, Valeriy E. Ushakov wrote: > > Also, come to think of it... Removing catman (i.e. user's ability to > > generate cat pages) is rather different from removing MKCATPAGES, > > what's going on

Re: catman (Was: CVS commit: src/games/fortune/datfiles)

On Sun, Nov 08, 2020 at 22:58:11 +0100, Kamil Rytarowski wrote: > On 08.11.2020 22:46, Valery Ushakov wrote: > > On Sun, Nov 08, 2020 at 17:37:30 +, Kamil Rytarowski wrote: > > > >> Module Name: src > >> Committed By: kamil > >> Date:

catman (Was: CVS commit: src/games/fortune/datfiles)

On Sun, Nov 08, 2020 at 17:37:30 +, Kamil Rytarowski wrote: > Module Name: src > Committed By: kamil > Date: Sun Nov 8 17:37:30 UTC 2020 > > Modified Files: > src/games/fortune/datfiles: fortunes > > Log Message: > catman(8) is a past thing Please, revert this. It's

Re: Proposal to import window(1) into the base

Christos Zoulas wrote: > In article , > Valery Ushakov wrote: >>Alistair Crooks wrote: >> >>> If it comes back, it needs to be modified to use curses - the hardcoded >>> terminal escapes for a bunch of 1970s terminals is kinda cute in a retro >>>

Re: Proposal to import window(1) into the base

Alistair Crooks wrote: > If it comes back, it needs to be modified to use curses - the hardcoded > terminal escapes for a bunch of 1970s terminals is kinda cute in a retro > way; it's also kinda embarassing. >From a very quick look half of window sources (tt* and ww* files) are its homebrew

Re: style change: explicitly permit braces for single statements

Luke Mewburn wrote: > I propose that the NetBSD C style guide in to /usr/share/misc/style > is reworded to more explicitly permit braces around single statements, > instead of the current discourgement. > > IMHO, permitting braces to be consistently used: > - Adds to clarity of intent. > - Aids

Re: Weekday abbreviations in output of cal(1)

Valery Ushakov wrote: > Wolfgang Solfrank wrote: > >>> "first $WEEKDAY of next month". I am at a loss how to do this with >>> NetBSD's date(1). >> >> Thanks for the explanation. >> >> Ok, let's try with a double invocation: >>

Re: Weekday abbreviations in output of cal(1)

Michael Siegel wrote: > So, in the output of NetBSD's cal(1), days are abbreviated with one > letter, except for Tuesday and Thursday. > > I'd say this is: > > * inconsistent > * potentially misleading (Saturday and Sunday are both just "S".) > * unnecessarily cryptic [...] > So, I'd say

Re: cgrep for basesystem?

Simon Burge 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. >> >> If someone would be interested to pick this project it would be

Re: Add curses_version() in curses(3)

[copying here my reply from source-changes-d] On Fri, Aug 30, 2019 at 18:22:37 +0100, 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 "NetBSD-"

Re: stdio.h's P_tmpdir definition - make it /tmp?

Greg Troxel wrote: > It seems that long long ago, /tmp was small and on /, and /var was often > bigger, and people used /var/tmp for larger stuff. Also I remember a > notion of clearing /tmp on boot and not clearing /var/tmp. Now, /tmp > is a tmpfs and large/fast, and the right place for

Re: EV_SET() better C++ compat with alternative implementations

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? Anything wrong with the templated solution for c++11 I posted a few days ago, keeping the original state

Re: EV_SET() better C++ compat with alternative implementations

On Wed, Aug 14, 2019 at 06:06:18 +0300, Valery Ushakov wrote: > static inline void > EV_SET_(struct kevent *_kevp, uintptr_t _ident, uint32_t _filter, > uint32_t _flags, uint32_t _fflags, int64_t _data, > uintptr_t _udata) > { > _kevp->ident = _ident;

Re: EV_SET() better C++ compat with alternative implementations

On Sun, Aug 11, 2019 at 03:57:50 +0200, Kamil Rytarowski wrote: > On 11.08.2019 02:56, Valery Ushakov wrote: > > Kamil Rytarowski wrote: > > > >> Cast of udata from void* to intptr_t shall be done with > >> reinterpret_cast<> otherwise a

Re: EV_SET() better C++ compat with alternative implementations

On Mon, Aug 12, 2019 at 03:43:56 +, m...@netbsd.org wrote: > So, this is when we changed to intptr_t. We also went through a > "int64_t udata" revision at some point, later. > > Module Name:syssrc > Committed By: jdolecek > Date: Wed Oct 2 19:09:37 UTC 2002 > > Modified

Re: EV_SET() better C++ compat with alternative implementations

Kamil Rytarowski wrote: > Cast of udata from void* to intptr_t shall be done with > reinterpret_cast<> otherwise a C++ compiler errors. > > Defining __REINTERPRET_CAST [1] and using it, did not work as a compiler > protested for NULL argument "warning: passing NULL to non-pointer argument". >

Re: find and limits

co...@sdf.org wrote: > I understand the need for correctness, but the limits for find ... -exec > are really low, and it's quite unclear why things fail when they do. What limits? Limits inside find(1)? Global limit on the maximum length of a command line? > cd

Re: Detecting keypress on console

On Thu, Mar 28, 2019 at 13:54:21 +, Emmanuel Dreyfus wrote: > On Sat, Mar 23, 2019 at 02:23:19PM -0000, Valery Ushakov wrote: > > Alternatively you should also be able re-inject wsevents you are not > > interested in back into the wsmux (instead of doing that at tty(4) &

Re: namespace pollution by curses

On Tue, Mar 12, 2019 at 15:21:49 -, Christos Zoulas wrote: > In article <20190312134722.ga1...@netbsd.org>, > David Holland wrote: > >On Tue, Mar 12, 2019 at 01:25:13PM +0300, Valery Ushakov wrote: > > > Admittedly, I'm not sure about the usage. E.g. in wsco

Re: colorls in base

Christian Groessler wrote: > On 2/15/19 10:28 PM, m...@netbsd.org wrote: >> On Fri, Feb 15, 2019 at 10:17:55PM +0100, Christian Groessler wrote: >>> On 2/15/19 8:15 PM, m...@netbsd.org wrote: For the record I support the change. I don't think it's very hard not to turn on colors. You

Re: colorls in base

Kamil Rytarowski wrote: > On 16.02.2019 03:03, Christian Groessler wrote: >> On 2/16/19 2:35 AM, Kamil Rytarowski wrote: >>> On 16.02.2019 02:14, m...@netbsd.org wrote: There's a topic on peace-keeping in a large project. There are two types of feedback: - "this change

Re: Definitions of types also as macros

On Tue, Nov 06, 2018 at 23:20:16 +0100, Rhialto wrote: > On Tue 06 Nov 2018 at 23:19:08 +0300, Valery Ushakov wrote: > > Also your change breaks redefining intN_t types with the preprocessor. > > E.g. > > > > #define uint32_t unsigned long long > >

Re: Definitions of types also as macros

[I missed this thread, so I'm reposting my reply that I originally sent to source-changes-d] On Tue, Nov 06, 2018 at 16:38:06 +, co...@sdf.org wrote: > On Tue, Nov 06, 2018 at 08:11:03AM -0800, John Nemeth wrote: > > On Nov 6, 3:07pm, co...@sdf.org wrote: > > } > > } I wanna do this, looks

Re: Help needed with understanding of config(1) debug output

On Thu, Sep 27, 2018 at 16:20:50 +0800, Paul Goyette wrote: > I've got a problem where something I've changed over the last six months > (or more) on the [pgoyette-compat] branch has broken the release build > for at least ``build.sh -m algor'' port. For some unknown reason it is > defining

Re: Weirdness in /bin/sh of 8.0

Izaac wrote: > On Thu, Jul 13, 2017 at 09:01:26AM -0400, Izaac wrote: >> On Thu, Jul 13, 2017 at 07:46:39AM +0700, Robert Elz wrote: >> > So, opinions? >> >> Stop. >> >> Leave /bin/sh alone. > > And here we are. If you want SCO Unix you know where to find it. -uwe

Re: Auxiliary header and macros for sanitizers in userland programs

On Tue, Jun 05, 2018 at 22:04:37 +0200, Kamil Rytarowski wrote: > On 05.06.2018 20:47, Valery Ushakov wrote: > > Kamil Rytarowski wrote: > > > >> On 05.06.2018 18:14, Valery Ushakov wrote: > >>> Kamil Rytarowski wrote: > >>> > >>&g

Re: Auxiliary header and macros for sanitizers in userland programs

Kamil Rytarowski wrote: > On 05.06.2018 18:14, Valery Ushakov wrote: >> Kamil Rytarowski wrote: >> >>> We've faced a problem with sanitizing part of the NetBSD userland, as we >>> need to use helper functions to make sanitization possible in some &

Re: Auxiliary header and macros for sanitizers in userland programs

Kamil Rytarowski wrote: > We've faced a problem with sanitizing part of the NetBSD userland, as we > need to use helper functions to make sanitization possible in some > narrow cases that aren't clear for sanitizers. > > The current problem is the usage of callback functions defined in >

Re: _UC_MACHINE_BP

Kamil Rytarowski wrote: > I propose to add a definition of _UC_MACHINE_BP() across the ports in > /usr/include/*/mcontext.h. > > BP stands for Base Pointer / Frame Pointer. Please, s/BP/FP/. "Frame pointer" is an esablished name and several assemblers use "fp" as a register

Re: Add static local vars to sh(1) ?

On Mon, Jan 29, 2018 at 23:33:25 +0700, Robert Elz wrote: > From: u...@stderr.spb.ru (Valery Ushakov) > Subject: Re: Add static local vars to sh(1) ? > Date: Mon, 29 Jan 2018 13:38:25 + (UTC) > > | This doesn't seem to mention what happens when the > |

Re: Fwd: Re: fmtcheck() query

Christos Zoulas wrote: > | Yes, I'm so sorry for this breakage of file(1). It clearly indicates > | possible risks of changing the behavior of fmtcheck(3). > > Thank you very much. I think that adding a new function is preferrable > in this case because we are adding

Re: Fwd: Re: fmtcheck() query

Rin Okuyama <rokuy...@rk.phys.keio.ac.jp> wrote: > On 2017/12/10 2:04, Valery Ushakov wrote: >> My version currently complains about unused arguments, but there's an >> XXX comment about that. For the numbered case the relevant passage >> is: >> >>

Re: Basesystem programs redefine routine symbols from libc

Kamil Rytarowski wrote: > The problem is not on the header files (preprocessor), but on the linker > level. > > We are linking prebuilt .a / .so files with a target application. > > $ nm > /usr/local/lib/clang/6.0.0/lib/netbsd/libclang_rt.msan-x86_64.a|grep uname >

Re: Fwd: Re: fmtcheck() query

On Sat, Dec 09, 2017 at 09:43:56 +0900, Rin Okuyama wrote: > We are discussing how fmtcheck(3) should be. Previously, it allows > format strings consuming less arguments than the default one, as long > as consumed args are of correct types. Recently, I've changed it to > reject such a string as

Re: Fwd: Re: fmtcheck() query

On Sat, Dec 09, 2017 at 09:43:56 +0900, Rin Okuyama wrote: > christos suggests that you wrote another version of fmtcheck(3) which > recognizes positional arguments. Did you? Oh, apparently I did. Then, iirc, I discovered we already have fmtcheck(), so the exercise became kinda pointless. I

Re: getaddrinfo(3) on numerical addresses

In gmane.os.netbsd.devel.network Joerg Sonnenberger wrote: > On Tue, Oct 24, 2017 at 03:19:29PM +0200, Edgar Fu? wrote: >> I've noticed[*] that on NetBSD, getaddrinfo(3) does a resolver lookup even >> if presented a numerical address. Is this on purpose? Would it have a >>

Re: GNU shellery

co...@sdf.org wrote: > reversing lines currently: > BSDs: tail -r > GNU: tac > > Anyone writing portable code: sed '1!G;h;$!d' > (Yes that actually works) > > Attached diff adds a hard link tac (need set lists adjusted though, and > I have a man page). it doesn't add any of the GNU tac options.

Re: pthreads vs. overriden malloc

On Wed, Sep 13, 2017 at 15:58:11 +0200, Joerg Sonnenberger wrote: > On Wed, Sep 13, 2017 at 04:48:54PM +0300, Valery Ushakov wrote: > > On a typical cpu that would be the alignment of "long double" I guess. > > (I haven't checked, but it looks like that's what TINY_MIN_2

Re: pthreads vs. overridden malloc

On Wed, Sep 13, 2017 at 02:23:22 +0300, Valery Ushakov wrote: > The two approaches I can think of are to use posix_memalign+memset > instead of calloc and to use calloc and manually re-align the result. > > So either > > newthread = calloc(1, __pthread_st

Re: kdump -E for time elapsed since the beginning of trace

On Thu, Sep 07, 2017 at 05:18:11 +0300, Valery Ushakov wrote: > I'd like to add kdump -E option to print timestamps as time elapsed > since the beginning of trace. I have committed a different set of changes to the same effect. I dropped support for v0 (NetBSD 3) and v1 (NetBSD 5) traces.

Re: kdump -E for time elapsed since the beginning of trace

On Thu, Sep 07, 2017 at 05:18:11 +0300, Valery Ushakov wrote: > I'd like to add kdump -E option to print timestamps as time elapsed > since the beginning of trace. PS: You may notice on some platforms that the second entry (execve) has 1) negative time, 2) incorrect negative time. $ ktrac

kdump -E for time elapsed since the beginning of trace

I'd like to add kdump -E option to print timestamps as time elapsed since the beginning of trace. The option name is from FreeBSD. While here, the patch makes it possible to use a combination of -T -E and -R options to print timestamps in several formats. The idea is also from FreeBSD. Trivial

Re: curses: Home key sends 0x162 in tmux

Carsten Kunze wrote: > TERMCAP=SC|screen|VT 100/ANSI X3.64 virtual terminal:\ [...] > This is from tmux(1), the same (kh=\E[1~:@1=\E[1~) is set by > screen(1). So who sets this? (TERMCAP is not set, when screen(1) > or tmux(1) are not started.) screen exports TERMCAP