Re: inetd enhancements - config syntax

[Mouse]

> ...and also, for your own and the operator's sanity, skip anything
> else beginning with '.',

Not sure I agree with that; I'd have to think about it.  I could argue
it either way.  Why do you think .-prefixed entries should be skipped?

Relatedly, do you feel the same way about names beginning with, or
containing, other unusual things, such as , + | ~ # * % !?  Why or why
not?

> names that don't end in ".conf" (or ".inetd" or whatever you think
> the proper suffix should be),

Yes.

> and anything that isn't a regular file (DT_REG).

I don't recall whether this is relevant (it's been quite a while since
I did anything with d_type), but I strongly believe that symlinks
should be followed before any such test.

> (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.)

I'm not sure I agree.  (I'm also not sure I disagree.)  I certainly
don't have any immediate use for any such, but I'm also very unsure
this wouldn't be a case of forbidding stupid things and thereby
forbidding clever things.  Maybe a switch to turn it off, or maybe
people who want to get that clever should just hack on the source
themselves?  I'm not sure how reasonable I think that is.

If such a check does go in, well, I don't *think* O_PLAIN (fail if the
putatively-opened object isn't a plain file) dates back far enough I
got it into NetBSD's tree, but if there isn't currently anything
equivalent, maybe it'd be worth adding?  I found it borderline trivial
to add, and it really helps for things like this.  I should probably go
read man.netbsd.org's open(2)

> ...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...

I may - occasionally - write code that uses global variables that way,
depending on precisely what you mean.  I definitely think there is a
place for (to borrow from the current syntax for a moment)

10.10.10.10:
.include "private-stuff/"
20.20.20.20:
.include "world-facing-stuff/"
*:
.include "everybody-stuff/"

This may or may not be an example of what you're talking about.

I do think the order in which the directory entries appear in the
directory should not matter; either the spec should be such that the
order in which they're processed doesn't end up mattering, or the
entries should be sorted in a well-defined order (whether hardwired or
chosen by the admin or indicated by the include directive or what).

/~\ The ASCII Mouse
\ / Ribbon Campaign
 X  Against HTMLmo...@rodents-montreal.org
/ \ Email!   7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

Re: inetd enhancements - config syntax

[David Holland]

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

[David Holland]

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