Re: Issues with lseek(2) on a block device
On Sat, Feb 24, 2024 at 04:28:28PM -0500, Thor Lancelot Simon wrote: > > Hello, thanks to everyone who responded with their suggestions. Using > > various non-portable ioctls I can device size on most platforms, for > > both block and raw devices. > > > > This is more convoluted than a single lseek() call, but it is what it > > is. If anyone wants to do something similar, then the following example > > can give you a good start. > > Probably not a good idea to start with lseek() because if you _do_ > encounter a tape device, seeking to SEEK_END could take you an extremely > long time. Also there at least used to be tapes where if you spun them all the way to the end you'd unthread the tape onto the take-up spindle and have to take it out and fix it. -- David A. Holland dholl...@netbsd.org
Re: Issues with lseek(2) on a block device
On Thu, Feb 22, 2024 at 08:13:28AM -0500, Mouse wrote: > I wouldn't call it buggy, not unless there is a spec that it's supposed > to conform to that says otherwise (even if the "spec" is just an > author's description of intent), which is something I so far haven't > seen reason to think exists. It looks to me like "we didn't bother > making it do anything in particular, so you get whatever it happens to > give you". "bug" ultimately means "failure to conform to expectations". We could debate what expectations might be for stat and block device sizes, but it is definitely against expectations that something so simple as retrieving the size of a storage device has such a messy interface. > My own method of finding disk device size is to lseek to offset N and > try to read one sector, for various N: initially N = sector size, then > double N until I get EOF-or-error, then do binary search between the > last working value and the first failing value. I think that's worked > on everything I've tried it on; admittedly, that's only a few OSes, but > I'd expect it to be highly portable. The only cases I'd expect it to > fail in are disks over 4G (or perhaps 2G) on systems with only 32 bits > for off_t. ...or tapes. -- David A. Holland dholl...@netbsd.org
Re: Issues with lseek(2) on a block device
On Wed, Feb 21, 2024 at 09:20:55PM +, Taylor R Campbell wrote: > But it's a little annoying to make that happen because it requires > going through all the file systems that have device nodes and > convincing their VOP_GETATTR implementations to do something different > for block devices (and ideally also character devices, if they > represent fixed-size media too). If I ever find time to follow through on my threat to reorganize the way device vnodes work, that will get rid of this problem :-) (and provide everyone a pony, too) (if anyone's curious, not sure I've posted about it before, the idea is to flip things so that the device logic sits on top of the fs-level special file vnode; currently it's the other way around, so the fs gets involved with all kinds of things it doesn't actually need to care about) -- David A. Holland dholl...@netbsd.org
Re: system(3) semantics when SIGCHLD is SIG_IGN'd
On Sat, Aug 12, 2023 at 11:58:36AM +, Taylor R Campbell wrote: > What should system(3) do when the signal action for SIGCHLD is > SIG_IGN, or has SA_NOCLDWAIT set? > [...] My suggestion would be invent a new working mechanism for disowning children and banish the mess to COMPAT_POSIX_MISTAKE. I had never noticed this specific additional behavior that prohibits wait(2) from operating properly; that makes the feature broken instead of just messy and ugly. -- David A. Holland dholl...@netbsd.org
Re: printf(1), sh(1), POSIX.2 and octal escape sequences
On Fri, Jun 30, 2023 at 05:51:13PM +0200, tlaro...@polynum.com wrote: > For this one I will go with the established behavior, but what should I > do when someone is passing, in octal or in hexa: "\000" ou "\x00"? If you don't support embedded nulls in the strings you're handling (and most things don't), it's an error. -- David A. Holland dholl...@netbsd.org
Re: printf(1), sh(1), POSIX.2 and octal escape sequences
On Wed, Jun 28, 2023 at 06:32:10PM +0200, tlaro...@polynum.com wrote: > > If you want to write a two digit octal number you can not continue with > > another ocatal digit. In C you could do "...\77" "7" and have it concat > > the literals. In config files (without concatenation) you need some > > other trick. > > I beg to differ: since due to this very unfortunate "variable length" > feature, your scanner has to read char by char, it can reject the third > digit since it would yield an out of range byte value. The behavior of escapes in C strings is widely used and well understood. Don't improvise. There are such things as invalid inputs. Reject them with a reasonable diagnostic message instead of trying to guess what the user might have meant. Works out much better in the long run. -- David A. Holland dholl...@netbsd.org
Re: inetd(8): continue or exit on error?
On Fri, Jun 02, 2023 at 01:21:15PM +0200, tlaro...@polynum.com wrote:
> > I have not read most of the traffic yet, but I feel, fairly strongly,
> > that inetd should _not_ exit, except (maybe) if the config is broken
> > during its initial startup. It's a critical service.
>
> So I will put together the result of the exchanges in the thread and of
> my reading of the source:
>
> Not stopping on an error was logical with the old syntax since _all the
> directives were independent_: failing to read a line for a service
> shouldn't have the side effect of failing to serve the other services.
>
> But this assumption does not anymore with the new syntax: the feature of
> the implicit address---one does not need to specify an address: it will
> then be what is the default at the moment---makes the config a whole,
> and failing on a line may define the default address with something
> completely different from what was intended: what will be the result of
> runnin login on the external interface instead of an internal one?
>
> => a failure in the config now must discard the whole config.
I don't understand. You read the config, you check it, if it's bad you
complain to syslog and if it's good you install it. There's still no
reason to exit.
> If the [-r] mode is asked for (r for "resilient"), in case of failure to
> validate the config, inetd falls back to "/etc/inetd.fallback.conf" that
> is also parses and, if checking successful, served. If even this
> fallback fails, inetd(8) does not exit but serves the "no-op" config: it
> does nothing simply waiting for the instruction to reload the config
> ("the config" is always the one passed, explicitely or implicitely, on
> the call).
That sounds way more complicated than necessary.
--
David A. Holland
dholl...@netbsd.org
Re: inetd(8): continue or exit on error?
On Mon, May 29, 2023 at 10:11:09AM +0200, tlaro...@polynum.com wrote: > There are infelicities in /usr/src/usr.sbin/inetd/parse.c and I will > send a PR with patches attached. > > The question is what to do in case of a config file not found (this is > the initial problem: the realpath() return status is not tested and a > structure is inconditionnally added to a linked list with an unreachable > config file). > > It seems to me, since these are services, that the failure to load a > config is critical enough (since the server may be then servicing what > was not intended to be serviced; the reverse is less problematic) > to exit at least on this error. > > What do others think? I have not read most of the traffic yet, but I feel, fairly strongly, that inetd should _not_ exit, except (maybe) if the config is broken during its initial startup. It's a critical service. At the moment it's no longer the case that remote machines are likely to become completely inaccessible and require a site visit if inetd craps out, but that could change again in the future. There's at least one variant inetd out there that does not exit once started, except for SIGTERM. I know this, because I wrote/patched it :-) -- David A. Holland dholl...@netbsd.org
Re: MAXPATHLEN vs PATH_MAX
On Sun, May 28, 2023 at 08:00:37AM +0200, tlaro...@polynum.com wrote: > Le Sat, May 27, 2023 at 08:50:21PM +0000, David Holland a ?crit : > > On Sat, May 27, 2023 at 09:10:34AM +0200, tlaro...@polynum.com wrote: > > > Shouldn't be MAXPATHLEN be defined as PATH_MAX - 1? > > > > No. They're the same. The existence of some old code where somebody > > didn't read the definition carefully (or that predates a clear > > definition) doesn't change that. Not sure why you think it should... > > The comment in sys/param.h: > [snip] ...has been improved, thanks. > Shouldn't MAXPATHLEN be marked as deprecated precisely because of > the unfortunate ambiguity of its name, PATH_MAX being prefered in > it's stead, and the comment modified to clearly state it is a size > and not a length? It is historic and not going anywhere; removing it would break a lot of old code. Also, I'm not sure everyone agrees with you on that distinction of "size" and "length" (even though it makes a certain amount of sense) so be careful about drawing too many conclusions. Note that some of the length constants include null-terminator space and some don't, with no particular pattern or logic other than historical usage. E.g. MAXNAMLEN and its POSIX equivalent NAME_MAX are 511 and not 512 (historically, 255 rather than 256) because they _don't_ include the space. For no particular reason. -- David A. Holland dholl...@netbsd.org
Re: MAXPATHLEN vs PATH_MAX
On Sat, May 27, 2023 at 09:10:34AM +0200, tlaro...@polynum.com wrote: > Shouldn't be MAXPATHLEN be defined as PATH_MAX - 1? No. They're the same. The existence of some old code where somebody didn't read the definition carefully (or that predates a clear definition) doesn't change that. Not sure why you think it should... -- David A. Holland dholl...@netbsd.org
Re: style: clean up mentions of old-style C
On Mon, Apr 17, 2023 at 12:51:02PM +0200, Joerg Sonnenberger wrote: > 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. I have; I've even done it... can't remember why -- David A. Holland dholl...@netbsd.org
Re: style: clean up mentions of old-style C
On Mon, Apr 17, 2023 at 03:06:53AM +0200, Joerg Sonnenberger wrote: > > The second point is an important part of the traditional layout, and I > > think the first is still worth stating. You _still_ see K > > code, 35-odd years notwithstanding. > > I'd suggest to also explicitly call out that functions with no arguments > are written as f(void) in C. +1 > > > Declaring a prototype for 'main' is so uncommon that I don't see a point > > > mentioning it. > > > > If it's going to be mentioned it should say "don't do that". It was a > > thing at one point, but a stupid thing... > > There is actually a valid reason for having a prototype for main: it > makes it easier to rename main via macros and not run into certain > warnings. ...but if you're going to do that it seems like you should arrange for a declaration of the new name to appear in a header somewhere in scope (and in scope of the caller) and that those warnings shouldn't be short-cut away. Otherwise sooner or later you'll get bitten by a main() that expects the env argument. -- David A. Holland dholl...@netbsd.org
Re: style: clean up mentions of old-style C
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 two lines: > > > * Use ANSI function declarations. ANSI function braces look like > > * old-style (K) function braces. > > I don't know what 'ANSI function braces' are or how they might differ > from 'old-style function braces'. What is the point of this sentence, > and why is it needed? How about (given what people have said about the sentence): * Use full function prototypes in all declarations and definitions. * The open-brace for a function body goes on its own line. The second point is an important part of the traditional layout, and I think the first is still worth stating. You _still_ see K code, 35-odd years notwithstanding. > I also suggest this change: > > - * ANSI function declarations for private functions (i.e. functions not > > used > > - * elsewhere) and the main() function go at the top of the source module. > > + * Declarations for private functions (i.e. functions not used elsewhere) > > go > > + * at the top of the source module. > > The words 'ANSI function' are redundant. Also replace this notion of "private" with "file-static"; non-static private functions shouldn't exist, and I'm reasonably certain everything we expect to be style-compliant at all has had static applied as needed. Thus, * Declarations for file-static functions go at the top of the file. Might say "Forward declarations" or even "Any needed forward declarations". I think we don't have an official stance on whether files should be ordered caller-first or callee-first, and the code base includes examples of both, but in the latter case forward declarations are rare and unnecessary ones shouldn't be encouraged. (They serve no purpose and create a maintenance headache.) However, this point might warrant further discussion. > Declaring a prototype for 'main' is so uncommon that I don't see a point > mentioning it. If it's going to be mentioned it should say "don't do that". It was a thing at one point, but a stupid thing... -- David A. Holland dholl...@netbsd.org
Re: flock(2): locking against itself?
On Mon, Apr 17, 2023 at 12:19:19AM +, David Holland wrote: > However, I'd expect that getting a second open of the same tty for the > output would work around this. (dup isn't enough, but a new open > should work, because non-blocking I/O is a file-handle-level mode, not > a tty driver mode.) Since there seems to have been some confusion about this upthread: FIONBIO works by setting FNONBLOCK on the struct file. This then results in IO_NDELAY being set on VOP_READ/VOP_WRITE calls. The FIONBIO is also forwarded to underlying objects, ioctl being the mess it is, but it seems the primary consumer of that is the socket layer; in particular tty.c does nothing upon receiving it. This means the state is per-open. Also, regarding something else mentioned upthread, see O_NOSIGPIPE. -- David A. Holland dholl...@netbsd.org
Re: flock(2): locking against itself?
On Sun, Apr 16, 2023 at 12:28:03AM -0400, Mouse wrote: > Back on 2023-03-30, I posted to tech-kern on a thread that had drifted > off-topic for tech-kern, into tech-userlevel territory. I was writing > about bad interactions between libcurses and nonblocking I/O. > > [...] > > It seems to me that there are multiple issues with libcurses here. > > (1) It does not get along with input and/or output being set > non-blocking. Bug. While, in principle, when you're using curses it owns both the input and the output, in practice because curses input can't cope with select loops it's common for curses applications to use curses only for output and do other things with the input, so it's reasonable for the input to be nonblocking and this can make the output nonblocking as well. However, I'd expect that getting a second open of the same tty for the output would work around this. (dup isn't enough, but a new open should work, because non-blocking I/O is a file-handle-level mode, not a tty driver mode.) Since it apparently doesn't my guess is that there are places in the curses code that don't clearly distinguish input and output and this causes it to get tangled in its shoelaces when they aren't the same object. Meanwhile, curses not being able to interact with select loops is also a bug (one I've complained about before) and, realistically, one that'll need fixing for successful use of nonblocking input _with_ curses. Unfortunately fixing all of this is not trivial, so nobody's likely to take it up anytime soon. > (2) newterm() takes FILE *s rather than file descriptors, but requires > for correct operation that they be connected to file descriptors anyway > (it uses fileno() all over the place). > > (3) Even if the FILE *s _are_ connected to file descriptors, it does > not work correctly unless those descriptors are connected directly to > tty devices. My recommendation for this would be to restructure the whole thing to use its own handle structure internally that has an ops table so at least the mess is contained in one place. But this is a large undertaking too. Then of course you also need a nonstandard replacement newterm() that provides the extra ops needed. > (4) There's no way, without going under stdio's hood, to create a stdio > stream that operates like a funopen()ed stream but allows the caller to > arrange for fileno() to return something useful. That probably isn't the right direction to go in, I think. > At this point, I'm tempted to pull the screen-updating smarts out of > libcurses (that's the only part I want to use, here) and make it > available under an API that has absolutely nothing OS-dependent about > it, possibly excepting terminal type capabilitiy lookup. So, I'm > writing to ask: > > (a) Does anyone have any other ideas, not mentioned above, for how to > address these issues? None that aren't super expensive. > (b) Does anyone know of any work done towards pulling the screen > updater out of curses, so it can be used without all the baggage tied > to the OS that libcurses imposes? > > (c) If not, would there be any interest in such a thing? As you probably remember I've argued at length in the past that memory-mapped screens should have a memory-mapped screen interface at the device level. (In which case that screen updater is only needed as a driver for serial-attached terminals.) However, that's also a huge undertaking and I've never actually done the work. Anyway, my guess is that pulling the screen updater out is roughly the same as what I suggested above about using its own handle structure internally, if you want something that works more or less like the current curses (you feed it text, it outputs other text). It might also to be possible to split it at a level where the ops are basically "write a chunk of text at this location" and calls for the various termcap capabilities it knows about, and then you plug it into termcap explicitly, but that seems like even more work. Although it also provides a framework that one could use to output to a graphics system window, which would be a nice thing to have. If opening a second fd for output doesn't work and debugging what's happening with that isn't feasible, I don't think there's any approach here that isn't a large pain. I guess the other question is: for what you're doing, do you really need the full screen updater? Unless it's intended to talk over a slow serial line (like, less than 19200 bps) a much simpler line-at-a-time updater will serve perfectly well. I imagine there are some extant implementations already, and if not, writing one will probably be less work than grinding the curses we have. -- David A. Holland dholl...@netbsd.org
followup style(5) change
I don't expect the following to be controversial: Index: style === RCS file: /cvsroot/src/share/misc/style,v retrieving revision 1.69 diff -u -r1.69 style --- style 30 Mar 2023 10:39:30 - 1.69 +++ style 1 Apr 2023 20:48:50 - @@ -355,8 +355,8 @@ /* * When declaring variables in functions declare them sorted by size, * then in alphabetical order; multiple ones per line are okay. -* Function prototypes should go in the include file "extern.h". -* If a line overflows reuse the type keyword. +* Function prototypes and external data declarations should go in a +* suitable include file. If a line overflows reuse the type keyword. * * Avoid initializing variables in the declarations; move * declarations next to their first use, and initialize (I'd apparently already been carrying this change in one of my trees since 2012, along with some related ones superseded by the externs update, and got reminded of it by a merge conflict) -- David A. Holland dholl...@netbsd.org
Re: make(1): is this a bug or PEBKAC?
On Tue, Feb 21, 2023 at 11:54:40PM -0500, Mouse wrote: > > To make the makefile easier readable and at the same time avoiding > > line noise, you can use a multi-variable .for loop, which are > > available since 2000: > > Maybe. I'd have to see if that's present in all the make versions I > care about. I use on more than just work machines It won't be in 1.4T's make but it should be in everything else you're likely to run into these days. % cvs log for.c : revision 1.7 date: 2000-04-16 18:08:06 -0400; author: christos; state: Exp; lines: +158 -78; PR/9899: David A. Holland: multi-variable .for constructs in make -- David A. Holland dholl...@netbsd.org
Re: mail(1) editline defaults to vi mode?
(sorry about the long reply latency) On Sat, Feb 18, 2023 at 07:46:24PM -0500, Mouse wrote: > >> I think that input line editing, no matter how fancy, should be > >> invisible to simple applications, as invisible as erase and kill > >> processing is for applications that run in cooked mode today. [...] > > > Ultimately the problem is that teletypes are baked into the core > > architecture of Unix and all more sophisticated user interaction has > > been bolted on top instead of being redesigned in. > > I agree and I disagree. > > If by "teletypes" you mean "octet streams", well, it might be an > overstatement to say that "everything is an octet stream" is the > unifying concept that has made Unix Unix, but not by much. I'm not > sure I'd call that "the problem", though. No, I mean "teletypes". The reasons we can't have real input line editing except as a bolt-on library are: - Real editing, as opposed to cooked mode, requires terminal control operations. But the abstraction in the kernel is a teletype, not a terminal, and it doesn't have any such concept as terminal control. Because termcap and then curses got bolted on top of the teletype layer, you can't have its concepts _in_ the teletype layer. - Editing also requires, or at least strongly desires, cursor keys and other function keys beyond typing single characters on a teletype keyboard. But similarly, because termcap and curses got bolted on top of the teletype layer, those concepts are not available in the teletype layer either. Furthermore, because input handling in curses has always been rubbish, the world is full of application code that does its own input interpretation; the situation is far worse than with output. - And then, completion and history are application-level functions, so they inherently can't be done in the teletype layer, or any other system-level input layer. Instead, the input read by the application has to have enough structure that the application can read and go "aha, the input layer has sent me this much and wants completions for the rest", or "aha, the input layer is asking for history entry 72, let me send it off". But because everything other than typing single characters on a teletype keyboard got bolted on top, there's no straightforward way to have that structure that doesn't interfere with other things that might be happening. - It only gets worse if you start considering that there might be other ways to produce input that have different semantics from typing (e.g. under normal circumstances if you paste you are intending to paste text and not editing operations; and also, input from dictation has different editing requirements), or additional functionality beyond completion and history (such as autocorrect). These reasons are obviously addressable -- at least some of them should have been addressed forty years ago or more, and it's been at least thirty since cooked mode became clearly inadequate -- but they require making fundamental changes. And that's just for input line editing for programs that are still basically using standard input. It only gets more complicated when you also have screen-mode programs and GUI programs and whatnot. And then, today the consoles of computers have a lot more functionality than typing ASCII characters. Quite apart from GUI programming and video, there's also pointing devices, stylus or other drawing-type input, assorted HID objects, stuff you plug into the front panel like scanners and cameras, and audio... along with stuff that Unix basically just doesn't handle at all like GPS/location services, accelerometers, or battery state. All of this ought to be available systematically as input to applications (or not, depending on permissions) rather than a mess of ad hoc devices and libraries. But that's not what we have; we have teletypes. > The very notion of a command line owes a good deal to that unifying > principle, it seems to me. I was never fortunate enough to use > interactive OSes designed without Unix available to draw on (while it > is just an assumption on my part that such exist, it seems likely). Well, there were quite a few; e.g. RT-11 and RSX-11 (which eventually grew into VMS), not to mention assorted mainframe horrors; plus the BASIC interpreter UIs of the 8-bit machines. I'm not sure where CP/M stood. MS-DOS ultimately had a notion of standard input, but I don't know/remember how early it appeared; but applications that had user interfaces tended to ignore it, just as they ignored DOS's standard output and wrote directly to the video card. Then there's MacOS Classic, but it never had anything resembling a command line of any kind. (Even today, Unix with curses or readline and whatnot is still, from the point of view of an application wanting to have a user interface and take input, largely a regression from the MS-DOS environment.) Anyway, one of the ways Unix was different is that the shell wasn't magic or privileged, and
Re: mail(1) editline defaults to vi mode?
On Sat, Feb 18, 2023 at 01:56:22PM -0500, Mouse wrote: > I think that input line editing, no matter how fancy, should be > invisible to simple applications, as invisible as erase and kill > processing is for applications that run in cooked mode today. > Applications that want frills, such as shells that want input history > that stretches back across multiple sessions, programs that want > completion of their own private command names, those will have to do > something to get them. But then, they do now too; it's just a question > of designing the right interfaces. > > But even that much is no easy task. Ultimately the problem is that teletypes are baked into the core architecture of Unix and all more sophisticated user interaction has been bolted on top instead of being redesigned in. By the time you fix it, it's not Unix any more. -- David A. Holland dholl...@netbsd.org
Re: shutdown sequence and UPS poweroff
On Fri, Jan 06, 2023 at 10:13:36AM -0500, Greg Troxel wrote: > Does it seem reasonably safe that mountall through root will be fast, < 10s? We've been seeing scattered reports of unmounting taking fast amounts of time, particularly on nvme devices, and I don't think we know why yet. It's a bug, but since not cutting the power to SSDs midflight is one of the primary reasons to have a UPS these days... seems like a dangerous on in this context. So it seems like a good idea to be cautions. Not sure what to recommend. The last time there was an issue like this (which turned out to be a bad bug with cached data not being written back until unmount time) it was possible to trigger the writing by attempting an unmount you know will fail with EBUSY, but I don't think we've ascertained if that works this go. -- David A. Holland dholl...@netbsd.org
Re: strftime(3) oddities with %s, %z
On Sun, Nov 06, 2022 at 05:31:59PM +, David Holland wrote: > > [Aside: a truly bizarre factoid - when we do eventually claim, in > > unistd.h, that we support Posix.7 (ie: 2008) rather than Posix.6 (2001) > > the support we have for strftime_l() will actually vanish - the function > > will still be there, but will simply be a clone of strftime(), > > ignoring the passed in locale. That wacky logic comes from > > tzcode, as many users of it have no locale handling at all, > > so our implementation will need local fixing sometime]. > > Can you file a PR on that? It seems likely that if nobody does > anything about it sooner or later the way we'll discover it again is > by random barely-debuggable browser or JVM misbehavior. The plot thickens! This is not true. There are two copies of strftime_l in strftime.c, one that works and one that behaves as you describe; the latter one is inside #if HAVE_STRFTIME_L, which I guess is false. So I guess if the _POSIX_VERSION gets bumped it'll just break the build. :-) Any reason not to remove that one? -- David A. Holland dholl...@netbsd.org
candidate strftime docs patch
The following patch is based on the assumption that the current points of contention (e.g. about undefined behavior calling mktime) are irrelevant for the time being as taking advantage of them requires code changes. Index: strftime.3 === RCS file: /cvsroot/src/lib/libc/time/strftime.3,v retrieving revision 1.37 diff -u -r1.37 strftime.3 --- strftime.3 25 Oct 2022 08:07:07 - 1.37 +++ strftime.3 6 Nov 2022 17:55:28 - @@ -32,7 +32,7 @@ .\" from: @(#)strftime.3 5.12 (Berkeley) 6/29/91 .\"$NetBSD: strftime.3,v 1.37 2022/10/25 08:07:07 kre Exp $ .\" -.Dd October 9, 2020 +.Dd November 6, 2022 .Dt STRFTIME 3 .Os .Sh NAME @@ -147,7 +147,9 @@ of leap seconds. .It Cm \&%s is replaced by the number of seconds since the Epoch (see -.Xr ctime 3 ) . +.Xr ctime 3 ) under the assumption that the time in +.Fa timeptr +is expressed in the current local time zone. .It Cm \&%T is replaced by the time in the format .Dq Li %H:%M:%S . @@ -185,13 +187,13 @@ .It Cm \&%y is replaced by the year without century as a decimal number [00,99]. .It Cm \&%Z -is replaced by the time zone abbreviation, -or the empty string if this is not determinable. +is replaced by the time zone abbreviation of the current local time +zone, or the empty string if this is not determinable. .It Cm \&%z is replaced by the offset from the Prime Meridian in the format +HHMM or -HHMM (ISO 8601) as appropriate, with positive values representing -locations east of Greenwich, or by the empty string if this is -not determinable. +locations east of Greenwich, reflecting the current local time zone, +or by the empty string if this is not determinable. The numeric time zone abbreviation \&- is used when the time is Universal Time but local time is indeterminate; by convention this is used for @@ -227,6 +229,13 @@ .Ft "const timezone_t" .Fa tz argument. +This time zone is used instead of the local time zone when handling +the +.Cm \&%s , +.Cm \&%Z , +and +.Cm \&%z +conversions. .Sh RETURN VALUES If the conversion is successful, .Nm @@ -289,6 +298,28 @@ .Ql \&%v conversion specifications are extensions. .Pp +Note that while in +.Nx +the +.Vt tm +structure contains fields that describe the time zone, this is an +extension, and standards compliance prevents +.Fn strftime +from using these fields when printing. +In particular, attempting to print a +.Vm tm +structure produced by +.Xr gmtime 3 +will not necessarily produce the intended results. +Portable code that wishes to print in multiple timezones must use +.Xr tzset 3 +to change time zone explicitly, then call +.Xr localtime 3 +and then +.Fn strftime +in each zone. +This is not thread-safe. +.Pp Use of the ISO 8601 conversions may produce non-intuitive results. Week 01 of a year is per definition the first week which has the Thursday in this year, which is equivalent to the week which contains the fourth Index: tm.3 === RCS file: /cvsroot/src/share/man/man3/tm.3,v retrieving revision 1.5 diff -u -r1.5 tm.3 --- tm.323 Oct 2022 15:43:40 - 1.5 +++ tm.36 Nov 2022 17:55:34 - @@ -24,7 +24,7 @@ .\" ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE .\" POSSIBILITY OF SUCH DAMAGE. .\" -.Dd April 14, 2011 +.Dd November 6, 2022 .Dt TM 3 .Os .Sh NAME @@ -83,6 +83,13 @@ in this form in future releases of . Nx . .Pp +In any event these fields are ``informational'' in the sense that they +are filled in by library routines that produce +.Vt tm +structures, but are not used by library routines that consume +.Vt tm +structures; portable code is free to not provide values for them. +.Pp The .Fa tm_gmtoff field denotes the offset (in seconds) of the time represented -- David A. Holland dholl...@netbsd.org
Re: strftime(3) oddities with %s, %z
On Sat, Nov 05, 2022 at 08:49:57PM +0700, Robert Elz wrote: > | (a) It follows from the observations so far that if I set ->tm_gmtoff > | to 101 and ->tm_zone to "abracadabra" (as well as populating the rest > | of the structure), and ask strftime to print those fields, it will not > | print them but print something else. I continue to fail to see how > | this is anything other than a bug. > > OK, I have looked into that now, and it turns out not to be a bug, > but by design. The whole story wrt these two is a little complex... > [...] Ok, so it turns out that C99 does exactly specify which fields of struct tm are used by each strftime conversion, which I missed on the first go and nobody bothered to point out explicitly. This means strftime must ignore any timezone fields present in struct tm other than tm_isdst when printing %z and %Z, even though C99 leaves all other timezone behavior as implementation-defined. Therefore it is impossible to have timezone fields in struct tm, use them in strftime for %z and %Z in what any reasonable person would conclude is the correct manner, and still be C99-compliant. Or POSIX compliant either since POSIX imports the same restrictions. This is unfortunate. It seems to orphan this text in POSIX: : If a struct tm broken-down time structure is created or modified by : gmtime() or gmtime_r(), it is unspecified whether the result of the %Z : and %z conversion specifiers shall refer to UTC or the current local : timezone, when strftime( ) is called with such a broken-down time : structure. since in the absence of significant magic this clearly requires having and using timezone fields in struct tm. However, it wouldn't be the first time a standard intended to allow certain behavior without actually making it legal. I do wonder, however, since it was mentioned earlier in this thread that POSIX is planning to add timezone fields to struct tm, what they're intending in this regard. Do you have a link to that proposal? Meanwhile, however, this doesn't affect %s since it isn't in C99 and POSIX is free to define it as derived from whatever struct tm fields they want. Furthermore, though I gather this has not actually been done, it would be reasonable to extend the above permission to use UTC to %s. I also don't see that any of this constitutes permission to pass a struct tm containing uninitialized fields, especially if the format contains %s. There is nothing in the C99 description of mktime (or POSIX either) that specifies which fields it uses, so passing a struct tm with uninitialized fields to mktime, and thus for %s and strftime given the proposed definition of %s, constitutes UB. Since both C99 and POSIX allow additional fields, there must be some form of initialization that covers them. Consequently I don't see any reason, other than the question of extending the above permission, why %s and also mktime can't use the timezone fields in struct tm, and therefore produce the correct answer in the various scenarios that have been described. If the state of the real world is that code that conses up struct tm doesn't actually bzero it first (or use an explicit struct initializer), then using the timezone fields is perhaps unwise in the near term. I also wonder how POSIX plans to handle this if they're proposing adding those fields. (Note that questions about bzero vs. explicit initializers and all bits zero are a red herring -- we do not run on the DS9000.) > That by itself is not all that illuminating. But the standard also says > > Local timezone information shall be set as though strftime() > called tzset(). > > That's POSIX text, but I believe the C standard has a similar requirement, > worded a different way (as it does not have tzset()). C99 doesn't say anything about it. It is all implementation-defined. However, all that text says is that the local timezone information is set, so that it's available; it does _not_ say the local timezone information is _used_, either there or in the definitions of %z and %Z, and given the paragraph that attempts to give permission to print GMT if the struct tm notionally reflects UTC, it does not seem reasonable to assert that %z and %Z necessarily print the _local_ timezone. (C99 doesn't even have the words "the time zone"; the only text it has that says anything at all about what zone might be intended is "if no time zone is determinable". So if you can determine a time zone, you can use it to print %z or %Z; but you can't determine it based on extra fields in struct tm.) > The reason why appears earlier in strftime.c, after private.h > is included, but before there is any code: > > /* > ** We don't use these extensions in strftime operation even when > ** supported by the local tzcode configuration. A strictly > ** conforming C application may leave them in undefined state. > */ > > #ifdef _LIBC > #undef TM_ZONE > #undef TM_GMTOFF >
Re: strftime(3) oddities with %s, %z
On Wed, Nov 02, 2022 at 02:54:01PM +, Taylor R Campbell wrote: > Suppose you create a struct tm _without_ gmtime(3) or localtime(3), > using designated initializers or memset for zero-initialization, with > only what is included in POSIX: > > [...] > > This struct tm doesn't specify a time zone in which to interpret the > calendar date. So what time_t do you get out of mktime(), or what > number is represented by the string you get out of strftime(..., "%s", > )? > > [...] > > Now what if TZ is not UTC, say TZ=Europe/Berlin? It obviously depends > on whether mktime and strftime examine TZ or tm_gmtoff. Here are some > possible rules to answer this: How about: 5. Also add a field tm_tzinfo to struct tm, with three possible values TZINFO_UNSET (which is 0), TZINFO_LOCAL, TZINFO_EXPLICIT. Then if you cons up your own struct tm without knowing about the zone fields, and either bzero it or give it a suitable initializer, it will come out with TZINFO_UNSET. If it comes from localtime(), it'll come from TZINFO_LOCAL. In other cases (including both gmtime() and intentional use) you set it to TZINFO_EXPLICIT. Then in mktime you use the last tzset() result for TZINFO_UNSET (which is required for compat with portable code) and for TZINFO_LOCAL (which is required for the corner case you came up with involving calling tzset again), and for TZINFO_EXPLICIT you use the zone info in the struct tm. I think that correctly covers all the cases that have been suggested so far. (This is why I mumbled yesterday about maybe needing a compat mess to fix our code; we don't have such a field, and checking the timezone name pointer for NULL isn't quite adequate. Though maybe setting it to something reserved in localtime would do the trick.) > It seems to me either we need a new API, or we risk breaking existing > programs. I don't think so. (On the subject of initializers vs. bzero and whatnot, that's a red herring.) -- David A. Holland dholl...@netbsd.org
Re: strftime(3) oddities with %s, %z
On Tue, Nov 01, 2022 at 05:20:17AM +0700, Robert Elz wrote: > [a small book] You can rehash the same points over and over again, and continue to introduce irrelevant distractions, and continue to assert without evidence that correct behavior is impossible, but the various facts remain: (a) It follows from the observations so far that if I set ->tm_gmtoff to 101 and ->tm_zone to "abracadabra" (as well as populating the rest of the structure), and ask strftime to print those fields, it will not print them but print something else. I continue to fail to see how this is anything other than a bug. Similarly, if I ask it to print %s, it will bring the wrong time_t value. I continue to fail to see how *this* is anything other than a bug. (b) Our implementation contains the timezone info in struct tm. This does not make our implementation noncompliant; the current posted text says "The header shall declare the tm structure, which shall include at least the following members:", not "exactly the following members". It follows (I can find no text to contradict this) that consing up your own struct tm to call strftime without bzeroing it first risks producing undefined behavior and is therefore incorrect. (c) Consequently it's easy to construct a compliant implementation that contains tm_gmtoff and tm_zone in struct tm and where strftime behaves correctly with respect to these values for %z, %Z, and %s. (Whether our implementation can be corrected without a compat mess is less clear.) (d) It is, in general, quite easy to write standards language that acceps both full correct and less than ideal implementations for cases where the incorrect implementations cannot be fixed. In fact, the current posted text says: : If a struct tm broken-down time structure is created or modified by : gmtime() or gmtime_r(), it is unspecified whether the result of the : %Z and %z conversion specifiers shall refer to UTC or the current : local timezone, when strftime() is called with such a broken-down : time structure. That is more specific than I had suggested, but clearly completely suitable. (And given this text, I completely fail to understand why they are proposing to change things.) (e) Standardization that precludes a correct implementation, or that mandates an incorrect implementation, remains wrong and inappropriate. Meanwhile we've clearly reached the point where you're wilfully misinterpreting what I'm writing in order to dismiss it, not to mention introducing specious analogies and committing a couple other rhetorical fouls. So I have a feeling that nothing productive is likely to happen going forward. -- David A. Holland dholl...@netbsd.org
Re: strftime(3) oddities with %s, %z
On Mon, Oct 31, 2022 at 07:25:34PM +0700, Robert Elz wrote: > Date:Sun, 30 Oct 2022 20:27:43 + > From: David Holland > Message-ID: > > | "%sis replaced by the number of seconds since the Epoch" > > Yes, though as has been mentioned before, that's incomplete (no matter > what you think should happen here, that isn't enough info to conclude > what that would be). Yes and no. The number of seconds since the epoch is only one value, regardless of timezone. The question is what the interpretation of the timezone in struct tm is, and the fact remains that the principle of least surprise dictates that a struct tm produced by gmtime() refers to UTC. Furthermore, the principle of least surprise also fairly strongly suggests that if in this case strftime prints an hour and zone name that are inconsistent (meaning that the timezone informs the printing of the hour but not the printing of the timezone itself), it is wrong. > | Changing it just in this particular corner because of an > | implementation defect is particularly silly. > > No-one is changing it here either. Yes, they are. They are proposing that %s print a nonsense value that is not the number of seconds since the epoch. For that matter, since they're apparently also adding the timezone info to struct tm, you can prepare a struct tm with the timezone info you intended and you will then still get the wrong value out from %s. > Further, if there is an implementation defect, it would require > intrusive changes to correct it. Not necessarily. > That's because you have forgotten one vital issue in all of this. No, I haven't. I am aware of what the implementation issue is, which is that apparently in some implementations struct tm lacks timezone info so it's impossible for it to work correctly. However, as I've already said, there's a well-established path for standardization in the presence of implementation issues that someone doesn't want to have to fix. Standardizing _wrong_ behavior so it's impossible to produce an implementation that is both correct and standards-compliant is extremely foolish. > Making the output > of %s be implementation defined or unspecified would be the same as the > situation we're in now (where %s isn't in the current standard at all) > and so, what it produces if used is simply unspecified. It might be > possible to make it better than "anything" by having it say "converted > to the string representation of an unknown integer", but that doesn't > really help does it? For anyone to be able to reliably use %s, it needs > a proper definition, and that definition needs to agree with the > implementations, or the whole thing is useless. %s is far too useful > in scripts ( via T=$(date +%s) ) to keep it a hidden buried undefined > interface. Any definition is better than that. Nonsense. "%s is replaced with the number of seconds since the Epoch. If the time in the struct tm argument is not expressed in the current local time zone, such as returned by the localtime() function, the value output is unspecified." That makes everybody's code is compliant and leaves people with non-broken implementations free to make it work correctly. And then we can make it work correctly in NetBSD, and add something to the man page like "Portable software should call tzset(3) before printing values in other timezones." And then maybe in ten years after some other people fix their code and others drop off the market, the unspecified behavior can be removed from the standard. > | No, there is no obligation to standardize incorrect behavior. > > Of course not. But there is nothing incorrect here. It is simply not > the interface you might have liked to see. Kind of surprising that you're > only complaining about it now, since it has been like this in NetBSD since > at least 1997 (when strftime.c was moved from wherever it was before into > src/lib/libc/time/ - I didn't bother to track down its previous location) > > You've had 25 years to complain about it, and until now, never have. It > cannot really have been much of an issue. Rubbish. In order to notice that it doesn't work you have to either audit the code very carefully (since to a casual inspection it looked like it was doing the right thing, only it doesn't actually work) or have the bad luck to explicitly stumble on the particular stftime formats that don't work. Since most of the ones likely to be used all function correctly, and in particular the ones you _will_ use if you call gmtime() and then strftime() and expect to print UTC do, this is highly unlikely. (That is: if you mean to print UTC and call gmtime and then strftime, why would you ever include the zone name or zone offset in the output format? You wouldn'
Re: strftime(3) oddities with %s, %z
On Thu, Oct 27, 2022 at 09:06:26PM +0700, Robert Elz wrote:
> | I don't see how POSIX proposing to define a function to produce a
> | wrong (and completely meaningless, no less!) answer makes it correct.
>
> The answer is neither wrong nor meaningless, it simply doesn't
> do what you might have wanted it to do. For typical uses (I use %s
> all the time, generally via "date +%s") it works exactly as intended.
> It also works when used as "date -u +%s" (both of these uses might have
> a -r or -d option to set the time desired, rather than just "now"), as
> date -u is set up to use UTC correctly.
"%sis replaced by the number of seconds since the Epoch"
That is, it's supposed to print the time_t value. In the context of
time_t as it's universally known, there is no timezone offset and no
timezone handling; it is the absolute time (modulo leap second issues,
which are an entirely different issue) and timezones are only
introduced when times are prepared for printing.
This is a fundamental design property of Unix time handling. Changing
it would be a mistake.
Changing it just in this particular corner because of an
implementation defect is particularly silly.
> Further, what POSIX is doing (it is already in the drafts) is specifying
> what the implementations (including ours, and glibc) actually do. That's
> what the users should expect to happen.
No, there is no obligation to standardize incorrect behavior. When
existing implementations have incorrect or variant behavior they don't
want to bother to fix, the correct response by the standards committee
is to make the result unspecified, or implementation-defined, or put
it in some other similar category.
For my part, I had never had any idea you couldn't use strftime with
gmtime() results, and I'm pretty sure I have done so at times, going
back all the way to when I first met this interface in Turbo C in the
1980s. Nor is there any reason to suspect that it wouldn't work. So I
consider this whole thing a significant violation of the principle of
least surprise.
> If you want something different, implement that, and then get the rest
> of the implementations to actually adopt it - and then propose it to
> POSIX, you never know, it might appear in the standard following the
> next one (in another 5-10 years).
Standardizing what is clearly _wrong_ behavior precludes fixing it.
> I will look into the timezone stuff in strftime(), but from when I glanced
> at it yesterday, it seemed to be simply using what is in the struct tm,
> passed in, so it may be that gmtime() isn't putting something useful in
> those fields (after all, if you're using gmtime() you ought to know that
> the zone name is GMT or UTC (your pick) and that the offset is 0). It
> is also perhaps affected by tm_isdst, which I assume gmtime() always sets
> to 0.
It looked to me like it was probably built with the wrong ifdefs, but
maybe not. I didn't look very hard either.
> It would help if you shared the "./test" program you used (source, doesn't
> matter how crufty - I understand quick and dirty tests) so I can reproduce
> your results.
Nothing surprising:
--
#include
#include
#include
static void print(const char *desc, struct tm *tm) {
char buf[256];
strftime(buf, sizeof(buf), "%c %Z %z (%s)", tm);
printf("%s: %s\n", desc, buf);
}
int main(int argc, char *argv[]) {
time_t timer;
timer = atol(argv[1]);
print("gmtime", gmtime());
print("localtime", localtime());
return 0;
}
--
Results don't depend on the order of the print calls. In the local
environment here, $TZ isn't set explicitly by default, and
/etc/localtime points to US/Eastern.
--
David A. Holland
dholl...@netbsd.org
Re: strftime(3) oddities with %s, %z
On Wed, Oct 26, 2022 at 08:42:16PM +0700, Robert Elz wrote: > Date:Wed, 26 Oct 2022 04:16:03 + > From: David Holland > Message-ID: > > | Where is this documented? > > As much as your message can be construed as a complaint about the > documentation, I agree, it should be better. > > For most of the rest I'm assuming that you replied to my earliest > message in this thread before you read the rest of them. No? I don't see how POSIX proposing to define a function to produce a wrong (and completely meaningless, no less!) answer makes it correct. > | I would expect strftime to print GMT if fed the results of gmtime(), > | and indeed ours does. > > As you demonstrated, indeed ours doesn't. It does produce > (not print, strftime() is not an I/O function) what posix > is going to require it to produce in this area however. > Most of the strftime() conversions are indeed just localised > sprintf's (effectively, not literally) of the values in the struct tm, > and work whatever is in the tm > [...] Emitting binary representations into a string buffer is a form of "printing". But anyway, if this is so, why does it print the wrong timezone? It seems to be configured to do it wrong on purpose. -- David A. Holland dholl...@netbsd.org
Re: strftime(3) oddities with %s, %z
On Tue, Oct 25, 2022 at 02:56:23PM +0700, Robert Elz wrote: > I am not sure that calling strftime() on something obtained from gmtime() > makes any sense. If one wants UTC conversions, either use strftime_z() > (not a POSIX interface) or set the timezone to UTC (tzset() with TZ="UTC"). Where is this documented? I would expect strftime to print GMT if fed the results of gmtime(), and indeed ours does. Its man page says it "formats the information from timeptr" (timeptr being the struct tm argument) and says nothing about either including or depending on other random information, or restrictions about where the struct tm is allowed to have come from. There is also nothing in gmtime(3) or tm(3) about this supposed restriction. This is what I get printing %c %Z %z %s: % ./test 20 localtime: Tue May 17 23:33:20 2033 EDT -0400 (20) gmtime: Wed May 18 03:33:20 2033 EST -0500 (218000) That is, it prints the correct time but the wrong zone, gets the %s value wrong by the offset of the zone it prints, and _also_ doesn't even manage to print the local zone correctly by virtue of apparently fumbling summer time. Or maybe by using the GMT/UTC rules for summer time (that is, none) instead of using the rules for the zone it printed. I see no reason to consider this anything but a bug, especially since our struct tm contains the timezone info. (And while I'm complaining, strftime_z(3) says nothing about what the passed-in zone does or how it modifies the output, let alone whether it has to be consistent with a previous call to localtime_rz(3) that fetched the struct tm.) -- David A. Holland dholl...@netbsd.org
Re: have a pint
On Mon, Oct 24, 2022 at 02:17:38AM +, David Holland wrote: > > TLDR: the "(US) survey foot" is 1200/3937 SI meters, and the > > "(international) foot" is > > 0.3048 SI meters, a ratio of about 1.0204000:1 or 1:0.98. > > Seems like the right thing to do is > >-surveyfoot british-ft >+surveyfoot 1200|3937 meter > >-geodeticfootbritish-ft >+geodeticfootsurveyfoot > > and kill off "british", unless anyone can think of a reason to keep > this name for almost-but-not-quite-1. > > Note that we have > > inch2.54 cm > > which is exactly equivalent to 0.3048 meters per foot. FWIW, I have done this. >From what I've been able to tell, survey feet are exclusively a US thing and so the adjective unit "british" to get them (and their derived units) was not just confusing but also backwards. -- David A. Holland dholl...@netbsd.org
Re: have a pint
On Sun, Oct 23, 2022 at 08:36:51PM -0500, Jonathan A. Kollasch wrote: > > (c) units.lib should get some editorial attention. Does anyone know > > what "british" is supposed to be there for? > > It looks like it's a common definition of the US "survey foot". > > https://www.nist.gov/pml/us-surveyfoot has some background on the > unit. It's been deemed obsolete since January 1, 2022. I'm not sure > why units.lib calls the ratio "british" though. > > TLDR: the "(US) survey foot" is 1200/3937 SI meters, and the > "(international) foot" is > 0.3048 SI meters, a ratio of about 1.0204000:1 or 1:0.98. Seems like the right thing to do is -surveyfoot british-ft +surveyfoot 1200|3937 meter -geodeticfootbritish-ft +geodeticfootsurveyfoot and kill off "british", unless anyone can think of a reason to keep this name for almost-but-not-quite-1. Note that we have inch2.54 cm which is exactly equivalent to 0.3048 meters per foot. -- David A. Holland dholl...@netbsd.org
have a pint
% units 551 units, 41 prefixes You have: pint You want: imperial pint * 0.83267413 / 1.20095 Ok, well enough. Lots of people forget that these are different, but it's a thing and it's good that units knows about it. (Maybe it should be less US-centric, but that's not what I'm looking at tonight.) This is also reasonable: You have: pint You want: brpint * 0.83267248 / 1.2009524 Except wait, they're not quite the same... You have: imperial pint You want: brpint * 0.9802 / 1.02 I assume that's a rounding bug and not intentional. This, however, seems problematic: You have: imperial pint You want: british pint * 1.2009476 / 0.8326758 I assume the word "british" in units.lib is meant for use as an adjective in some other other context. However, I'm wondering what, given this: You have: british You want: 1 * 1.02 / 0.98 That is, it's almost but not quite 1, probably because of rounding. Meanwhile this doesn't work: You have: pint You want: metric pint units: Unknown unit 'metric' which given the way units works isn't surprising, but this could and doesn't: You have: pint You want: metricpint units: Unknown unit 'metricpint' (where a metric pint is 500 mL) Meanwhile things like this shouldn't be allowed: You have: lightyear You want: imperial lightyear * 0.83267413 / 1.20095 You have: lightyear You want: british lightyear * 0.98 / 1.02 since "imperial" is correctly only useable as a modifier on certain volume units. Then, units.lib defines a constant fuzz == 1 that appears to be used to tag definitions that are not precise, but it's used inconsistently and not always correctly (e.g. it's attached to c and should not be) and units itself doesn't know about it or what it means so it serves no actual purpose currently. So, some propositions: (a) Dimensional analysis is great but it seems like we ought to have some additional typing rules to prevent misuse of adjective units; (b) units ought to be able to track the number of significant digits in its definitions and computations and print accordingly; (c) units.lib should get some editorial attention. Does anyone know what "british" is supposed to be there for? (d) deep chrome green -- David A. Holland dholl...@netbsd.org
Re: mkdir -p, autoconf
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 execution, it's reasonable to expect > > if (!directory_exists()) > make_it() > > and a possible returned error if it doesn't exist but then creation > fails. I think it's a crock that autoconf suddenly cares about this after how many non-MAKE_JOBS_SAFE automake-generated makefiles we've had to deal with. And just how do they attempt to check? Anyway, it takes about fifteen seconds with mkdir.c to ascertain that this isn't a problem. -- David A. Holland dholl...@netbsd.org
Re: alloca again
On Tue, Oct 04, 2022 at 12:41:07AM +0300, Valery Ushakov wrote: > On Mon, Oct 03, 2022 at 18:32:47 +0000, 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) && \ > > > > Note that the part you didn't quote is > >defined(__GNUC__) && __GNUC__ < 2 > > and all it does is change the argument type to int from size_t. > > > > This makes it highly unlikely that it ever failed, for an assortment > > of reasons, not the least of which is that we removed critical parts > > of gcc2 support from /usr/include years ago so it's not been exercised > > in at least that long. > > ITYM gcc1? Note "less than" in __GNUC__ < 2 Oops! Yeah. Was gcc1 still in use even in 1993? I can't remember. -- David A. Holland dholl...@netbsd.org
Re: alloca again
On Mon, Oct 03, 2022 at 02:20:20PM -0400, Mouse wrote: > >>> #if defined(_NETBSD_SOURCE) > >>> #if defined(alloca) && (alloca == __builtin_alloca) && \ > >> [...] > > _NETBSD_SOURCE and __builtin_alloca are each in reserved-for-any-use > > namespace, so there are no grounds for citing the standard as basis > > for any behaviour whatsoever from that. > > I think I overstated the case. Those two _are_ reserved, but I think > testing them in the preprocessor like that does not produce undefined > behaviour. (Quotes below.) > > I think it would be conformant for __builtin_alloca to expand to, for > example, the four tokens & < % 14. Presumably this would be done only > when the compiler in question accepts that, but even then I think there > is no requirement that compiler accept that as part of a *preprocessor* > expression. > > Of course, this is not to say that the test quoted is a bad thing, only > that it is nonportable - but nonportability is not necessarily a bad > thing in implementation-specific places (such as system headers). It > *does*, however, mean that citing the standard as basis for expecting > any particular behaviour is unjustified. I think it is reasonably plausible to do the following: - provide a "weak" macro definition of alloca -> __builtin_alloca (such that another #define implicitly removes it); - handle equality tests of identifiers beginning with __builtin with strcmp. The former is not compliant, but unlikely to cause trouble unless someone used the name "alloca" expecting it to be an ordinary identifier and not a libc element, and without including ; and in 1993 when this thing was inserted the likely reaction to such trouble would be "don't do that". The latter seems to be perfectly legitimate since it's equivalent to predefining a bunch of things in the reserved namespace to magic token sequences. I can't remember exactly how builtins worked in gcc2 but I have a vague recollection it may have been something like this. Also remember that in 1993 there realistically wasn't another compiler. If we still cared about gcc2 it might be better to put that part of the test first in the expression so the rest isn't evaluated in other compilers, but we don't. -- David A. Holland dholl...@netbsd.org
Re: alloca again
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) && \ > > According to my knowledge of the C preprocessor, the condition 'alloca > == __builtin_alloca' always evaluates to '0 == 0', assuming that if > 'alloca' and '__builtin_alloca' are actually defined, they expand to > some other identifier. As C90 6.8.1 and C99 6.10.1p4 both say, "all > remaining identifiers are replaced with the pp-number 0." > > Did this condition make any sense at any time in the last 40 years? If > not, why has this piece of clearly broken code survived since 1993-03-25? Note that the part you didn't quote is defined(__GNUC__) && __GNUC__ < 2 and all it does is change the argument type to int from size_t. This makes it highly unlikely that it ever failed, for an assortment of reasons, not the least of which is that we removed critical parts of gcc2 support from /usr/include years ago so it's not been exercised in at least that long. As for why nobody ever noticed, I'm sure many people have looked at it and said to themselves "alloca is magic, I'm sure it's that way for a reason" and not thought about it further. And as Mouse pointed out, it's definitely possible that it behaves as intended in gcc2's preprocessor. gcc's handling of builtins in those days was a lot dodgier than it is now. Anyway, the gcc2 part can definitely be removed at this point. -- David A. Holland dholl...@netbsd.org
Re: alloca again
On Mon, Oct 03, 2022 at 09:33:47AM -0400, Mouse 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. > >> I'd argue that alloca should never be used and actually should never > >> have existed. As far as I can see it does nothing that can't be > >> done better - more portably and correctly - by variable-sized > >> arrays. Am I missing something? > > I look forward to you fixing every piece of third-party code using it > > in the wild. :) > > That sounds like a "no" to my question (which was independent of what > does or doesn't try to use alloca). Is it? > > I don't see any reason I should be responsible for fixing other > people's nonportable code. (Nor, for that matter, do I see any reason > NetBSD should be responsible for supporting their choices of > nonportabilities. I consider code that uses alloca() to be on a par > with code that uses, say, SCM_SECURITY ancillary data, sys$crmpsc(), or > #pragma aux: it's choosing to use a nonportable feature.) > > Would you have reacted the same if I'd argued against support for, say, > the routines typically declared by ? Why or why not? If you propose to remove something, and thereby break code that previously worked, you also need to propose to deal with those consequences. We don't have a compat layer; we do have alloca, and since alloca has historically existed in Unix for a long time there is a fair amount of old software that uses it. If you would like to contribute to an effort to fumigate pkgsrc for alloca uses, please go ahead. We have fairly successfully killed off other dead interfaces (e.g. union wait, ) and it's mostly a matter of being willing to run the test builds and patch the failures. However, iirc you won't touch pkgsrc for some reason :-p Also, depending on how you interpret the interaction of alloca and the C standard, the aliasing rules may preclude using variable-length arrays as a general replacement. That is, it's reasonable to interpret it as being like malloc and returning untyped memory, whereas any array you declare is automatically typed. -- David A. Holland dholl...@netbsd.org
Re: sh(1) and ksh(1) default PATH
On Tue, Aug 16, 2022 at 08:59:13AM +0200, tlaro...@polynum.com wrote: > But the argument "if something is modified, that"s the problem of the > user" can be reversed: NetBSD provides utilities whose > functionnalities it relies upon. So, by default, the system should use > its utilities, the ones it has been tested with and expects. So base > should always come first by default; user can modify this but in this > case, he is on is own. The system is provided without anything in > /usr/local/ so placing something in /usr/local is modifying the > system. So for the core to still function, it has to be designed to > ignore whatever is in /usr/local for its core functionnalities. Except that the whole reason for installing e.g. bind or sendmail from pkgsrc is to replace the corresponding functionality in base. -- David A. Holland dholl...@netbsd.org
Re: sh(1) and ksh(1) default PATH
On Tue, Aug 16, 2022 at 02:03:49AM +0700, Robert Elz wrote: > So, for example if the shell were to not start with line editing > enabled (to borrow from one of the recent issues) a moron user > with complain about how useless it is, and moan a lot, and that's > about it. A user who is merely inexperienced will wonder why > that is, and perhaps decide to have a look in the documentation for > the shell, which will tell them that "set -E" (or set -o emacs) or > set -V (or set -o vi) will enable it. Then they'd try that, and > discover that it does work. Next would be how to make that happen > automatically, so back to the man page to learn about the startup > scripts that the shell runs. An inexperienced user has no basis upon which to make any such conjectures. There's no rational reason to suppose line editing exists but is disabled by default for some unfathomable reason; the logical conclusion is that if it doesn't work, it's not supported. And then they tell a thousand of their facebook friends that NetBSD sucks. That is only a reasonable line of thinking for a user who already knows enough about Unix and NetBSD to realize that (a) this feature is thirty-odd years old and they entitled to expect it; (b) NetBSD is not thirty years "behind"; and (c) in 2022 NetBSD still ships with some assembly required and it's expected to have to tinker with the config to get acceptable results. > There's a proverb something about giving a fish vs teaching fishing that > is probably relevant here. Are you really suggesting that the default config should be broken to force people to learn how to change it? -- David A. Holland dholl...@netbsd.org
Re: sh(1) and ksh(1) default PATH
On Mon, Aug 15, 2022 at 04:36:13PM +0700, Robert Elz wrote:
> Date:Sun, 14 Aug 2022 21:41:08 +
> From: David Holland
> Message-ID:
>
> | There's another wrinkle, which is that /usr/local and /usr/pkg should
> | come before /usr... except that this point is apparently contentious
> | and has been bikeshedded to death in the past with no consensus
> | reached.
>
> Aside from the issue you address there, there's also the question of
> which of /usr/local{/bin,...} and /usr/pkg{/bin,...} should come first.
>
> That one is ever harder to make any general decision upon.
Not really; the same principle applies. Same with ~/bin, for that
matter, though adding that by default isn't traditional.
> Those kinds of users need to be able to discover where they can set PATH
> so that it works for their needs - and encouraged to do that, not told
> "this way is the right way".
Sure. But also, in the common case, they shouldn't have to learn the
hard way that the default does not suit their needs.
It's easy to ignore these problems because you and I (and probably
most netbsd users) have session configs they've been carrying around
since the 90s or longer. However, the days where someone in the
terminal room would tell you to get started by copying ~kre/.profile
are gone for good, and furthermore we no longer in general accept
vendor-Unix-quality software deliveries. The default session needs to
function well enough for new users to get to the point where they can
figure out how to adjust it on their own. This is true regardless of
whether they're users we approve of or not.
I don't think we disagree on that, but we seem to disagree on what it
entails; for example, I don't think it's acceptable to have to type
out "/usr/X11R7/bin/startx" in longhand because whatever copy of the
default path actually took effect doesn't have X in it.
A good first step would be to hunt down all the path strings scattered
all over everywhere and fix things so that even if they have to appear
in more than one place in the installed system, there's only one copy
in the source tree.
> And then 10 minutes later dholland-t...@netbsd.org also said:
>
> [stuff about dropping X tools from the path when X isn't running]
As I said, it's a nice idea, in a way, but it doesn't actually work
and isn't practical. Also, it ends up being confusing: "I thought I
installed xyz; why is it telling me it's not found?"
--
David A. Holland
dholl...@netbsd.org
Re: sh(1) and ksh(1) default PATH
On Mon, Aug 15, 2022 at 10:50:39AM +0200, Hauke Fath wrote:
> > Argument 2:
> > the stuff in base is canonical and it's wrong for random whatnot to
> > arbitrarily override it. I admit I don't fully understand argument 2 [...]
>
> To give an arbitrary example: I had ${PREFIX}/{s,}bin first in PATH at
> one point. A Kerberos pkgsrc package installed a su(1), which for
> whatever reason didn't work (I don't use Kerberos).
>
> Until pkgsrc prefixes any tools that duplicate base tools, or we grow a
> viable alternatives system, that will remain a problem. And I am not
> sure the above cures are any better than the problem.
pkgsrc should not install stuff that duplicates/replaces/overrides
base tools unless you asked it to. That part I fully agree on.
(That particular bug got fixed in heimdal at least fifteen years ago.)
--
David A. Holland
dholl...@netbsd.org
Re: Relative interpreter pathname on #! line
On Wed, Aug 17, 2022 at 08:29:48AM -0400, Mouse wrote: > > Is [#! taking a relative interpreter path] intentional? > > > What's more, the relative interpreter filename is taken relative to > > the current directory, not relative to the script directory. > > That's exactly what I'd expect, and what I'd say should happen: it's > consistent with ~every other use of relative pathnames. > > > There's probably some logic to this but it seems bug-prone and I > > can't think of a legitimate use for it. > > I can't offhand either, but I also don't see any real risk from it, and > am very far from certain there is no clever use for it. There is a slight risk if you have untrustworthy users and you run one of these things (perhaps by accident) while in /tmp. However, it would be substantially more useful if relative paths were interpreted relative to the location of the script file. I would have to look in the exec code to be sure, but I don't think that would be hard to arrange. -- David A. Holland dholl...@netbsd.org
Re: sh(1) and ksh(1) default PATH
On Mon, Aug 15, 2022 at 08:28:28AM +0200, tlaro...@polynum.com wrote: > > (If there are no bins with duplicate names, it doesn't matter. If > > there are, it does. Argument 1: the point of installing something in > > /usr/local or /usr/pkg that's also in base is to replace the version > > in base, not for it to be inaccessible to ordinary use. Argument 2: > > the stuff in base is canonical and it's wrong for random whatnot to > > arbitrarily override it. I admit I don't fully understand argument 2 > > and I suspect it may partly be a leftover response dating from System > > V installs with world-writable /usr/local.) > > Argument 2.1: permissions on /usr/local may be relaxed and malicious > software could more easily install devious utilities there to precisely > override safer versions in base. So by default, base version should take > precedence. Except that if you do that you have deliberately misconfigured your system. I don't think there's any reason the default setup should cater to this kind of inherently unsafe environment. -- David A. Holland dholl...@netbsd.org
Re: sh(1) and ksh(1) default PATH
On Sun, Aug 14, 2022 at 09:13:23AM +0700, Robert Elz wrote: > It is also certainly wrong to add /usr/X11R7/bin to $PATH unless the > user is actually in an X environment, that ought be added in the X11 > startup scripts, not in the shell, or in user.cs_path A profile > file can check if DISPLAY is set, doing that in the shell isn't appropriate. That's a nice idea, in a way, but: (1) startx is in there, so if you don't already have it in the path you will find starting X a nuisance if you have logged in on the console (which I think is not uncommon); (2) it's not common but far from unheard-of to log in somewhere without a DISPLAY and then start X programs on some otherwise existing display. (Examples of this being useful include (a) starting a new window manager if the original one has cored and left you without window focus; (b) starting xlock remotely when you accidentally went home without locking your session; (c) screendumping or otherwise salvaging what you were doing when PR 44712 strikes and you can't switch back to your display.) Granted, if you know enough about what you're doing to do this, having /usr/X11R7/bin not in the PATH is only an annoyance, but it's highly irritating. (3) it is entirely moot if you installed X from pkgsrc, in which case all the X bins are on the path (or not) regardless. (4) it's far from the case that the only things that require an X display live in /usr/X11R7/bin. So I think it's an unnecessary complication to worry about this issue. -- David A. Holland dholl...@netbsd.org
Re: sh(1) and ksh(1) default PATH
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. > [...] There's another wrinkle, which is that /usr/local and /usr/pkg should come before /usr... except that this point is apparently contentious and has been bikeshedded to death in the past with no consensus reached. (If there are no bins with duplicate names, it doesn't matter. If there are, it does. Argument 1: the point of installing something in /usr/local or /usr/pkg that's also in base is to replace the version in base, not for it to be inaccessible to ordinary use. Argument 2: the stuff in base is canonical and it's wrong for random whatnot to arbitrarily override it. I admit I don't fully understand argument 2 and I suspect it may partly be a leftover response dating from System V installs with world-writable /usr/local.) But if we're going to paste new copies of the default path into more places we should really try to straighten this out first, or have a setting for the order somewhere. There's already too many copies as it is, and they aren't all the same. The one in etc/login.conf is missing /usr/local/sbin, for example. I am not clear on why has both _PATH_DEFPATH and _PATH_STDPATH and why they're different (one potentially has RESCUEDIR in it, whatever that is, and the other has sbin dirs; and neither has /usr/X11R7/bin) but probably that should be clarified and then all the others derived directly from there rather than repasted. (Also, being a system header, paths.h shouldn't be trafficking in symbols like RESCUEDIR that belong to the application namespace. I am guessing that RESCUEDIR is sometimes set to /rescue? This should get sanitized.) -- David A. Holland dholl...@netbsd.org
Re: disable HPN in sshd for the -10 branch?
On Tue, May 24, 2022 at 06:57:23AM -, Michael van Elst wrote: > >(1) having an unencrypted option at all is one of the ways spooks like > >to weaken cryptosystems; it creates ways to force/cause people to use > >it when they didn't mean to. > > People have to be very clear in making that choice and they actually > use it for a reason. > > Consider the alternatives that are much weaker and don't protect > anything at all. > > Or consider the alternative to create separate tools that satisfy > the requirements that the HPN patch was created for. Will that be > better? It is better, yes, because it's much harder to engage an entirely different tool by trickery. > Also consider that people believe their data is safe in the current > virtualized world, just because someone calls "encryption". True, but that's not a reason to make the situation worse. > >(2) if you don't encrypt everything, you're telling anyone who's > >listening which data's important. > > Gung znxrf lbhe choyvpnyyl fgngrq bcvavba abg vzcbegnag? V qba'g xabj nobhg lbh, ohg V cbfgrq vg bire na rapelcgrq frffvba, naq gurfr qnlf n ybg bs gur genafcbeg vf rapelcgrq gbb. -- David A. Holland dholl...@netbsd.org
Re: disable HPN in sshd for the -10 branch?
On Mon, May 23, 2022 at 05:30:36PM -0700, John Nemeth wrote: > } I would say that doesn't really fit with what we want either, certainly > } without somebody really trying. It breaks the rule that using ssh can > } count on confidentiality and integrity and makes systems with ssh as a > } component harder to reason about. > > I would say it is something that should be available as an > option (likely a command line option). ssh/scp has pretty much > completely replaced rsh/rcp (other than for people that go out of > their way to use those); however, there are many things that get > copied around that are completely public where encrypting them for > data transfer is useless overhead. That said you likely still want > passwords encrypted and integrity checks. (1) having an unencrypted option at all is one of the ways spooks like to weaken cryptosystems; it creates ways to force/cause people to use it when they didn't mean to. (2) if you don't encrypt everything, you're telling anyone who's listening which data's important. IOW, I disagree entirely. -- David A. Holland dholl...@netbsd.org
Re: usefulness of lint (was: Re: Proposal: remove usr.bin/mkstr)
On Sun, Apr 10, 2022 at 01:13:26AM +0200, Roland Illig wrote: > > We should not remove lint until we have another program checker to > > replace it with, but it is not itself very useful. And yes, I know > > you've been working on it and I haven't been following the details, > > but it will take far more than the time you've put in (and a ground-up > > restructuring) to become even as useful as lclint or sparse, let alone > > comparable to a state-of-the-art program checker. > > Could you go into the details of what you mean by "ground-up"? The basic > concepts and data types (expression, type, symbol, operator) look > sensible to me. Sure, the memory management is hard to understand at > first, I'm preparing a README file for that. When I looked it over in detail (some years back now) the internal representation seemed entirely inadequate for doing more sophisticated analyses and handling their results. It was far enough back that I don't remember any details, just that I concluded that it didn't seem worth spending time on. But anyway, to do complicated analyses and then track the results you need an intermediate representation you can iterate over easily and also one that you can extend to hold additional discovered information. Looking at lint1.h it still does not seem suitable at all. For one thing it's too close to the concrete syntax; for example, it has type specifiers in it instead of just types. For another thing, declarations don't seem to have statements in them (!?) so it isn't complete in some fashion and/or is limited to handling one a function at a time. (While the latter isn't the end of the world, it means you can't propagate information between functions in the same translation unit unless they appear in the right order, which is a significant limitation.) And it isn't... how shall I say... sturdy. You want a robust framework you can store a lot of arbitrary information in. If you start stuffing large amounts of dataflow results, or extra type annotations in more expressive type systems that you're using to carry extra information (e.g. allowing functions to be polymorphic in const as I mentioned before), or tracking ranges or impossible values or other stuff like that, it will become a mess. None of this is unreasonable; it was never intended to handle the kinds of analysis I'm thinking of and wasn't written with the possibility in mind. But, all the same, it wasn't. Back then (whenever it was) my conclusion was that hacking it up was probably considerably more expensive than starting over; now that you've fixed up some of the more glaring problems that might be less true (that is, the infrastructure that one might salvage at least works now), but it's still a huge job. > > It used to be that lint did not do this in a useful way (via > > quantifier polymorphism) -- have you improved it? > > Yes, but not in a general way. I just listed the few affected functions > explicitly. See > https://nxr.netbsd.org/search?q=%22effectively+discards%22 for the > implementation, the test msg_346.c contains a few examples. Right. I was talking about doing it in a general way :-) (To do that what you basically want is abstract interpretation over the domain "is const", "is not const", "can be either", and "don't know"; and then in support of that you want your types to be able to express functions where the return constness is covariant in one of the args's constness. And then to do the analogous thing with volatile, though since volatile's a lot less common it's less interesting.) > > I tried to check but running lint on a test file spews fatal errors > > trying to read the system headers. If one adds -Ac11 and > > -D'__attribute__(x)=' to avoid these, it does not complain about your > > example, let alone any other more complex ones. > > Oh, I can see how lint's default settings result in a bad first-time > experience. Ideally, lint should just work out of the box, without even > having to read the manual. The minimal lint flags to make it usable are > currently -g for GCC mode and -S for C99 mode. That's what I use in the > unit tests as well. I'll try to improve the default settings to be more > user-friendly. Yeah, the alphabet soup of options is hard to wade through too. With -g -S it runs but doesn't complain on your example (or one where the first arg is explicitly const char *, either) -- I assume that there's some other flag that needs to be set to enable the warning, but the only thing I see in the man page is an option for _disabling_ warnings by number. :-| Might be nice to add an EXAMPLES section in the man page :-| -- David A. Holland dholl...@netbsd.org
Re: Proposal: remove usr.bin/mkstr
On Sat, Apr 09, 2022 at 03:16:24PM +0200, Roland Illig wrote:
> > That's just like lint - once used all the time, code was not accepted
> > if not lint free, now essentially useless as tge compilers have most
> > of its functionality built in. If being old and no longer very useful
> > is the test, then lint should go too. Perhaps so should I.
>
> Do you know of any C compiler that [...]
We should not remove lint until we have another program checker to
replace it with, but it is not itself very useful. And yes, I know
you've been working on it and I haven't been following the details,
but it will take far more than the time you've put in (and a ground-up
restructuring) to become even as useful as lclint or sparse, let alone
comparable to a state-of-the-art program checker.
> Do you know of any C compiler that catches the implicit unconst cast in
> strstr("literal", "lit")[0] = 'X'?
It used to be that lint did not do this in a useful way (via
quantifier polymorphism) -- have you improved it?
I tried to check but running lint on a test file spews fatal errors
trying to read the system headers. If one adds -Ac11 and
-D'__attribute__(x)=' to avoid these, it does not complain about your
example, let alone any other more complex ones.
--
David A. Holland
dholl...@netbsd.org
Re: rc of built-in printf
On Wed, Mar 16, 2022 at 07:00:12AM +0700, Robert Elz wrote: > This issue was brought up on the austin-group list (POSIX) by > some doing testing in linux, with output from commands being sent > to /dev/full (yes, a special file whose only purpose, as far as > I can tell, is to return ENOSPC to any write request). Yes, that's what /dev/full is for. It's surprisingly useful for testing, especially in a world where full disks rarely happen but silent data corruption when it does happen isn't really acceptable. Though with one thing and another a very small tmpfs is probably more useful today. > Anyway, in the next version, POSIX is planning on making it mandatory > for lots of commands to check for write errors on stdout, and if found > exit with a status indicating an error (which also mandates a message > on stderr from almost all utilities). > > I don't much like this, but my arguments fell on deaf ears, so despite > my misgivings, in current, both versions of both echo and printf (the > builtin ones in /bin/sh and the ones in the filesystem) do check for > errors and report them (and exit non-zero) if they happen. > > None of the many other utilities (built into sh, and otherwise) has been > changed, except I think maybe the built-in pwd in sh (not sure if I did > that one or not now) - pwd received a lot of attention because pwd was > the command which (pwd >/dev/full) which started all of this. Reporting ENOSPC (or EDQUOT) and such seems like a considerably different mission from reporting EPIPE, which is noise... but it also wouldn't surprise me to hear that they missed this point. :-| -- David A. Holland dholl...@netbsd.org
Re: possible bug in fseek of buffered files shared between processes (example uses stdin)
On Tue, Nov 02, 2021 at 04:54:58PM -0700, Carlo Arenas wrote: > Note that the way the wording is done in that paragraph, it might seem > to imply that the position is a property of the file and not of the > FILE, so you could have more than one FILE pointing to the same fd, > and any fseek on it should be visible to them all. That's a preposterous interpretation, though, because it would prohibit buffering in stdio and that's the whole point of stdio. Anyway, I don't see it, because C itself has no notion of files, let alone other processes. There are only FILEs. -- David A. Holland dholl...@netbsd.org
Re: openssl 3
On Sun, Oct 03, 2021 at 06:30:36PM -0400, Greg Troxel wrote: > > On Fri, Oct 01, 2021 at 07:54:18PM -0400, Greg Troxel wrote: > > > So, if it happens that way, then it really does not matter from the > > > NetBSD side if pkgsrc moves to 3 this branch, or adds 3 as an option > > > alongside 1.1.1, or doesn't do either. But, as you switch things, it > > > will be good for pkgsrc to be able to use the native 3 and have other > > > packages build against it. > > > > Yes and no; what are the odds that if both are installed (because > > something in pkgsrc wants 3 and base doesn't have it yet) that > > everything will actually work? bl3 will help with this, but only so > > much... > > I see your point, but this is exactly what was happening earlier on I > think 8 (maybe 7) that had openssl 1.0.x when pkgsrc had 1.1. It mostly > worked. True. That didn't become mandatory for some time, but I guess the same will probably be true this go. (I thought of another issue, but it belongs in the pkgsrc thread) -- David A. Holland dholl...@netbsd.org
Re: openssl 3
On Fri, Oct 01, 2021 at 07:54:18PM -0400, Greg Troxel wrote: > So, if it happens that way, then it really does not matter from the > NetBSD side if pkgsrc moves to 3 this branch, or adds 3 as an option > alongside 1.1.1, or doesn't do either. But, as you switch things, it > will be good for pkgsrc to be able to use the native 3 and have other > packages build against it. Yes and no; what are the odds that if both are installed (because something in pkgsrc wants 3 and base doesn't have it yet) that everything will actually work? bl3 will help with this, but only so much... -- David A. Holland dholl...@netbsd.org
Re: Anyone still using YP support on NetBSD?
On Thu, Sep 23, 2021 at 02:06:51PM -0700, Jason Thorpe wrote: > Anyone? Not any more, but I think I'm among the more recent people to have hacked it, because I used to until not that far back. -- David A. Holland dholl...@netbsd.org
Re: test a -nt b if b doesn't exist
On Fri, Aug 27, 2021 at 05:49:06PM +0200, Edgar Fu? wrote: > > But since no portable script can really use -nt (as it isn't standardised) > > I'm not sure that this is all that important. > > It's a pity it's not stadardised, but if different shells behave > differently, there's little chance it ever will be, no? Nah, what happens then is waffling, probably with the result that the behavior is unspecified if either file doesn't exist. (me, I think it should be an error. you can always write [ ! -f Y ] || [ X -nt Y ].) > [...] the only workaround I could think of is parsing two ls -l outputs. ...which you can't do anyway because of locales (even in practice, because last I remember linux's en_US locales arbitrarily change ls -l output for no reason.) -- David A. Holland dholl...@netbsd.org
Re: draft mcount(3) man page
On Fri, May 21, 2021 at 05:29:30PM -0700, Jason Thorpe wrote: > This looks awesome, David, thanks for writing it! :-) > Might it be worth noting some of the historical legacy symbol > naming issues that were are the root of the bug report we were just > talking about a little while ago? After investigation I don't think that's actually true: the name in MCOUNT_DECL is a C name, so in a.out days if given as "mcount" would have come out as "_mcount" and still be in the user namespace. The name of the assembly function is not necessarily, but that's _mcount on alpha. Now, anyway; was probably different originally as having the same obviously would never have worked. (context for passersby: PR 10582) To cut down on future confusion we should probably (if it's not excessively expensive for some reason) change all the compiler configs to call "__mcount_hook" and change the name of the C function to always be "__mcount_impl" or "__mcount_backend" or something like that. Having both _mcount and __mcount is terrible, especially when their roles are exchanged on ~half the ports we have. (Since profiling binaries are static and these functions aren't user-facing there's no compatibility issues with changing them.) -- David A. Holland dholl...@netbsd.org
draft mcount(3) man page
The workings of the various *mcount functions are confusing and currently undocumented. After wading into it just now for I think the third time recently, I wrote the following to ease the process. Comments? -- .\" .\" Copyright (c) 2021 The NetBSD Foundation, Inc. .\" All rights reserved. .\" .\" This code is derived from software contributed to The NetBSD Foundation .\" by David A. Holland. .\" .\" Redistribution and use in source and binary forms, with or without .\" modification, are permitted provided that the following conditions .\" are met: .\" 1. Redistributions of source code must retain the above copyright .\"notice, this list of conditions and the following disclaimer. .\" 2. Redistributions in binary form must reproduce the above copyright .\"notice, this list of conditions and the following disclaimer in the .\"documentation and/or other materials provided with the distribution. .\" .\" THIS SOFTWARE IS PROVIDED BY THE NETBSD FOUNDATION, INC. AND CONTRIBUTORS .\" ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED .\" TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR .\" PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE FOUNDATION OR CONTRIBUTORS .\" BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR .\" CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF .\" SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS .\" INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN .\" CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) .\" ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE .\" POSSIBILITY OF SUCH DAMAGE. .\" .Dd May 21, 2021 .Dt MCOUNT 3 .Os .Sh NAME .Nm mcount , .Nm _mcount , .Nm __mcount .Nd profiling hooks .Sh LIBRARY .Lb libc .Sh SYNOPSIS .Fn _mcount "/* asmlinkage */" .Fn __mcount "u_long frompc" "u_long selfpc" .Sh DESCRIPTION The .Fl pg option to .Xr cc 1 causes the compiler to insert calls to a profiling hook at the entry to each function it compiles. This allows code in the standard library to collect call graph information. .Pp The compiler inserts a call to .Fn _mcount , typically written in assembler, which is responsible for saving registers and calling .Fn __mcount . .Pp Note however that on some targets, e.g. vax, these names are reversed. The name of what this manual page refers to as .Fn _mcount is determined by the compiler, and the name of what this manual page refers to as .Fn __mcount is determined by the macro .Dv MCOUNT_DECL in .In machine/profile.h (q.v.). .Pp The .Ar frompc argument to .Nm __mcount is the address the call came from, that is, the original return address; the .Ar selfpc argument is the address of the callee, normally expressed as the return address of the call to .Nm _mcount . Note that .Nm _mcount itself does not have arguments in the normal sense; it receives stack and register contents consistent with the call location inserted by the compiler, which is usually at the beginning of the original function but may vary by target. It is responsibile for extracting the arguments to .Nm __mcount from that state, in addition to preserving register contents as needed. .Pp The code for .Nm _mcount is on some machines contained in the macro .Dv MCOUNT in .In machine/profile.h , and on others in its own source file. In the former case, .Nm __mcount can be and often is declared static. .Sh RETURN VALUES None. .Sh RESTRICTIONS Both .Nm _mcount and .Nm __mcount are internal interfaces and must not be called directly by application code. The symbols are not even guaranteed to exist unless the .Fl pg option was given to .Xr cc 1 . This manual page is provided to document the internal workings for developers who need to adjust them. -- -- David A. Holland dholl...@netbsd.org
Re: Inetd Enhancements - Include Directive
On Mon, Apr 05, 2021 at 10:39:52AM -0700, James Browning wrote: > [...] our current plan is to implement it with the following syntax: > > !include The reason to favor .include is that lots of other syntaxes use . for directives, and most people's instinctive interpretation of ! (if any) is a shell escape. it is not a big deal though. > Our current plan is to simply implement a max recursion depth, so > that inetd will quit if the number of files included exceeds that > depth. If you count the depth rather than the total number of files (that is, decrement when you finish each file), you don't need a large depth; a limit of 4-8 is ample and will still stop mistakes rapidly. (in fact, more than 1 is unlikely to ever be necessary) -- David A. Holland dholl...@netbsd.org
Re: Q about pthread condition variable usage - mixing interlocks
On Thu, Apr 08, 2021 at 10:47:09AM -0700, Jason Thorpe wrote: > Is there ANY situation where, for a given pthread condition > variable, that using a different mutex as the interlock in two > different calls to pthread_cond_wait() would EVER be legitimate > usage? I cannot come up with any scenario in which this would be > appropriate, but who knows what some crazy applications might do. It is not a reasonable thing to do and there's no scenario I know of where it makes sense. That mutex had better protect the state that expresses the condition the CV is associated with, or things don't work. > POSIX for whatever dumb reason allows pthread_cond_signal() / > pthread_cond_broadcast() without holding the interlock, but at > least there?s explicit language about this in the spec (and > thankfully the language contains a mild finger-wag about it). For implementations with Mesa semantics (though not Hoare semantics) this is a reasonable thing to do, e.g. to avoid holding a heavily contended mutex for any longer than absolutely necessary. Since wakeups are only advisory, it doesn't matter if you unlock first and thereby allow the state to change before the wakeup goes through. Allowing it excludes some implementation strategies though, because it means you can't rely in on the mutex to protect the CV's internal state. -- David A. Holland dholl...@netbsd.org
Re: magic unmbers in rmt protocol
On Wed, Mar 17, 2021 at 07:26:13PM +, David Holland wrote: > Question: should the defines go in a new or is that > overkill? Right now they're pasted in both programs, which is not > ideal but not a huge issue either. Another question: is O_APPEND useful? Does it work to concat dump files? I can't remember and being able to write them to tape one after another isn't the same. -- David A. Holland dholl...@netbsd.org
magic unmbers in rmt protocol
It came up in chat today that dump/rmt uses hardcoded integer values
that are then passed as the flags argument of open. This is wrong for
several reasons.
The following patch corrects it. The rmt part is untested (don't have
a suitable setup to test it with) -- if someone who uses rmt could
check it out that would be helpful.
Based on discussion with mrg, the rmt patch accepts a bunch of open
flags that dump doesn't send, because it's apparently useful to be
able to use rmt to dump to remote regular files with a suitably
patched dump. Getting the latter written and committed is for some
future time :-)
Question: should the defines go in a new or is that
overkill? Right now they're pasted in both programs, which is not
ideal but not a huge issue either.
Index: usr.sbin/rmt/rmt.c
===
RCS file: /cvsroot/src/usr.sbin/rmt/rmt.c,v
retrieving revision 1.17
diff -u -p -r1.17 rmt.c
--- usr.sbin/rmt/rmt.c 23 Jan 2018 21:06:25 - 1.17
+++ usr.sbin/rmt/rmt.c 17 Mar 2021 19:18:13 -
@@ -59,6 +59,25 @@ __RCSID("$NetBSD: rmt.c,v 1.17 2018/01/2
#include
#include
+/*
+ * The wire protocol uses integer literals for the open mode,
+ * corresponding to the traditional O_RDONLY and O_RDWR values.
+ * Traditional dump sends only either O_RDONLY or O_RDWR, but
+ * since it's useful to use rmt to dump to remote regular files
+ * we also allow some other flags, using the NetBSD values
+ * (which are likely the historical ones, but I'm not sure).
+ */
+#define RMT_O_RDONLY 0
+#define RMT_O_RDWR 2
+#define RMT_O_ACCMODE 3
+#define RMT_O_APPEND 8
+#define RMT_O_NOFOLLOW 0x100
+#define RMT_O_CREAT0x200
+#define RMT_O_TRUNC0x400
+#define RMT_O_EXCL 0x800
+#define RMT_O_REGULAR 0x0200
+#define RMT_O_FLAGS0x02000f08
+
inttape = -1;
intmaxrecsize = -1;
@@ -77,6 +96,7 @@ FILE *debug;
char *checkbuf(char *, int);
voiderror(int);
voidgetstring(char *, size_t);
+static int decode_mode(const char *);
int
main(int argc, char *argv[])
@@ -85,6 +105,7 @@ main(int argc, char *argv[])
int rval;
char c;
int n, i, cc;
+ int openflags;
argc--, argv++;
if (argc > 0) {
@@ -106,7 +127,12 @@ top:
getstring(device, sizeof(device));
getstring(mode, sizeof(mode));
DEBUG2("rmtd: O %s %s\n", device, mode);
- tape = open(device, atoi(mode),
+ openflags = decode_mode(mode);
+ if (openflags == -1) {
+ error(EINVAL);
+ goto top;
+ }
+ tape = open(device, openflags,
S_IRUSR|S_IWUSR|S_IRGRP|S_IWGRP|S_IROTH|S_IWOTH);
if (tape < 0)
goto ioerror;
@@ -246,3 +272,49 @@ error(int num)
(void)snprintf(resp, sizeof(resp), "E%d\n%s\n", num, strerror(num));
(void)write(STDOUT_FILENO, resp, strlen(resp));
}
+
+static int
+decode_mode(const char *buf)
+{
+ unsigned val;
+ int ret;
+ char *more;
+
+ errno = 0;
+ val = strtol(buf, , 0);
+ if (errno != 0 || *more != '\0') {
+ return -1;
+ }
+ switch (val & RMT_O_ACCMODE) {
+ case RMT_O_RDONLY:
+ ret = O_RDONLY;
+ break;
+ case RMT_O_RDWR:
+ ret = O_RDWR;
+ break;
+ default:
+ return -1;
+ }
+ if ((val & RMT_O_FLAGS) != val) {
+ return -1;
+ }
+ if (val & RMT_O_APPEND) {
+ ret |= O_APPEND;
+ }
+ if (val & RMT_O_NOFOLLOW) {
+ ret |= O_NOFOLLOW;
+ }
+ if (val & RMT_O_CREAT) {
+ ret |= O_CREAT;
+ }
+ if (val & RMT_O_TRUNC) {
+ ret |= O_TRUNC;
+ }
+ if (val & RMT_O_EXCL) {
+ ret |= O_EXCL;
+ }
+ if (val & RMT_O_REGULAR) {
+ ret |= O_REGULAR;
+ }
+ return ret;
+}
Index: sbin/dump/dump.h
===
RCS file: /cvsroot/src/sbin/dump/dump.h,v
retrieving revision 1.59
diff -u -p -r1.59 dump.h
--- sbin/dump/dump.h3 Dec 2020 08:25:57 - 1.59
+++ sbin/dump/dump.h17 Mar 2021 19:18:14 -
@@ -244,6 +244,8 @@ voidlfs_wrap_go(void);
#endif
/* rdump routines */
+#define RMT_O_RDONLY 0
+#define RMT_O_RDWR 2
#if defined(RDUMP) || defined(RRESTORE)
void rmtclose(void);
intrmthost(const char *);
Index: sbin/dump/tape.c
===
RCS file: /cvsroot/src/sbin/dump/tape.c,v
retrieving revision 1.55
diff -u -p -r1.55 tape.c
--- sbin/dump/tape.c1 Mar 2019 16:42:11 - 1.55
+++ sbin/dump/tape.c17 Mar 2021 19:18:14 -
@@ -391,7 +391,7 @@ trewind(int eject)
#ifdef RDUMP
if (host) {
Re: Summary of man-page formatting
On Tue, Mar 16, 2021 at 04:16:49PM +0100, Reinoud Zandijk wrote: > > > Right, and in my experience it would be completely unsuitable. :) > > > > > > Now, don't get me wrong, I love Lout and and when I need a batch > > > formatter it's what I use unless there are strong overriding reasons. > > > But it's *way* slower than roff or tex (remember, that troff and tex > > > are macro processors, while lout uses a functional language). > > > > If speed is the primary problem it's probably fixable... > > Yeah, who uses rendering a manpage in a tight loop ;) If it runs on > the older machines in a few seconds I don't think its going to be > an issue. And it isn't that slow is it? Again, it's not about man pages. We have mandoc, it works; this thread arose from a discussion of formatting man pages for not-80-columns, which is a different issue entirely. The thing we want a new/different solution for is formatting release notes and miscellaneous documents (and the mostly-nonexistent NetBSD docshelf, which would be nice to have in a viable state) -- for this speed is, though not irrelevant, not a primary concern as it'll be happening on fast build machines in parallel with compilation. What I meant though was: if the problem is that lout has a functional language interpreter in it and that interpreter is slow, it can probably be made faster. However, I took a quick look at the source yesterday and it seems the code comes as 52 source files numbered 01-52, which is not, shall we say, entirely auspicious. :-| -- David A. Holland dholl...@netbsd.org
Re: Summary of man-page formatting
On Sun, Mar 14, 2021 at 07:20:31PM +0100, Anders Magnusson wrote: > Agreed if the goal is to replace groff. > What i was referring to was only the ability to format nroff man pages > containing troff directives, nothing else.? It's really small for that > usage. > The troff part only generates output for the C/A/T 4 typesetter :-) At this point all man pages in pkgsrc either work with mandoc, have been patched, or are so obscure that nobody's noticed. So I don't think there's any point worrying about it. -- David A. Holland dholl...@netbsd.org
Re: Summary of man-page formatting
On Fri, Mar 12, 2021 at 10:54:46AM +0100, Reinoud Zandijk wrote: > > Like with many other problems, the current situation is poor and > > there's also no particularly viable way forward. > > Well, there is lout to consider. Its a selfcontained program > written in C only with no external dependencies and can output in > EPS, PS and PDF next to normal raw text. It supports multi colum, > paragraph split prevention, kerning, references, math layout, > graphics etc. Yeah, this falls under "(3) People go inventory the small number of existing alternatives to roff and tex". It's come up before, nobody has ever seemed particularly enthusiastic. :-| FWIW, pkgsrc says "gnu-gpl-v3", so that won't be super popular either. -- David A. Holland dholl...@netbsd.org
Re: inetd enhancements - config syntax
On Wed, Jan 20, 2021 at 01:37:44AM +0700, Robert Elz wrote: > Date:Mon, 18 Jan 2021 22:15:30 + > From: David Holland > Message-ID: > > | ...and also, for your own and the operator's sanity, skip anything > | else beginning with '.', > > That one is probably reasonable (and also possibly some other odd > character, to give an easy way to "turn off" a file in a directory, > without removing it - and without 'hiding' it using a '.' name). > [...] > But please, no, file name suffixes are a horrible idea, invented to > cope with file systems with either no (rational) directory scheme Basically what you want is to read only files matching some glob that matches the POLA reasonably well, like "*.conf". The reason to have a suffix and only read files with that suffix is that there are lots of ways to get extra files in the directory that the user didn't mean for you to read, and ~98% of the time they won't have the right suffix so filtering by suffix is a good way to skip them and avoid trouble. This doesn't just mean foo.conf~ files left behind by emacs, but also files like foo.conv,v, directories named RCS, and things like that. :-p Without the suffix filtering you just can't have a directory named RCS in there. Alternatively you could put the glob in the include explicitly (that is, "include dir/*.conf" > Devices and pipes, etc, yes, but I thought the idea was to allow recursion > through directory trees. For that just skipping directories isn't the > right approach. What's more being able to do that seems useful to me. I don't think you want to include a whole subtree recursively. I can't think of any tool that does that by default, including these read-a- whole-directory tools meant to be fed by package managers. > | ...also I strongly recommend against having global settings that are > | meant to change around as things are included > > While in general I think I agree with what you mean, I wouldn't write > it like that. What I'd say instead is that anything in an included > file can affect only that file, and other files included below it, > nothing should be exported back to wherever the file was included from. Perhaps. That's at least reasonably sane, but I think in general it's better to design things so you don't need to do that either. E.g. (partially cribbing from Mouse's example) to avoid pasting listen addresses all over the place you might have some syntax like 10.10.10.10: ntalk dgram udp wait nobody:tty /usr/libexec/ntalkd ntalkd finger stream tcp nowait nobody /usr/libexec/fingerd fingerd 20.20.20.20: httpd stream tcp nowait _httpd /usr/libexec/httpd httpd /var/www ftp stream tcp nowait root /usr/libexec/ftpd ftpd -ll where the listen address is a global setting in the config file that changes over time. Making changes to it not escape include files is one way to avoid allowing regrettable things to happen, but something like this also avoids the problem without need for the global variable, plus works better with ipv6: service ntalk type=dgram user=nobody:tty options?= /usr/libexec/ntalkd ntalkd $(options) service finger type=stream user=nobody /usr/libexec/fingerd fingerd service httpd type=stream user=_httpd dir?=/var/www /usr/libexec/httpd httpd $(dir) service ftpd type=stream user=root options?= /usr/libexec/ftpd ftpd $(options) interface inside ipv4=10.10.10.10 ipv6=fe80::... interface outside ipv4=20.20.20.20 ipv6=1234::... enable ntalk listen=inside enable finger listen=inside enable httpd listen=outside enable ftpd listen=outside options=-ll and among other things it also lets you quickly slap down things like enable httpd listen=inside port=8080 dir=/var/www.new for testing purposes. -- David A. Holland dholl...@netbsd.org
Re: inetd enhancements - config syntax
On Fri, Jan 15, 2021 at 05:43:45PM -0800, John Nemeth wrote: > } We like the idea of being able to include files along with > } directories. Our current plan is to implement directories first, > } along with files if time permits us. If we don't have time to > } implement include-a-file, then we will make sure our include-a-directory > } implementation can easily be extended to support fies in the future. > > You should really start by implementing functionality to > include files as that is your base. The way to implement including > directories is to stat the item being included to see if it is a > directory, and if it is, then branch to a routine that will scan > the directory and call the file inclusion routine on each file > found (skipping . and .. of course). ...and also, for your own and the operator's sanity, skip anything else beginning with '.', names that don't end in ".conf" (or ".inetd" or whatever you think the proper suffix should be), and anything that isn't a regular file (DT_REG). (If you get DT_UNKNOWN it's reasonable to call stat to get the real type rather than just skipping it, and you might want to allow symlinks, but definitely skip directories, devices, named pipes, etc.) ...also I strongly recommend against having global settings that are meant to change around as things are included (such that the order includes are processed in matters) -- you wouldn't write code that used global variables that way, don't do it in configs... -- David A. Holland dholl...@netbsd.org
Re: tolower()/islower() and char
On Thu, Jan 14, 2021 at 10:54:45AM -0500, Mouse wrote: > >> [Y]ou just need to choose a value for EOF that is out of range for > >> signed char. > > I recall there being some debate about whether it's actually legal > > for EOF to have any value other than -1. > > Curious. Do you recall the basis for such a position? No, only that I remember seeing a discussion about it, most likely on comp.std.c so most likely not about POSIX, and before C11. I can't find any trace in my own archives, and asking the goog about comp.std.c turns up tons of rubbish about comp.std.c++, and I don't see anything obvious in the standard either. But of course it would only be an interesting proposition for comp.std.c if it weren't obvious :-) Could also be that I'm thinking of something else entirely. So, in the absence of further information, never mind I guess... -- David A. Holland dholl...@netbsd.org
Re: tolower()/islower() and char
On Thu, Jan 14, 2021 at 07:46:01AM -0500, Mouse wrote: > > The standard is explicit that the argument must be EOF or an unsigned > > char. There is no way to support both true 8bit locales and > > magically fix this. > > No way for ctype.h to do so independent of the rest of the system. But > it's not at all hard to fix it from a libc design perspective; you just > need to choose a value for EOF that is out of range for signed char. I recall there being some debate about whether it's actually legal for EOF to have any value other than -1. FWIW. -- David A. Holland dholl...@netbsd.org
Re: Convention in the output of service rcvar
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. -- David A. Holland dholl...@netbsd.org
Re: POSIX proposal: make and "pattern matching" rules
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 that has been issued since 2011. Blaah. I'll try to pull together some kind of posting. as you might expect, I'm against it because, although suffix rules are wholly inadequate, gmake pattern rules are only slightly better and are still inadequate for a number of common uses. (and that's without allowing the %'s to match slashes, which is a nice big can of worms in its own right) -- David A. Holland dholl...@netbsd.org
Re: inetd Enhancements
On Sat, Nov 21, 2020 at 08:24:56PM -0800, James Browning wrote: > 2. To inquire about the ideal way to implement per-service > configuration files in inetd. Please see the other post I just wrote, even though it's somewhat deep in the thread. (You don't necessarily need to read the rest of that branch of the thread first.) Per-service configuration files are a mistake. As the project definition partly says, what you want are per-service _service definitions_ and a single master config file that turns services on and off. (And, perhaps, allows setting command-line flags, though that's somewhat of a can of worms.) This seems to have migrated to "nice to have" but is really essential for doing this correctly. The other post explains in substantially more detail. > In addition we are considering also changing the syntax of the > inetd configuration file to be cleaner and easier to read > (something more in line with what xinetd does). We would like to > know if this change would be worth it at the cost of users > potentially needing to change their inetd config files to conform > to the new format. You need to extend it, not change it. The current syntax has been extended well past its elastic limit, so what this means in practice is: continue to accept the old syntax but also accept files that begin with "syntax v2" or "inetd.conf v2" or some other magic sequence that isn't easily confused with a valid traditional inetd.conf line, and are read with a different parser and have a completely different syntax. IIRC at one point there was a suggestion to use "#@" (by analogy to "#!") for these markings but that may not be a good idea. Don't follow xinetd blindly; there's nothing especially good about its syntax and it doesn't have the service definition vs. configuration decomposition. > per-service rate limiting. This is also configuration, not part of the service definition, so it doesn't belong in the service definition files. (Though a service definition might want to come with a default set of rate limiting settings.) As other people have noted, the rate limiting is already at least somewhat per-service and has been since at least 4.3BSD. I can't remember how that clause got into the project description in its current form; it's probably edit sausage. My recollection is that the goal was to make the rate limiting more flexible than it currently is, but I don't remember how and I haven't thought about this in years so I'm not sure at the moment what would be useful. Probably a good first step is to allow more reactions than unceremoniously shutting off for a fixed (and rather long) period of time. Configuring that period is an obvious direction. It should also be possible to continue accepting connections but limit the rate at which it happens (giving those who don't get in ECONNREFUSED). Limits based on system load average, or the number of subprocesses _running_ rather than the fork rate, are probably also useful. > [...] Another important thing often gotten wrong doing this in the Linux world: when pointed at a directory, don't read _every_ file in the directory; read only the ones whose names match "*.conf" or "*.inetd" or something like that. Otherwise you inevitably end up editor backups or scratch files or other miscellaneous rubbish and problems ensue. -- David A. Holland dholl...@netbsd.org
Re: inetd Enhancements
On Sun, Nov 22, 2020 at 09:53:27PM -0500, Mouse wrote:
> Not quite. It's not about the admin having to pass a test in order to
> be one of the elite who get to use $PACKAGE. (I know that's going
> beyond what you actually wrote; it's approximately what I suspect a lot
> of people will read into what you wrote, whether you meant it or not.)
> It's more that I don't like automated administration of the "I'm going
> to put all these pieces in what I fondly hope are the correct places
> and hide it all from the admin" sort.
Done properly, it doesn't do that.
The main (and rather large) downside of making a directory full of
tiny files for each config task, instead of a single file, is that
it's a large and untidy mess and it makes it hard to get an overview
of what's going on, hard to keep track of changes, and also hard to
make updates.
The main advantage is that the resulting files can be handled by
package managers, whereas merging stuff from packages into a single
file is complicated and fragile.
The important issue is: what's this crap being added by packages
anyway?
In the case of inetd, the definition of a service is not really
configuration. Sure, it configures inetd in the sense that it tells
inetd what to do, but modulo the possibility of passing flags to
daemons there's only one correct way to define any given inetd
service. They are not configuration in the sense of material edited by
the sysadmin to adjust how the system operates.
For example:
ntalk dgram udp wait nobody:tty /usr/libexec/ntalkd ntalkd
If you change anything on that line, apart from "nobody" or adding one
of talkd's minimal command-line options, it won't work correctly. And
changing "nobody" is not a good idea or necessary in any reasonable
case. The only things you can actually _do_ with it as a sysadmin are
(a) comment it out (that is, turn it on or off) and (b) add those
options.
If inetd.conf instead contained something like
ntalk on flags -l
and the service definition were elsewhere, the only drawback to the
experienced sysadmin is that it's not the traditional syntax so they
have to read the directions. (And yes, that's a real drawback, but not
a huge one.) For the newbie sysadmin there's a minor advantage, namely
that they can't break it accidentally by editing it wrong, e.g. by
doing
-ntalk dgram udp wait nobody:tty /usr/libexec/ntalkd ntalkd
+ntalk dgram udp wait nobody:tty /usr/libexec/ntalkd -l ntalkd
instead of
-ntalk dgram udp wait nobody:tty /usr/libexec/ntalkd ntalkd
+ntalk dgram udp wait nobody:tty /usr/libexec/ntalkd ntalkd -l
(which is an easy mistake to make).
Now, in this new world where inetd.conf contains
ntalk on flags -l
and somewhere else there's a service definition that says e.g.
ntalk dgram udp wait nobody:tty /usr/libexec/ntalkd ntalkd ${FLAGS}
it makes _no sense whatsoever_ to split inetd.conf up into tiny files
in a subdirectory. In this new form, there's nothing whatsoever in it
that should be getting adjusted by package management -- both the
on/off switch and the flags are system configuration that should be
changed only by the sysadmin. (I'm aware that in the Linux world
installing a daemon seems to also imply turning it on automatically.
This is just wrong.)
(If you have the misfortune to be using puppet or ansible or similar
tools, those should be blatting in the whole inetd.conf file at once,
and there's still no reason to subdivide the file.)
On the other hand, the _service definitions_ can come from one file or
ten files or a gazillion files and nobody needs to care as long as (a)
inetd can find them and (b) they get installed into the right place.
For these it is definitely convenient to have a subdirectory scheme so
that packages can install inetd service definitions. Right now the
state of the art for that is for the package to print a message at
install time and hope the sysadmin notices, which is useless enough
that very few third-party packages ever shipped as inetd clients even
back in the days when most systems would have had inetd running and
serving various standard things.
Note though that this directory is not system configuration and
doesn't belong in /etc. It should be /usr/share/inetd, plus also
/usr/pkg/share/inetd, and for completeness /usr/local/share/inetd.
xinetd does not get this right. Few if any of the foo.d schemes
arising from the Linux world have gotten this right.
Getting it right requires at least two things that demand a deeper
understanding of system design than the Linux world seems to be able
to muster in general: (a) understanding the difference between genuine
sysadmin-facing configuration and other material; and (b) setting up
configuration schemas to respect this difference.
--
David A. Holland
dholl...@netbsd.org
Re: Summary of man-page formatting
On Sun, Nov 15, 2020 at 03:10:08AM +0100, Kamil Rytarowski wrote: > I'm going to summarize the situation with formatters in the NetBSD base. A couple more points: > [...] old groff in base. There's an additional reason to not update groff besides licensing, which is that recent groff depends on perl. > 9. The upstream mandoc(1) team (as of today) is open to accept MANWIDTH > as it was repeatedly requested by users, however only for the release > after the coming one. I don't think there's any point trying to format roff docs to any terminal width other than 80. The formatting is not robust and I don't think we can expect anything other than plain paragraphs of text to resize correctly, and maybe not even that. Furthermore, widths much past 80 are too wide for ergonomic reading anyhow. You'd want to switch to two (or more) columns, and that's a can of worms. > 11. For some reason we have got a rule for .me files in man.conf(5). Someone should try to find out why/how it got there, but realistically it can be removed. > 12. I recall recurring discussions about phasing out gplv2 groff from > the base and introduction of something else. This is not relevant to man pages; we have mandoc for man pages and it works well enough. Trying to find something else for typesetting articles and large documents and perhaps also the release notes (it might be possible to abuse mandoc into handling the release notes, but it's not desirable and mandoc will never be able to handle the general case) that's an entirely different question. When it comes up, there's basically three standard responses: (1) Various people propose switching to this or that other roff implementation, and sometimes lengthy discussion of the current availability or licensing concerns or whatever follows, all ignoring that this is rearranging the deck chairs on the Titanic. (2) Thierry mentions kertex as an alternative to trying to import ordinary tex into base (which is a nonstarter), but this never goes anywhere; occasionally someone also proposes writing something new, which has some of the same problems, most notably that it would be a private project without much or any user community and without much (or any) upstream supporting it. (3) People go inventory the small number of existing alternatives to roff and tex and find that they're all pretty problematic even ignoring questions of whether they can credibly be imported into base. None of this goes anywhere useful and what's left is the status quo. I think the _solution_ to this problem is a new typesetting engine (not anything based on tex or roff), but this has to happen and become viable independent of netbsd before we adopt it; if we jump the gun it's as likely to become an expensive white elephant as anything else, and we already have as many of those as we can afford. Like with many other problems, the current situation is poor and there's also no particularly viable way forward. > 14. We still deliver vgrind(1) and some similar macros that use groff > internally. vgrind(1) is rubbish. You can easily get much nicer listings from enscript. The vgrind we have should probably just be deleted. I'm not convinced it's worth writing a replacement, particularly not one that depends on roff. But since it's a traditional Unix utility maybe someone cares enough to bother. -- David A. Holland dholl...@netbsd.org
Re: Proposal to drop MKCATPAGES
On Tue, Oct 27, 2020 at 06:10:10AM +0700, Robert Elz wrote: > | (after all, sed has something similar) > > Yes, but its needs are different, as it can read all of that > from a file, not just from the arg list. True. > | I made it specifically recognize only \n and \t (and not \\ or > | anything else) to minimize the chances of it breaking anything. > > Given that we now have (since at least NetBSD 8) the ability to > easily generate any of these chars from the shell, I wouldn't > go adding magic support for them in anything that doesn't already > have that, at least for processing arg strings. So, I'd prefer > it if you abandoned that patch. Reasonable enough. So the example should be changed to lam file1 -S $'\n' file2 file3 file4 ? Someone(TM) should add $'' to csh and tcsh; it seems handy and doesn't conflict with anything. -- David A. Holland dholl...@netbsd.org
Re: Proposal to drop MKCATPAGES
On Mon, Oct 26, 2020 at 05:39:30PM +0700, Robert Elz wrote:
> | Also if inserting newlines is an intended use case, I kinda think it
> | ought to accept \n in there, which it currently doesn't.
>
> That would be "C string quoting" which is $'\n' which isn't yet in POSIX
> but should be coming sometime, it is supported by most (Bournish) shells
I was thinking in lam itself, like this:
(after all, sed has something similar)
I made it specifically recognize only \n and \t (and not \\ or
anything else) to minimize the chances of it breaking anything.
Index: lam.1
===
RCS file: /cvsroot/src/usr.bin/lam/lam.1,v
retrieving revision 1.14
diff -u -r1.14 lam.1
--- lam.1 26 Oct 2020 04:09:32 - 1.14
+++ lam.1 26 Oct 2020 04:12:48 -
@@ -91,6 +91,9 @@
This option may appear after the last file.
(A capitalized version appearing before the last file is not carried
over past the last file.)
+Instances of the sequences "\en" and "\et" are replaced with hard
+newlines and tabs, respectively.
+(No other escapes are recognized.)
.It Fl t Ar c
The input line terminator is
.Ar c
Index: lam.c
===
RCS file: /cvsroot/src/usr.bin/lam/lam.c,v
retrieving revision 1.8
diff -u -r1.8 lam.c
--- lam.c 4 Sep 2011 20:28:09 - 1.8
+++ lam.c 26 Oct 2020 04:12:48 -
@@ -74,6 +74,7 @@
static char*gatherline(struct openfile *);
static void getargs(char *[]);
static char*pad(struct openfile *);
+static const char *getseparator(const char *arg);
int
main(int argc, char *argv[])
@@ -128,7 +129,7 @@
switch (tolower((unsigned char) *c)) {
case 's':
if (*++p || (p = *++av))
- ip->sepstring = p;
+ ip->sepstring = getseparator(p);
else
error("Need string after -%s", c);
S = (*c == 'S' ? 1 : 0);
@@ -216,6 +217,50 @@
return (lp);
}
+static const char *
+getseparator(const char *arg)
+{
+ size_t i, j;
+ int seen;
+ char *p;
+
+ seen = 0;
+ for (i = 0; arg[i] != '\0'; i++) {
+ /*
+* React only specifically to \n and \t; leave
+* anything else alone.
+*/
+ if (arg[i] == '\\' && (arg[i+1] == 'n' || arg[i+1] == 't')) {
+ seen = 1;
+ }
+ }
+ if (!seen) {
+ warnx("blah");
+ return arg;
+ }
+
+ /* sufficient: length of result is at most strlen(arg) - 1 */
+ p = malloc(strlen(arg));
+ if (p == NULL) {
+ err(1, "malloc");
+ }
+ for (i = j = 0; arg[i] != '\0'; i++) {
+ if (arg[i] == '\\' && arg[i+1] == 'n') {
+ p[j++] = '\n';
+ /* skip the \\ */
+ i++;
+ } else if (arg[i] == '\\' && arg[i+1] == 't') {
+ p[j++] = '\t';
+ /* skip the \\ */
+ i++;
+ } else {
+ p[j++] = arg[i];
+ }
+ }
+ p[j] = '\0';
+ return p;
+}
+
static void
error(const char *msg, const char *s)
{
--
David A. Holland
dholl...@netbsd.org
Re: Proposal to drop MKCATPAGES
On Mon, Oct 26, 2020 at 01:33:22AM +0700, Robert Elz wrote: > | (what are the odds that anyone > | on a slow machine will ever look at lam(1)?) > > I must admit that I'd never looked at lam(1) - on any speed of machine. > > But when I did just now, just for the thrill of it, I see ... > [...] > The proverbial someone should fix that. Fixed. Also if inserting newlines is an intended use case, I kinda think it ought to accept \n in there, which it currently doesn't. > just from that man page read, I suspect that perhaps that -s should > also be -S (but that's speculation). Indeed. Someone changed it a while ago without apparently having read thoroughly enough. -- David A. Holland dholl...@netbsd.org
Re: Proposal to drop MKCATPAGES
On Sun, Oct 25, 2020 at 02:03:43AM +0100, Kamil Rytarowski wrote: > I bet that cat(1) is always faster, but I consider myself as the only > regular (at all?) user of these pages at least since since 6.x and > nobody caring. Also, if we do have a platform where it's too slow and anyone actually cares, the right answer is really not to spend a gob of disk space generating all the pages in advance (what are the odds that anyone on a slow machine will ever look at lam(1)?) but to teach man about caching. That is: I agree, fire away. -- David A. Holland dholl...@netbsd.org
Re: style change: explicitly permit braces for single statements
On Sun, Jul 12, 2020 at 10:01:36AM +1000, 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. concur Really, there should always be braces unless the entire thing is only one line, and we don't (and shouldn't) allow the latter. -- David A. Holland dholl...@netbsd.org
Re: malloc() exceeds RLIMIT_DATA
On Wed, Jul 10, 2019 at 08:40:43PM -0700, Graham Percival wrote: > > Ah, but how do you ask malloc to exceed RLIMIT_DATA? Not by passing it > > a large number, or any number, since that doesn't change the size of > > any data segment. > > Aha! I misunderstood "this limit" to mean "the number returned by > getrlimit()", not "the size of the data segment". So I thought that second > sentence was about talking about what should happen if you passed malloc() a > large value. Ah, so we were all talking past one another. Good thing I wrote that post, I guess :-) In practice (across arbitrary platforms) I wouldn't count on malloc necessarily respecting any of these limits, including the limit imposed by the amount of DRAM in the known universe. In addition to bugs and perhaps unexpected phenomena like NetBSD's non-sbrk malloc, AFAIK there's a faction out there (connected with C++? dunno) who think it's incorrect for malloc to fail, ever, so if they're in control it won't. Instead, at some unpredictable point you get SIGSEGV or SIGKILL, like if the system ran out of swap. > My sincere apologies for wasting everybody's time. Eh, no worries :-) -- David A. Holland dholl...@netbsd.org
Re: malloc() exceeds RLIMIT_DATA
On Tue, Jul 09, 2019 at 10:24:53AM -0700, Graham Percival wrote: > RLIMIT_DATA > This is the maximum size of a data segment of the process, in bytes. If > this limit is exceeded, the malloc() function shall fail with errno set > to > [ENOMEM]. > http://pubs.opengroup.org/onlinepubs/9699919799/functions/getrlimit.html > > The relevant part is the second sentence. My interpretation of that sentence > is that if malloc() does *not* fail when it is asked to exceed RLIMIT_DATA, > then it is not following the POSIX standard. Ah, but how do you ask malloc to exceed RLIMIT_DATA? Not by passing it a large number, or any number, since that doesn't change the size of any data segment. I think a program image whose .data exceeds RLIMIT_DATA won't load, so in that case any call to malloc will indeed fail with errno set to ENOMEM, inasmuch as anything follows from an invalid premise. Although now I wonder if ld.so enforces RLIMIT_DATA on the .data size of shared library images. (Note: if you're trying to do something practical, you might find RLIMIT_AS or RLIMIT_RSS more helpful.) -- David A. Holland dholl...@netbsd.org
Re: NetBSD truss(1), coredumper(1) and performance bottlenecks
On Sat, May 25, 2019 at 09:19:39AM +0700, Robert Elz wrote: > | My observation was general that this syscall is frequently called by > | many programs. Optimization of it can potentially change responsiveness > | of the whole system. > > Yes, gettimeofday() is very common - but we need to investigate how > to speed it up, not just presume that a mapped page is the right answer. > > Using a mapped page would mean processes would only see the time as it was > last updated in the kernel - That obviously sucks :-) The general mapped page scheme is that the processor has some kind of usermode-accessible tick counter or timer and the mapped page contains the offset and/or scale needed to convert that to a useful time. On old processors without such a widget, it basically doesn't work. > I am sure there are, but I very much doubt that build.sh is really something > itself that ought to be a target of investigation. All it is is a wrapper > around make. All the real work is done in make, and all that it calls. > Speeding up build.sh itself is very unlikely to change anything, unless we > can find entire runs of make that we can optimise away. make is very slow :-| -- David A. Holland dholl...@netbsd.org
Re: NetBSD truss(1), coredumper(1) and performance bottlenecks
On Fri, May 24, 2019 at 04:25:12PM +0700, Robert Elz wrote: > | That's probably the shell that must read input byte by byte in most cases. > > The shell actually very rarely does one byte reads when not reading > from the terminal (and even then only for command line editing). > > That used to be important in the pre Bourne-shell days, but the time > of the shell passing the open script to child processes to read from > are long gone - and without that, it isn't as important that there > be no readahead. Did POSIX drop the requirement that sh scripts can successfully be self-modifying? (if so, hurray) -- David A. Holland dholl...@netbsd.org
Re: _NETBSD_SOURCE always defined leading to unwanted inclusions
On Sat, Apr 20, 2019 at 10:30:48PM +0200, tlaro...@polynum.com wrote: > [I changed the subject because this was lost in the end of a message > about _STANDALONE] > > When one does not specify something special (_ANSI_SOURCE or > _POSIX_C_SOURCE or _XOPEN_SOURCE), _NETBSD_SOURCE is always defined > due to the inclusion of sys/featuretest.h almost everywhere. Yes, that's intentional. > This leads to the inclusion of some chunks of code in , > specially the definition of static functions (supposed to be inlined but > this will depend on the compiler and on the flags--- -fno-inline). > > A first problem (YMMV) is that can not be included anywhere > but only outside of a block, since there are definitions and not only > declarations. Don't do that. You can't expect any header not specifically prepared for the purpose to work correctly if included somewhere other than the top level. > The second problem is that the functions are not prefixed by '_' and can > conflict with locally defined functions. Those functions are part of the library API. If you want to restrict what's defined, use _POSIX_C_SOURCE or one of its many cousins. -- David A. Holland dholl...@netbsd.org
Re: SHA384_Update symbol clash with libgs
On Fri, Apr 05, 2019 at 07:18:46PM +0200, Edgar Fu? wrote: > Apart from a GS rendering library exporting symbol with the name of a > well-known crypto function being a strange idea, who is at fault? The ELF spec. -- David A. Holland dholl...@netbsd.org
Re: [PATCH] dump -U to specify dumpdates device
On Wed, Mar 20, 2019 at 08:10:22AM +, Emmanuel Dreyfus wrote: > I propose to add -U option to dump(8), which lets the administrator > specify the device name in /etc/dumpdates. Example usages: > dump -a0uf /dump/data.dump -D NAME=data /data/ > dump -a0uf /dump/data-abc.dump -D data-abc /data/a* /data/b* /data/c* > > Here is the patch. Opinions? I have been meaning sometime to hack dump to allow using dumpdates with subtree or partial-volume dumps, which requires something like this as a prereq, so yes please. -- David A. Holland dholl...@netbsd.org
Re: namespace pollution by curses
On Tue, Mar 12, 2019 at 01:25:13PM +0300, Valery Ushakov wrote: > Admittedly, I'm not sure about the usage. E.g. in wscons case you can > press a modifier on one keyboard and the key on another and it should > work. But in case of curses, do the users really expect to be able to > input the beginning of a multi-byte sequence on one screen (via that > screen-private infd) and the end of if on another screen (via its own > screen-private infd) and still get a composed (via static > state/inbuf/...) wide character sent to the second screen? That seems like a bug waiting to be exploited if the app is some kind of multiuser game that works by multiheading... not that such an architecture should be encouraged... -- David A. Holland dholl...@netbsd.org
Re: colorls in base
On Sun, Feb 17, 2019 at 07:57:52PM +, David Holland wrote: > Why? Does every terminal window out there have the same background > color? So, just for shits and giggles, here's twenty xterm color pairs from my master list of decently legible and reasonably nice-looking ones. If anyone can provide a set of colors for ls that works nicely with all of them, I'll pipe down, even though the full list is a lot longer :-) -fg royalblue3 -bg lavenderblush -fg blueviolet -bg peachpuff -fg blueviolet -bg plum2 -fg violetred4 -bg azure3 -fg ghostwhite -bg deeppink4 -fg white -bg palevioletred4 -fg yellow -bg chocolate -fg ghostwhite -bg seagreen4 -fg wheat -bg turquoise4 -fg white -bg steelblue4 -fg yellow -bg deepskyblue3 -fg white -bg deepskyblue -fg turquoise2 -bg '#007faf' -fg turquoise2 -bg slateblue -fg gold -bg slateblue -fg orange2 -bg slateblue4 -fg ivory2 -bg '#300d9a' -fg orangered -bg navyblue -fg gold -bg '#27275f' -fg turquoise1 -bg midnightblue -- David A. Holland dholl...@netbsd.org
Re: colorls in base
On Sun, Feb 17, 2019 at 01:24:09PM -0600, Jonathan A. Kollasch wrote: > > Can we, however, please have colors that are not angry fruit salad? My > > understanding is that sufficiently recent xterm and terminfo is > > capable of handling arbitrary rgb colors, so there's therefore no need > > to make everyone's eyes fall out. > > That's more a palette issue... ANSI gives us 8 colors (16 if you think > that "bold" should indicate another color rather than heavier weight > text). It's difficult to get a combination of > black/red/green/yellow/blue/magenta/white to not look like angry fruit > salad, unless you significantly diverge from the generally accepted look > for those color names. And you can't diverge from them at all using just the traditional MSDOS-era color escape codes. That's the point. Using tty colors is, inherently, repulsively ugly. I am asking that we not perpetuate this aesthetic crime and, if we're going to deploy this feature, do it in a way that doesn't automatically make people's eyes fall out. (And before anyone says "it adds information! whether it's ugly is irrelevant" -- being that ugly detracts significantly or fatally from the ability to interpret the information.) > If you want to advance to the 256 color with > 6x6x6 color cube, or 24-bit color modes, you may quickly take this > thread into literal 'what color should we paint it' bike shedding. Yes, so someone with graphic design sense needs to put together a scheme, or steal one off the internet. > > Better still would be a scheme that can adjust to the existing text > > and background color of the terminal, but that's probably still hard. > > While an interesting idea, that sounds like a solution waiting for a > problem to me. Why? Does every terminal window out there have the same background color? -- David A. Holland dholl...@netbsd.org
Re: colorls in base
On Fri, Feb 15, 2019 at 04:43:24AM +0100, Kamil Rytarowski wrote: > I'm for adding colors... I kind of agree with jnemeth; but as long as it isn't on by default I don't care that much. Can we, however, please have colors that are not angry fruit salad? My understanding is that sufficiently recent xterm and terminfo is capable of handling arbitrary rgb colors, so there's therefore no need to make everyone's eyes fall out. Better still would be a scheme that can adjust to the existing text and background color of the terminal, but that's probably still hard. -- David A. Holland dholl...@netbsd.org
Re: Possible slight speedup to non-interactive /bin/sh startup
On Tue, Feb 12, 2019 at 02:41:30AM +0700, Robert Elz wrote: > Nothing that could be done to libedit itself can possibly change > anything that is being measured here. That's not quite true; it has a fair amount of data in its ABI, and that incurs startup-time cost because you can't bind data lazily. (Also, initialized data incurs bulk memcpys...) -- David A. Holland dholl...@netbsd.org
Re: Possible slight speedup to non-interactive /bin/sh startup
On Mon, Feb 11, 2019 at 09:36:57AM +0700, Robert Elz wrote: > Is this something that is worth pursuing? Maybe one of the necrocomputing folks wants to measure rc.d performance with and without it :-) -- David A. Holland dholl...@netbsd.org
Re: Pressure sensors
On Wed, Jan 02, 2019 at 01:56:12PM -0500, Greg Troxel wrote: > > I would make it Pa in the API and let userland translate to whatever > > values we want to display by default. > > That seems somewhat reasonable, except that in my experience everybody > wants to see atmospheric pressure in mb/hPa (if they aren't using inches > or mm of Hg). This is an integer API underneath, right? So the choice of kernel -> user reporting unit should be made on precision and range grounds. Which isn't much of a concern for atmospheric pressure as the possible range is narrow, but one could imagine someone trying to use the same interface for lab equipment. -- David A. Holland dholl...@netbsd.org
Re: Pressure sensors
On Tue, Jan 01, 2019 at 12:03:31PM -0500, Greg Troxel wrote:
> > my sensor does fill ->value_cur with mPa, so pressure does fit into the
> > "everything else"-else{} with ->cur_value / 100.0 for printout in kPa.
>
> Until very recently I had never seen pressure in kPa. For atmospheric
> pressure, the standard unit seems to be hPa. I realize that's a
> less-normal SI prefix, but it happens to match mbar. But, I am seeing
> kPa more tha last 6 months.
Environment Canada was reporting pressure in kPa when I was a kid. Did
they stop?
> So, I wonder why you are choosing kPa vs hPa, and if that choice ends
> up being a framework choice for everything. And how the rest of the
> world deals with this issue.
Most of the world uses millibars and occasionally labels them hPa.
Since judging by the patch the framework isn't up to handling both,
the best course is probably to use and label as millibars and just
duck the occasional brickbat from metrication nuts.
--
David A. Holland
dholl...@netbsd.org
Re: deleting telnet/telnetd
On Wed, Dec 19, 2018 at 10:00:06PM -0800, John Nemeth wrote: > } The previous telnet thread, contentious as it has been, has completely > } missed the critical context, which is that telnet is 14,700 lines > } cutpasted from the Necronomicon and telnetd is only slightly better. > > Yeah, so? So it's a danger to have around, given that it's network-facing. Have you looked at the code? Have you tried making changes to it? Do you have any grounds for claiming it's not as bad as I say it is? It's the worst code I've ever worked on, and I've spent a long time (probably more than most people here) cleaning out toxic software messes and I've seen a lot. > why aren't you volunteering to do the rewrite Because I'm not one of the people claiming I need it because I can't learn to type 'nc' instead. Because the amount of discretionary hacking time I have these days is measured in tens of hours per year. Because I already threw plenty of time down this rathole in the past (note the 12000 line diff I posted a couple days ago). Because anyone could do it and I should be spending what time I have on things that other people can't or won't do. Etc. And also, because the attitude in this thread (yours, but not just yours) is ticking me off. I have better things to do than provide software for free to people who respond to my carefully considered opinion with contempt. -- David A. Holland dholl...@netbsd.org
Re: deleting telnet/telnetd
On Wed, Dec 19, 2018 at 10:04:19PM -0800, John Nemeth wrote: > } The reason it came up this week is that someone found and posted a > } couple noncritical problems in one of the other forks of it. > > And, how many years has it been since the last significant bug? How many years has it been since anyone looked at it in any serious way? Have you looked at the code? It's quite reasonable to suppose it has many significant bugs. -- David A. Holland dholl...@netbsd.org
Re: deleting telnet/telnetd
On Wed, Dec 19, 2018 at 10:17:28PM -0800, John Nemeth wrote: > } - PuTTY is nice > > PuTTY is a graphical app, and therefore not a replacement for > telnet(1). If there is a way to use it from a command line, please > let us know. As you would know if you'd bothered to look, PuTTY contains its own telnet protocol implementation that isn't derived from the historic one. It would be interesting to know just how many legacy network devices it's actually been tested against and what fraction of them it works reliably with. (However, it does not support flow control, which probably nobody cares about, or line mode, which various people have announced they do.) > It's frustrating even when it touches things that one doesn't > use. It's just double frustrating when it touches things that one > uses. The deletionists should go create their own OS (which will > be useless due to lack of functionality). You realize I'm not a deletionist, right? -- David A. Holland dholl...@netbsd.org
Re: deleting telnet/telnetd
On Wed, Dec 19, 2018 at 11:06:58PM +0100, Manuel Bouyer wrote: > On Wed, Dec 19, 2018 at 10:03:19PM +0000, David Holland wrote: > > On Wed, Dec 19, 2018 at 10:58:14PM +0100, Manuel Bouyer wrote: > > > On Wed, Dec 19, 2018 at 09:03:27PM +0000, David Holland wrote: > > > > [...] > > > > The hope, I think, was that the conclusion would be that we don't > > > > really need one. > > > > > > We really need one, and the one we have does the job. I really don't see > > > why we shoud rewrite something that works. > > > > Have you looked at the code? > > no but I do use it quite often. If you value your sanity, don't. But, also, you might want to rethink how much you trust it. -- David A. Holland dholl...@netbsd.org
Re: deleting telnet/telnetd
On Wed, Dec 19, 2018 at 10:14:47PM +, m...@netbsd.org wrote: > Relax, the end conclusion was not to delete it. To maintain it until a > replacement comes in. Please help test the replacement if it is written, > to ensure it works for your case. Obviously since we've concluded we need a telnet client, we can't delete the one we've got without a replacement... -- David A. Holland dholl...@netbsd.org
Re: deleting telnet/telnetd
On Wed, Dec 19, 2018 at 10:58:14PM +0100, Manuel Bouyer wrote: > On Wed, Dec 19, 2018 at 09:03:27PM +0000, David Holland wrote: > > [...] > > The hope, I think, was that the conclusion would be that we don't > > really need one. > > We really need one, and the one we have does the job. I really don't see > why we shoud rewrite something that works. Have you looked at the code? -- David A. Holland dholl...@netbsd.org
Re: deleting telnet/telnetd
On Wed, Dec 19, 2018 at 01:36:48PM -0800, Hisashi T Fujinaka wrote: > Telnet is used every day and most of the use cases can use nc. > > I wish you'd get rid of it because that would mean I can resign and > delete NetBSD and get rid of a lot of old hardware. You realize I'm not one of the deletionists, right? -- David A. Holland dholl...@netbsd.org
