Re: patch(1) max line length
Mouse wrote in <202407122106.raa17...@stone.rodents-montreal.org>: |>>> I note the specification does not forbid the handling of lines |>>> longer than LINE_MAX characters. |>> No, it certainly does not do that. | |Yeah; like a lot of examples, recovery from error cases is allowed to |be "handle it as if the limit weren't there". | |> It is your fault to think normal rules apply to JSON, for sure. | |Well, I would say, rather, that it the mistake lies in expecting normal |text tools to work on newline-free JSON, or minified javascript, or |other pseudo-text data without newlines). Maybe yes. Pretty sure even. |But, yeah, "they don't care any more". I have yet to find a way to Yeah, really. That. And then i want mupdf (which became a monster that has a 143 MB package here) to give me a way to look and scroll through the history. Just a window with the content. Has not even a window that shows shortcuts. |configure recent Linuces so that text tools (ul, sed, etc) work in the |"each octet is exactly one character" paradigm (which I want more often |than they seem to think I should, even when working on Linux). LC_ALL=C i would say. (If that is not C.UTF-8 ;) |For that matter I have lost track of the number of tools (Linux tools |are the worst but by no means only offenders) that assume X3.64 |sequences do whatever it is the program is expecting them to...and then |there's recent gcc, which outputs *mis-terminated* OSCs. Not encountered that yet here. I only have problems with GNU bison when running it (for nawk) in some container. bug-bison on April 26th bison -d awkgram.y awkgram.yawkgram.y: : warning:warning:3399;49m;49m 62 shift/reduce conflicts62 shift/reduce conflicts [ [ 7 reduce/reduce conflicts] [8;id=5]984;dicd7=750909046d1c67f7101050b63196dfb1d1050b03090d0b0d10;0h0t0t0p0s0:1/;/hwtwtwp.sg:n/u/.wowrwg./gsnouf.towragr/es/obfitswoanr/em/abniusaoln//hmtamnlu_a nlo/dhet/mDli_angondoes/tDiicasg.nhotsmtli#cWsc.ohntfmlli#cWtcso-nrfrl\c-Wconflicts-rrt[-3r9r;\9-Wconflicts-rrm389;;;4\m] awkgram.y: note:note: erun with option '-Wcounterexamples' to generate conflict counterexamples[f111d207]580;0i0d00=050919;h4ttdpcs7:/7/0w0w0w.gnu.org/softw6a1r6ef/1b1i1sdo2n/ma0nu7a4l2/0h0t0 39;49m rerun with option '-Wcounterexamples' to generate conflict counterexamplescts-rri[o3n9/;m4a9nmu]l8/;h;t\l_no]de cc -g -Wall -pedantic -Wcast-qual -O2 -c -o [.] ... Have this for years, but it seems it is the library underground and noone else uses strange namespace containers in favour of docker or something. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: patch(1) max line length
Steffen Nurpmeso wrote in <20240712172239.8n2tqdo2@steffen%sdaoden.eu>: |Robert Elz wrote in | <28937.1720777...@jacaranda.noi.kre.to>: ||Date:Fri, 12 Jul 2024 08:15:57 + ||From:Emmanuel Dreyfus ||Message-ID: || ||| I note the specification does not forbid the ||| handling of lines longer than LINE_MAX characters. || ||No, it certainly does not do that. || ||However applications (at least if there's any attempt at portability ||at all) shouldn't assume that will work. | |It is your fault to think normal rules apply to JSON, for sure. |It is exceptional, see for example | | $ wc -lwc /var/tmp/steffen/.cache/.mupdf.history | 122 23240 /var/tmp/steffen/.cache/.mupdf.history | |They all do not care no more. (I remove this once in a while, it It must be said though that the (i maintain) MUA blindlessly saves any user input as a single line, no matter the size. The history file format does not support line continuation. (But i hope this really is exceptional for me.) |would be even worse otherwise.) |You are assumed to use json_pp or something, ah, i think "jq". ... --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: patch(1) max line length
Robert Elz wrote in
<28937.1720777...@jacaranda.noi.kre.to>:
|Date:Fri, 12 Jul 2024 08:15:57 +
|From:Emmanuel Dreyfus
|Message-ID:
|
|| I note the specification does not forbid the
|| handling of lines longer than LINE_MAX characters.
|
|No, it certainly does not do that.
|
|However applications (at least if there's any attempt at portability
|at all) shouldn't assume that will work.
It is your fault to think normal rules apply to JSON, for sure.
It is exceptional, see for example
$ wc -lwc /var/tmp/steffen/.cache/.mupdf.history
122 23240 /var/tmp/steffen/.cache/.mupdf.history
They all do not care no more. (I remove this once in a while, it
would be even worse otherwise.)
You are assumed to use json_pp or something, ah, i think "jq".
Btw my MUA calls its on-program-exit also very late, even
documented so ("after terminal is torn down" or so). I find it
much more natural to configure history during startup, when
case $- finds *i*|*m*.
--End of <28937.1720777...@jacaranda.noi.kre.to>
--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
Re: submission port usage (was: /etc/services losses)
Edgar Fuß wrote in
:
|I think the de-facto rationale for a larger network goes like this:
|-- You don't want to get your IPs blacklisted because infected clients
| send spam from within your network.
|-- Other sites will allow mail submission on their submission port only
| after authentication (SASL).
|So you block outgoing smtp, but allow outgoing submission.
Seems to me, likely that was the spark as such even. No
auth+login on :25, TLS requirement on submission(s). Different
kind of content checks / milters / filters etc etc. (Though it
seems "we" ("white") waste the planet for useless CI runs, mail
checks, and flights to the Caribbean).
--End of
--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
Re: /etc/services losses
Mouse wrote in <202308031802.oaa16...@stone.rodents-montreal.org>: |> Hm, but especially :25 was traditionally used by MUAs, no? |> Who used the submission port ~a decade ago? | |User agents. I'm pretty sure submission was a thing _two_ decades ago, |though IIRC not all that big a thing. (Mind you, it may not have been |on the port it's on today, but there was something SMTPish that was |designed for MUA submissions, on a separate port.) Well ok submission (not -s) seems to have been invented (RFCd) in 1998. BUt i am very sure i have submitted mails via MUA to port 25 some time in the past. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: /etc/services losses
Greg Troxel wrote in : |Taylor R Campbell writes: | |> `smtp(s)' and `submission(s)' are subtly different protocols and |> should not be aliases: |> |> - smtp(s) is for MTA<->MTA exchange of fully formed internet mail |> messages with complete headers. Hm, but especially :25 was traditionally used by MUAs, no? Who used the submission port ~a decade ago? (I cannot truly tell about a survey though, here all was TLS, "always".) |> - submission(s) is for an MUA to submit new messages, which may not |> have complete headers or fully qualified addresses or otherwise be |> fully formed, via a mail submission agent into the internet mail |> system. | |Yes, they are different, however my take from reading |https://datatracker.ietf.org/doc/html/rfc8314 is that the orignal label |of 465 as smtps was confused, and that IANA now labels 465 as start | |> I'm also not sure it matters if a TLS session is preceded by the ten |> bytes `STARTTLS\r\n' on the wire or not. 'Had to read the RFC how that interferes with EHLO reset. |It very clearly does not matter. I think the concern was |implementations that treated TLS as optional and would continue. But |that's all rationale for why RFC8314 recommends as it does. Where we |are now is that 465/tcp is submissions and 587 is submission. And our |services file has smtps for 465, but that no longer exists in IANA-land. | |> I'm not sure if there is any port number that can rightly be called |> `smtps' today. | |Agreed. I know of no usage that is MUA-to-MUA SMTP over prenegotiated |TLS. It's basically a STARTTLS over 25 world -- which is what I think |you are thinkig | |For this thread, I think all that matters is that we find a reasonable |way to update services to match IANA while maintaining local diffs. We |have gotten into a bad state. --End of --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: /etc/services losses
Greg Troxel wrote in : |Hauke Fath writes: |> On Mon, 31 Jul 2023 18:20:40 +0200, Steffen Nurpmeso wrote: |>> Greg Troxel wrote in : |>>|Hauke Fath writes: |>>|> attached is a diff with services that for some reason or other got |>>|> dropped from /etc/services - in particular Amanda* and AppleTalk. |>>| |>>|The really big question here is the relationship between our |>>|/etc/services and |>>| |>>| |> <https://www.iana.org/assignments/service-names-port-numbers/service-nam\ |> es-port-numbers.txt> |> |> Indeed, and our /etc/services looks a lot more like a copycat of that |> file than like the output of Steffen's script - thanks for that. Has it |> ever been used for a commit, though? | |You should write to the people that did the commits and ask them. | |> IANA appears to have settled on submissions for port 465 (which, |> coincidentally, was assigned to 'urd' in the netbsd-5 version, and the |> NetBSD addition then declared the smtps alias). A web search for |> 'smtps' confirms widespread use, so this should be maintained as an |> alias for 'submissions' IMO. | |I must have misread. The iana link above clearly has submissions = |465/tcp. It also has urd. So our file should of course match. 465 is urd and submissions and igmpv3lite (here). But since MTAs do not look out for smtps (instead of 465 for SMTPS we now have RFC 8689, SMTP Require TLS Option --- hihihi) it does not matter to also give SMTPS that MUAs may look out for (which normal mentally healthy user looks for submissions:// given he normally uses smtp:// even though that most likely is indeed submission or so, who knows, .. luckily my hairsplitting time has long passed). |There's a huge point here that I want to make explicit. We need to have |a sane process for updating from IANA, and that involves | | - having a script to convert IANA into our format Did you not ask Christos Zoulas, he surely "did something" the last time this came up. | - having that script checked into the sources Maybe that is in "othersrc" or any other such thing i do not track. | - some mechanism to maintain the "local additions" section at the end | | - probably a scheme to maintain any diffs from IANA, if we really want |any | | - probably a way to build a new file from iana-converted and local --End of What i did not understand was that huge number of additional name permutation entries we see. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: /etc/services losses
Greg Troxel wrote in
:
|Hauke Fath writes:
|> attached is a diff with services that for some reason or other got
|> dropped from /etc/services - in particular Amanda* and AppleTalk.
|
|The really big question here is the relationship between our
|/etc/services and
|
| https://www.iana.org/assignments/service-names-port-numbers/service-name\
| s-port-numbers.txt
|
|The format you don't like seems to be sort of similar to the one from
|IANA. But we are quite out of sync from that, so I wonder about the
|other BSDs.
...
|So I would talk to them and see what they did and why; it seems like
|there must be a script from an iana file, and then there's supposed to
|be the "local additions" section. Probably the real bug is losing that
|and it can be put back. But editing without understanding that flow
|seems unwise.
Anything amanda like but amanda itself is missing from IANA, at
least it is not here either, and we also have a script. (I once
posted it, as below.)
|Files generated like this usually have a Big Scary Warning, and this
|doesn't; probably someone(tm) should fix that.
|
|On the substance:
|
|The use of mail for port 465 was apparently assigned briefly and then
|not (we have STARTTLS now), and how is assigned to urd. I never thought
|it was for submission. It is not in the current IANA file. So it's a
|good question why it remains at all. I am therefore not ok with adding \
|smtps.
submissions is a standard, RFC 8314:
3.3. Implicit TLS for SMTP Submission
When a TCP connection is established for the "submissions" service
(default port 465), a TLS handshake begins immediately. Clients MUST
implement the certificate validation mechanism described in
[RFC7817]. Once the TLS session is established, Message Submission
protocol data [RFC6409] is exchanged as TLS application data for the
remainder of the TCP connection. (Note: The "submissions" service
name is defined in Section 7.3 of this document and follows the usual
convention that the name of a service layered on top of Implicit TLS
consists of the name of the service as used without TLS, with an "s"
appended.)
...
#!/bin/sh -
#@ Update protocols and services from IANA.
#@ Taken from ArchLinux script written by Gaetan Bisson. Adjusted for CRUX.
awk=awk
curl=curl
url_pn='https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xml'
url_snpn="https://www.iana.org/assignments/service-names-port-numbers/\
service-names-port-numbers.xml"
download() {
datetime=`date +'%FT%T%z'`
echo 'Downloading protocols'
${curl} -o protocols.xml ${url_pn}
[ ${?} -eq 0 ] || exit 20
echo 'Downloading services'
${curl} -o services.xml ${url_snpn}
[ ${?} -eq 0 ] || exit 21
}
process() {
echo 'Processing protocols'
${awk} -F "[<>]" -v URL="${url_pn}" -v DT="${datetime}" '
BEGIN{
print "# /etc/protocols, created " DT
print "# Source: " URL
}
/ protocols.new
[ ${?} -eq 0 ] || exit 30
echo 'Processing services'
${awk} -F "[<>]" -v URL="${url_snpn}" -v DT="${datetime}" '
BEGIN{
print "# /etc/services, created " DT
print "# Source: " URL
}
/ services.new
[ ${?} -eq 0 ] || exit 31
}
update() {
mv protocols.new protocols
[ ${?} -eq 0 ] || exit 40
mv services.new services
[ ${?} -eq 0 ] || exit 41
rm -f protocols.xml services.xml
[ ${?} -eq 0 ] || exit 42
}
download
process
update
--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
Re: Trivial program size inflation
Robert Elz wrote in <2939.1688393...@jacaranda.noi.kre.to>: |Date:Sun, 2 Jul 2023 15:51:06 -0400 (EDT) |From:Mouse |Message-ID: <202307021951.paa07...@stone.rodents-montreal.org> | || For example, a program that calls printf but never uses any || floating-point values at all will not, in theory, need floating point || support. But we do not have any mechanism by which anything can || discover that no floating-point printf formats are used and thus bring || in a printf variant that doesn't actually support floating point; this || means that a bunch of floating-point stuff will be brought in even || though it will never actually get used. | |First, a different printf that doesn't support floats isn't needed, |printf (itself) has essentially no knowledge of anything related to |floats. | |When everything used to be static (ie: back in my time...) a lot of Mine around Y2K also, not _that_ long ago. |effort was expended making small programs stay small (both RAM for the |executing binary, and disc space for the executable file, were scarce |resources) by careful crafting of what was in libc.a and the order it Even getting rid of libc was not that hard (especially on Linux with its syscall() macros where one did not even need ASM shims at all to go this way). And not even "extern char **environ" with the three argument form of main() which unfortunately is never become standardized. Isn't it just that it all went down a grazy route of comfort, with (very smart) TLS (instead of hand-written "ThreadSpecificData"; which was still very fast with a fast thread_self()), automatic ctors and dtors (which existed by then but who really uses that possibility of injection auto-ctors, ie C++ instances, what a mess). ifuncs are also a smart thing, but then again dynamic local jumps (ie computed gotos) in a statically linked function may be faster, by then and maybe even more so today with all the massive (even "multithreaded"?) speculation. But yes they are smart. Of course that could be a standardized thing like dlopen/dlsym is so that people could actually use it. (This is all so much better than applying attributes, because all of today's language designers do not care, for example i now have to write for example OVRX(~a_md(void)) because # if __cplusplus +0 < 201103l # define su_OVRX(X) virtual X # else # define su_OVRX(X) X override # endif ie the order of the attribute switched, but it is likely i am just too stupid to understand why virtual is left and override is right. Right? Yes the "virtual" above is just moron notation as the virtuality is implied from a super class. But, hey.) And POSIX threads are "Thank you, Butenhof of HP"; they should have required a pthread_enable_threading(&mt_enabled_main_fun) to be called in order to make thread+ initialization an explicit thing, instead of anything else. It could even have been super strict, "normally an application does not wildly switch back and forth SMT and non-SMT", at least i have never seen that. |all appeared. Keeping that correct took much work, and it was very easy |to end up with multiple symbol definition errors from linking an innocuous |(and correct) program that just happened to be slightly different than |had been expected. My gut feeling always was that libc is best when it is not needed. |The issue above was solved by having dummy versions of the floating point |to string conversion routines (which did nothing, and so were very small). I have a Plan9 dtoa.c file that is ~20KB and says /* derived from /netlib/fp/dtoa.c assuming IEEE, Standard C */ /* kudos to d...@bell-labs.com, gripes to e...@bell-labs.com */ Uses a malloc though. (And a global dtoa lock, optionally.) And then the full gdtoa package, also from dmg@, aka David M. Gay. That is a bit larger of course. |The compiler helped, by inserting a reference to a well known symbol, if |the program being compiled contained any float or double references. |The real floating conversion routines defined that symbol, the dummy ones |did not. libc was constructed (as far as is relevant here) with the |real conversion routines first, then printf, then the dummy conversion |routines following. | |If the program used any floating point then the compiler inserted undefined |reference to the magic symbol would cause the real conversion routines to |be linked (as they would be if explicitly called by the program, but that's |very unlikely). Then printf would be linked (we're assuming the program |uses printf, or this issue isn't relevant). If the floating point \ |conversion |routines were already linked, they satisfy the undefined symbols in \ |the printf |object file(s). If they weren't, those remained undefined until the dummy |routines were encountered, later in libc, at which point they'd be loaded. |Since we know the program isn't using floating point to get to that point, |they'd
Re: Proposed chown(8)/chgrp(1) enhancement
Paul Goyette wrote in : ... | ( p->fts_statp->st_mode && 07000 ) == 0)) ^^ --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) |~~ |..and in spring, hear David Leonard sing.. | |The black bear, The black bear, |blithely holds his own holds himself at leisure |beating it, up and down tossing over his ups and downs with pleasure |~~ |Farewell, dear collar bear
Re: Controlling Daemons (inetd or aunchd or relaunchd?)
Steffen Nurpmeso wrote in
<20230226013826.renhc%stef...@sdaoden.eu>:
|Bruno Melo wrote in
| :
...
|I personally use something scripted that polls periodically
|instead (for most). It is pretty easy (most of the time), like
...
|I personally think UNIX should be as easy as the above.
|runit is very interesting, but i think being able to redirect
|deaths of daemonized programs to another process like init(8) is
|a real improvement that Linux has with PR_SET_CHILD_SUBREAPER and
|PR_SET_PDEATHSIG of prctl(2), and the FreeBSD approach is even
|more fine-grained. But i personally again really admire
|unshare(1) of Linux with CLONE_NEWPID.
Ie like cgroups:
pid=${!}
[ -d /sys/fs/cgroup/_box_web ] && printf '%s\n' ${pid} >
/sys/fs/cgroup/_box_web/cgroup.procs
...
$ cat /sys/fs/cgroup/_box_web/cgroup.procs
9390
9391
9392
9393
9448
9471
9508
9559
9562
9564
9648
I have not tried whether inotifyd can be used to track such files.
And not to think about the possibility to migrate responsiblity of
an entire (even daemonized) process tree to some other program
simply by writing the pid, or say "IDENT PID" somewhere, for
example to a pipe.
|I think what i mean is, isn't it better to have the possibilities
|in the kernel to provide such, and then the freedom to use shell
|scripts, than something like systemd?
...
(Unfortunately the above has a race condition.)
--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
Re: Controlling Daemons (inetd or aunchd or relaunchd?)
Bruno Melo wrote in
:
|> I am Qingyao Sun, a student looking forward to participating in a GSoC
|> project for NetBSD this year. One project I am interested in is "Port
|> launchd" http://wiki.netbsd.org/projects/project/launchd-port/. I have
|> reached out to Christos Zoulas, the prospective mentor of that project, \
|> but
|> he said that replacing init/rc with launchd could be a little
|> controversial, and suggested me ask your opinions on the list.
|>
|
|I think non-controversials options are importing classic daemontools \
|or importing runit like Void Linux does. Relaunchd is a good idea, \
I personally use something scripted that polls periodically
instead (for most). It is pretty easy (most of the time), like
sshd__init() {
name=sshd
pid=/run/${name}.pid
prog=$(command -v ${name} 2>/dev/null)
}
sshd_start() {
sshd__init
if [ -f /root/hosts/${HOSTNAME}/sshd-ed25519 ]; then :; else
ssh-keygen -q -t ed25519 -N '' -f /root/hosts/${HOSTNAME}/sshd-ed25519
fi
eval ${ssd} --start --pidfile ${pid} --exec ${prog} -- ${SSHD_ARGS}
}
sshd_stop() { sshd__init; ${ssd} --stop --retry 10 --pidfile ${pid}; }
sshd_status() { sshd__init; daemons__stat_and_dog n; }
sshd_watchdog() { sshd__init; daemons__stat_and_dog y; }
where ssd is start-stop-daemon (of busybox, or Debian, where the
former complicates thinfs a bit; and namespace / unshare boxes do,
too).
I personally think UNIX should be as easy as the above.
runit is very interesting, but i think being able to redirect
deaths of daemonized programs to another process like init(8) is
a real improvement that Linux has with PR_SET_CHILD_SUBREAPER and
PR_SET_PDEATHSIG of prctl(2), and the FreeBSD approach is even
more fine-grained. But i personally again really admire
unshare(1) of Linux with CLONE_NEWPID.
I think what i mean is, isn't it better to have the possibilities
in the kernel to provide such, and then the freedom to use shell
scripts, than something like systemd?
|but need to be more stable to replace classic init. Launchd itself \
|is now closed source and full of Mach dependencies as far as I looked \
|the code, you would need to implement Mach microkernel as a kernel \
|module like NextBSD did and like previous NetBSD had. I still prefer \
|the daemontools or runit options (runit runs not being the PID1 too).
--End of
--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
Re: mail(1) editline defaults to vi mode?
Robert Elz wrote in <1017.1676698...@jacaranda.noi.kre.to>: |Date:Sat, 18 Feb 2023 05:18:22 +0300 |From:Valery Ushakov |Message-ID: | || I think no program should ever init editline to vi mode, | |This is BSD, everything should default to vi mode!!! | |If you want some perversion from elsewhere, you need |to ask ecplicitly (perhaps even different ways for |different programs), let's make it as unfriendly as |possible! | |kre | |ps Mouse: no, this should not be in the kernel ... asking the |kernel to search back and get text from something you entered |3 weeks (and several reboots) ago is just unreasonable. I think Mouse refers to a thread on TUHS (where all the old hands of UNIX are, and some idiots, too, but the thread i cannot find, must be within the last six months but whee). Ah have it, for example Rob Pike said in [1] t just seems much more natural to me to have line editing provided at some fundamental level. Putting it in the shell or some library means some tools get it but some don't. Why should sh have editing but mail not? But then there's glob. Do it once, do it well, and do it for everything, where "it" is a wildcard that refers to every important detail. [1] https://www.tuhs.org/pipermail/tuhs/2023-January/027189.html --End of <1017.1676698...@jacaranda.noi.kre.to> --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: strftime(3) oddities with %s, %z
Mouse wrote in
<202211021508.laa26...@stone.rodents-montreal.org>:
|> 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:
|
|> struct tm tm = {
|> .tm_sec = 56,
|> .tm_min = 34,
|> .tm_hour = 12,
|> .tm_mday = 1,
|> .tm_mon = 12 - 1, /* December */
|> .tm_year = 2021 - 1900,
|> .tm_wday = 3, /* Wednesday */
|> .tm_yday = 334,/* zero-based day of year (%j - 1) */
|> .tm_isdst = 0,
|>};
|
|This is fine. But using memset is not; if struct tm contains a pointer
|or a floating-point value, setting it to all-0-bits may produce a trap
|representation - or, possibly worse, a valid value that means something
|different from what you intend.
|
|Unless POSIX was stupid enough to mandate that all-bits-0 is nil for
|any pointer type and something well-defined for floating-point. (I'd
The former is definetely true. (Or will be.)
And i think on the TZ list it just came up it is generally true
for all "modern" machines. (Except for C++ member pointers which
may be -1 (in parts, i hated their double-pointer size).)
|be surprised by that, but standards bodies have surprised me often
|enough in the past.) Certainly C doesn't, at least not as of C99 - I
|don't have a copy of anything newer.
Ah. ISO C.
--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
Re: Permissions of the root dot files
Robert Elz wrote in <15785.1661861...@jacaranda.noi.kre.to>: ... |I have no idea... like I said, the owner bits (except x) for |a root owned file are almost meaningless. "Yeah". ... --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: Permissions of the root dot files
Valery Ushakov wrote in : |On Tue, Aug 30, 2022 at 08:38:02 +0700, Robert Elz wrote: | |> Date:Tue, 30 Aug 2022 02:27:33 +0300 |> From:Valery Ushakov |> Message-ID: |> |>| Is there any particular reason why /root/.profile and /root/.cshrc |>| (that have hard links in / too, for the single user mode i guess) are |>| not writable? |> |> Aside from applications like vi rm mv etc (probably more) which require |> a slight bit more effort if the file has no write permission, what |> difference does the user 'w' (or 'r' ... 'x' does matter) permission |> bit really make on a root owned file? | |Exactly my point. So why do we inflict that on people (ourselves |included)? .shrc is writable but .profile is not and (vice versa) for |csh - .login is writable and .cshrc is not. | |Dot files are meant to be edited, so "aside from vi" is, IMO, a |mischaracterization of a situation. And "a slight bit more" |accumulates over different test VMs etc. In the mailer i maintain i once committed mk/make-install.sh: install binaries 0755 not 0555.. Since packagers have been seen which explicitly adjust their recipes for that, do it. Since root can by default write anything whatsoever on a Unix, 0555 is misleading at best. (Old hand Jürgen Daubert, CRUX-Linux.) --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: sh(1) and ksh(1) default PATH
Robert Elz wrote in
<8853.1660590...@jacaranda.noi.kre.to>:
|Date:Mon, 15 Aug 2022 10:45:59 -0400
|From:Jan Schaumann
|Message-ID: <20220815144559.go11...@netmeister.org>
|
|| I think it's short-sighted and unfair to equate lack
|| of experience with idiocy.
|
|Then why did you jump to that conclusion? That is neither
|what I said, nor what I meant.
|
|There is no problem with inexperienced users, who are capable
|enough to know they are inexperienced (which of itself says
|very little) and who are willing to learn, and to recognise
|that learning means work.
|
|The best way for such users to become experienced, is by doing
|things, and that should start with the small things, of course,
|for which solutions can fairly easily be discovered.
|
|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.
And the golden path is enabling.
Yeah, do not make turtle soup, let the turtles do smalltalk.
I just did
--- a/home/.shrc
+++ b/home/.shrc
@@ -99,6 +99,7 @@ eval "___isinc=\$___SHRC$$"
shopt -s expand_aliases
elif [ "${OSTYPE}" = netbsd ]; then
set -o cdprint -o emacs -o tabcomplete
+ (set -o promptcmds) >/dev/null 2>&1 && set -o promptcmds
fi
export HISTSIZE HISTFILE
last saturday after creating my NetBSD 9.3 VM, because i was given
a hand. (Iirc: again, and again, and again...-)
P.S.: i want to add i was sitting and saying your first two
sentences this afternoon (in German).
Thanks, and Ciao from Germany. (That unfortunately sends lots of
military planes to your home country.)
--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
Re: sh(1) and ksh(1) default PATH
Hauke Fath wrote in <20220815111506408018.2367a...@espresso.rhein-neckar.de>: |On Sun, 14 Aug 2022 09:04:21 + (UTC), RVP wrote: |> Linux has a pam_env.so which reads /etc/environment and |> /etc/environment.d/* for this kind of thing. I was looking |> for something like that on NetBSD a while back... | |login.conf(5) can set PATH. And pam_env does a whole lotta things more, really. We have the very same discussion on #crux-devel, but there it was about the sole decision to create a /etc/profile with all sorts of XDG directories (.. i had written pam_xdg for those (also available on FreeBSD) but the one hates me ..), and the terrible -if [ "$UID" = "0" ]; then - export PATH="/sbin:/usr/sbin:/opt/sbin:/bin:/usr/bin:/opt/bin" -else - export PATH="/bin:/usr/bin:/opt/bin" -fi +export PATH="/sbin:/usr/sbin:/opt/sbin:/bin:/usr/bin:/opt/bin" change that _i_ hate. I also hate pam_env which came up here for the XDG variables (imagine this!), but it does _so much more_ that i personally would really hate to see that thing enabled _on each and every installation by default_. login.conf, yes! Or heck write a very simple PAM module (the NetBSD site contains fully fledged examples even) that only reads _one_ global configuration file at maximum, and sets some environment variables accordingly. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: stack overflow in getaddrinfo(3) with a small-sized stack in pthreads
Mouse wrote in <202111292115.qaa06...@stone.rodents-montreal.org>: |> * The maximum is 65000. | |It probably is actually 65535, or 65495, or some such; if there is a |limit that is actually 65000, it strikes me as unlikely to be anything |but someone imposing an artificial round-human-number limit. Don't mind, that referred to my own code only. You would (have) switch(ed) to TCP sooner that much is plain. Today .. i would write the stub resolver more primitively and simply rely upon some global local thing like dnsmasq or what per se; and hope that firefox-bin can be forced to use it, too. 'Night, --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: stack overflow in getaddrinfo(3) with a small-sized stack in pthreads
Joerg Sonnenberger wrote in : |On Mon, Nov 29, 2021 at 06:31:30PM +0100, Steffen Nurpmeso wrote: |> Joerg Sonnenberger wrote in |> : |>|On Mon, Nov 29, 2021 at 08:38:35PM +0700, Robert Elz wrote: |>|> DNS queries (via UDP) are limited to max 512, as that is what the |>|> protocol always required, so can be handled by everything (or should \ |>|> be). |>| |>|Strictly speaking, it is the minimum MTU every IPv4 implementation is |>|supposed to allow. IPv6 bumped it to 1280. |> |> RFC 1035 says |> |> 2.3.4. Size limits |> ... |> UDP messages512 octets or less |> |> If no EDNS is in use the answer should be pretty small also. |> Also see RFC 2671, but i have forgotten about all that. | |Both are predate IPv6 by ages and don't actually disagree with what I am |saying... No. I documented * \var conf_edns_size ... * The default is 1280 (RFC 2671, 4.5.1.). * The minimum is 1024 (RFC 3226, 3.; note: not 1220!). * The maximum is 65000. ..'just wanted to say that FreeBSD fixed aspects of FIONREAD just one or two (or so) weeks ago. |Joerg --End of --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: stack overflow in getaddrinfo(3) with a small-sized stack in pthreads
Joerg Sonnenberger wrote in : |On Mon, Nov 29, 2021 at 08:38:35PM +0700, Robert Elz wrote: |> DNS queries (via UDP) are limited to max 512, as that is what the |> protocol always required, so can be handled by everything (or should be). | |Strictly speaking, it is the minimum MTU every IPv4 implementation is |supposed to allow. IPv6 bumped it to 1280. RFC 1035 says 2.3.4. Size limits ... UDP messages512 octets or less If no EDNS is in use the answer should be pretty small also. Also see RFC 2671, but i have forgotten about all that. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: stack overflow in getaddrinfo(3) with a small-sized stack in pthreads
Steffen Nurpmeso wrote in <20211129173130.b55ba%stef...@sdaoden.eu>: |Joerg Sonnenberger wrote in | : ||On Mon, Nov 29, 2021 at 08:38:35PM +0700, Robert Elz wrote: ||> DNS queries (via UDP) are limited to max 512, as that is what the ||> protocol always required, so can be handled by everything (or should \ ||> be). || ||Strictly speaking, it is the minimum MTU every IPv4 implementation is ||supposed to allow. IPv6 bumped it to 1280. | |RFC 1035 says | | 2.3.4. Size limits | ... | UDP messages512 octets or less | |If no EDNS is in use the answer should be pretty small also. |Also see RFC 2671, but i have forgotten about all that. Ah ya the OPT RR also mentions MTU. Sorry. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: Possible "new" redirect style for /bin/sh (needs a name)
Greg A. Woods wrote in
:
|At Sun, 11 Apr 2021 01:37:44 +0700, Robert Elz wrote:
|Subject: Re: Possible "new" redirect style for /bin/sh (needs a name)
...
|Perhaps the current high FD watermark could even be exposed to the user
|with a new shell variable such as ${CUR_MAX_FD}, but also/instead the
I think this is a good idea. I think using 27>&- is not, i think
assigning to that one would be better, then.
...
|The only thing that immediately jumped into my mind was "dynamic
|redirection".
If starting with va_fds this could eventually end up as stdfds.
(Then VA_FDS_MIN or _START would come to mind.)
P.S.:
I really like the idea! For the MUA i maintain i long have the
idea of variable (I/O) redirections in mind, because for now the
terrible syntax is, for example
? vexpr + 1 1
0b 0010
02 | 0x2 | 2
? vput vexpr i + 1 1
? echo $i
2
Which was a way to make it work, which is better than not being
able. But it is really weird. Because of the syntax constraints,
i was thinking (and am still looking forward to) things like <
and > (and maybe |) prefixes (as in maybe "? >i vexpr"), but was not
yet sure how to differentiate in between variables (memory) and
file descriptors aka file names. Enclosing braces would be
a thing.
--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
Re: Summary of man-page formatting
Kamil Rytarowski wrote in <12f29556-2407-2f6f-de5c-67539bca6...@netbsd.org>: |I apologize for nerves and words that could be avoided. | |I'm going to summarize the situation with formatters in the NetBSD base. | |1. NetBSD base ships with two programs that can format manual pages from |base and most 3rd party software: BSD mandoc (newest) and GPLv2 groff |1.19.2 (old, from 2005). Not much good happened since then on the source side, i would even go back a bit further. |2. mandoc as of today renders correctly 99.8% of manual pages from I find mandoc formatting terrible when indentation is involved, really. It has been like that forever, and i was reading carefully already at a time where this number was much lower. For example compare ‘*!*’ the error number is tracked in !. ‘needs-box’ whether the command needs an active mailbox, a folder. ‘ok:’ indicators whether command is ... ‘batch/interactive’ usable in interactive or batch mode (-#). ‘send-mode’usable in send mode. ‘subprocess’ allowed to be used when running in a subprocess instance, for example from within a macro that is called via on-compose-splice. with ‘needs-box’ whether the command needs an active mailbox, a folder[199]. ‘ok:’indicators whether command is ... ‘batch/interactive’ usable in interactive or batch mode (-#[88]). ‘send-mode’ usable in send mode. ‘subprocess’ allowed to be used when running in a subprocess instance, for example from within a macro that is called via on-compose-splice[489]. or (purposes). ‘content-description’ Associate some descriptive information to the attachment's content, used in favour of the plain filename by some MUAs. ‘content-id’ May be used for uniquely identifying MIME with for) saving (purposes). ‘content-description’ Associate some descriptive information to the attachment's con‐ tent, used in favour of the plain filename by some MUAs. ‘content-id’ May be used for uniquely identify‐ ing MIME entities in several con‐ texts; this expects a special refer‐ all moved to the left to fit in this message, but otherwise just taken the output i get. I wonder why you (or anyone else) never recognized these differences. Technically you are correct, of course. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: Proposal to remove catman(8)
Jaromír Doleček wrote in
:
|Le mar. 10 nov. 2020 à 23:45, Mouse a écrit :
|> And, of course, when you're up single-user is, generally, when you're
|> least able to bring other tools to bear or the like, and when you're
|> possibly most likely need to know how to use a command you don't use
|> enough to have memorized. Fortunately, in this case I wasn't trying to
|> recover a half-crashed system; nroff | less actually did work.
|
|OK, I see here a suggestion that in the year 2020, installed catpages
|save the day as the only way how to get a formatted manpage for
|publicly available operating system while in single-user without a
|read-write /tmp. And that is the reason to keep the tool in base. For
|the record, I find this suggestion really bizzare.
|
|It really looks like arguing just for arguing sake.
I will start creating cat pages for the next release
automatically, 'added manually for the last months ago, in order
to support old Solaris (Schily) aka Solaris/XXX which do not have
the mdoc(7) macro package.
# And generate the HTML manual, while here
if [ -z "${grappa}" ] && command -v ${roff} >/dev/null 2>&1; then
echo 'nail.1: creating HTML manual'
< nail.1 MDOCMX_ENABLE=1 ${roff} -Thtml -mdoc > /tmp/nail-manual.html
echo 'nail.1: creating ASCII cat1 in '"${TMPDIR}"
< nail.1 MDOCMX_ENABLE= ${roff} -Tascii -mdoc > "${TMPDIR}"/s-nail.cat1
echo 'nail.1: creating mdocmx ASCII xcat1 in '"${TMPDIR}"
< nail.1 MDOCMX_ENABLE=1 GROFF_NO_SGR=1 \
${roff} -Tascii -dmx-toc-force=tree -dmx-debug=1 -mdoc |
col -b > "${TMPDIR}"/s-nail.xcat1
fi
Yieeeha! (Btw a system with /rescue is _so_ cool!)
--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
Re: Moving telnet/telnetd from base to pkgsrc
Greg Troxel wrote in : |Robert Elz writes: | |> It does no harm as it is, if you don't use the client, all it does is |> occupy a couple of hundred blocks (nothing), the server is not |> enabled by default, and it is even smaller. | |I agree. I use it often, to see if TCP ports are open and hand-type |smtp or http. | |Another point is that as a BSD system, we at least used to have a |respect for history and tradition. That has to have a balance - we did |get rid of sendmail. But removing longstanding programs (that don't run |by default) because some people don't like them, as part of what feels |like a larger deletionist crusade, is not ok. I like that. --End of --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: Future shell work - comments reqyuested
Robert Elz wrote: || I think the standard says IN and ERR rather than IN and OUT for || this condition?! | |It does, but we implement the latter (always have I think) - not sure |whether that should be changed or not, or what the effects might be. Yes, it does. If possible it should be changed, then. At least in $POSIXLY_CORRECT / posix mode. I think the virtue would be to be standard compliant while still being able to rock it. || fact it seems i never understood why this should be in and err, | |They are the fd's that the shell (as distinct from utilities that it |runs, including built in ones) actually read from and write to. Not to forget out!! || i think i thought use cases like "< template prog" to start into || interactive mode should be valid. | |That wouldn't just start, it would start and finish. When the shell |reads eof on its input file (stdin in a case like this) it exits. My console library only supports fullscreen mode. I don't know, for that "< template prog 2>err.log" could very well have been a valid interactive case, too. It was an error to hard code that dependency, i see this now. For the MUA i think i should try to end up with a logically sensitive detection of "interactive", possibly allowing the user to force interactivity. Unfortunately -i is given to "ignore SIGINT", only -I could be used. |But perhaps I am misunderstanding what you meant? Oh, it is ok to talk about a shell. We are learning from that. |It is possible to do | | sh -sic '. template' | |to start an interactive shell after reading a template file (the -i works |there because -s is also specified.) And there is a lot to learn. .. Interesting, this seems to be a speciality of the Almquist SHell, bash and mksh simply logout ?0[sdaoden@wales sdaoden]$ echo 'echo bla'|sh -sic 'echo da' da Logging out ... and: ?0[sdaoden@wales sdaoden]$ sh -sic 'echo da' da Logging out ... and: dash logs out only the former. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: Future shell work - comments reqyuested
Robert Elz wrote: |I have more or less finished work on shell arithmetic, completing the |currently missing (not posix required, but allowed) operators, that is |the unary ++, -- (prefix & postfix) and the ',' operator. There's |nothing much to say (or ask) about that, but... A pretty impressive run, if that comment is allowed! ... |Second, the -i (iinteractive) flag to sh is handled quite strangely on |the command line.After the shell has started it can be turned on or |off at will (doing so is not often an intelligent thing to do, but it |does have some uses.) But on the command line, unlike all other options, |it cannot simply be set - the shell deduces it is interactive when input |is from stdin, and stdin and stdout are ttys, and -i can be set, but only |in conjunction with -s. I think the standard says IN and ERR rather than IN and OUT for this condition?! One more problem i cannot handle in my MUA (currently, for the upcoming release), which unfortunately uses IN and OUT for that purpose. My console library used out and err, in fact it seems i never understood why this should be in and err, i think i thought use cases like "< template prog" to start into interactive mode should be valid. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)
Re: Restricting rdtsc [was: kernel aslr]
Maxime Villard wrote:
|Having read several papers on the exploitation of cache latency to defeat
|aslr (kernel or not), it appears that disabling the rdtsc instruction is a
|good mitigation on x86. However, some applications can legitimately use it,
|so I would rather suggest restricting it to root instead.
I have used it for random noise in user space. I don't want to
paste it, it is so ridiculous…, but then again a nice example of
user space horror – you may skip the rest at your will.
|The idea is simple: we set CR4_TSD in %cr4, the first time an application
|uses rdtsc it faults, we look at the creds of the lwp, if it is root we
I used it to add noise to my ARC4 random generator upon ()()/call()
time, as in
// strong (noisy) generator?
if(m_d.flags & f_strong) {
#if(__HAVE_RAND_CRYPTOHW)
if(__RAND_CRYPTOHW_OK) {
ret = ::__sf_sys_misc_rand_Strong();
goto jout;
} else
#endif
addNoise();
}
where this was
#if(__HAVE_RAND_CRYPTOHW)
if(!m_d.enpy)
goto jout;
#endif
#if(!__HAVE_RAND_NOISE)
ep.now().setSecond(ep.second() ^ ep.microsecond())
.setMicrosecond(_WEAK(ep.microsecond()));
addNoise(ep.tv(), szof(Epoch::TimeVal));
#else
x = ::__sf_sys_misc_rand_Noise();
stack[0] = x;
x = _WEAK(x);
stack[1] = x;
addNoise(stack, szof(stack));
#endif
#if(__HAVE_RAND_CRYPTOHW)
jout:
#endif
and that with args did a loop that used "random" bytes of the
given "stack" as noise additions to the internal entropy (and
doing one ARC4 stir after each addition).
|What about this?
No longer of any value, it seems to me.
--steffen
Re: Environment settings not taken into account by (portable) bmake(1)?(!)
Taylor R Campbell wrote:
| Date: Sat, 05 Nov 2016 18:47:54 +0100
| From: Steffen Nurpmeso
|
| I am currently fixing the build system of the MUA i maintain
| because the portable version of bmake looses CFLAGS (and LDFLAGS
| i think) from the environment.
|
|Can you share a small isolated example that demonstrates the problem
|you're observing? Certainly bmake does respect environment variables
|for make macro expansion:
|
|% printf 'x:;@echo ${CFLAGS}' | CFLAGS=abcd bmake -f /dev/stdin
|abcd
|% printf 'x:;@echo ${CFLAGS}' | bmake -f /dev/stdin CFLAGS=abcd
|abcd
|
|However, following POSIX, any assignments in the makefile itself
|override environment variables, unless you use the -e option:
...
There are no assignments, the file is
.SUFFIXES: .o .c .x .y
.c.o:
$(CC) -I./ $(CFLAGS) -c $(<)
.c.x:
$(CC) -I./ -E $(<) > $(@)
.c:
$(CC) -I./ $(CFLAGS) $(LDFLAGS) -o $(@) $(<)
But i see now that i already have needed such a fix two years back
for cross-compilation on Void Linux! The commit message reads
...
- make PREFIX=/usr ...
+ make CC=$CC PREFIX=/usr ...
i finally assume that environment variables that are defined by
make(1) itself by definition are not passed through to
subprocesses by the used make(1) but instead reset to the make(1)
default-ones. I have seen similar problems for S-CText, fixed
there for example on 2014-04-14 in [7cc84aa] by explicitly setting
the variable (as shown above) when calling those.
Let's see if that fixes Void Linux. If not i think we either have
to document this problem (as for UnixWare where you have to pass
-e, but which has unfortunate side-effects) or even replace the
...
and i think the standard leaves that undefined. Note however that
this fix was for a make(1) rule invoking $(SHELL) which in turn
starts other $(MAKE) instances (the fix was
-_prego = $(SHELL) ./mk-conf.sh
+_prego = SHELL="$(SHELL)" MAKE="$(MAKE)" \
+ CC="$(CC)" CFLAGS="$(CFLAGS)" LDFLAGS="$(LDFLAGS)" \
+ $(SHELL) ./mk-conf.sh
back then) but this time there is a direct invocation:
compile_check() {
variable=$1 topic=$2 define=$3
_check_preface "${variable}" "${topic}" "${define}"
if ${make} -f ${makefile} XINCS="${INCS}" \
^^^ $make==bmake, $makefile as above
CFLAGS="${CFLAGS}" LDFLAGS="${LDFLAGS}" \
^^^ this line new and fixes issue
./${tmp}.o &&
[ -f ./${tmp}.o ]; then
msg 'yes'
and then i think this is not quite right given that CFLAGS and
LDFLAGS are exported into the environment. I.e., my ~/.profile
exports CFLAGS='-01 -g' by default and i would be surprised if
that isn't inherited! So the attached test program yields
?0[steffen@wales tmp]$ make=make sh bm.sh
clang -I./ -g -O -g -DBLA="-g -O -g" -o bm bm.c
ok
?0[steffen@wales tmp]$ make=smake sh bm.sh
...clang -I./ -g -O -g -DBLA="-g -O -g" -o bm bm.c
ok
?0[steffen@wales tmp]$ make=bmake sh bm.sh
cc -pipe -I./ -g -DBLA="-g" -o bm bm.c
no
Ciao.
--steffen
bm.sh
Description: Bourne shell script
Environment settings not taken into account by (portable) bmake(1)?(!)
Hello.
I am currently fixing the build system of the MUA i maintain
because the portable version of bmake looses CFLAGS (and LDFLAGS
i think) from the environment. I currently have no NetBSD (my
main machine died last year, my used one is small and
resource-restricted), but unlikely that this bug has been
introduced for the portable version?
?0[steffen@wales ]$ pacman -Si bmake
Repository : community
Name: bmake
Version : 20160926-1
Description : Portable version of the NetBSD 'make' build tool
Architecture: x86_64
URL : http://www.crufty.net/help/sjg/bmake.html
This diff fixes the issue for me.
- if ${make} -f ${makefile} XINCS="${INCS}" ./${tmp}.o &&
+ if ${make} -f ${makefile} CFLAGS="${CFLAGS}" LDFLAGS="${LDFLAGS}"
XINCS="${INCS}" ./${tmp}.o &&
Here $makefile is a very small file with inference rules and the
entire construct in a shell script?
Have a nice weekend, ciao.
--steffen
Re: pthread library related
Joerg Sonnenberger wrote: |On Mon, May 30, 2016 at 02:19:26PM -0700, Charles Cui wrote: |> good to know atomic_inc_uint_nv is implemented using cas. | |No, atomic_inc is *not* necessarily implemented using CAS. There are a What a pity. |couple of different ways to do it ranging from implicit serialisation on |UP-only systems over CAS/LL-SC loops to native locked inc instructions. |For the application program, it doesn't generally matter which it is. Remembering some atomic integer (inline) functions seen in the Linux Kernel (Alpha?) before discovering FreeBSD (v4.7), i'd rather go with cas (or even locked xchg if not otherwise possible) spinlocks (or noops without SMP) and a normal integer increment instead. You can even PAUSE. That was a good hardware addition. (Not that i have any idea of hardware.) --steffen
Re: pidfile_lock(3)
Hi. "James K. Lowden" wrote: |mlel...@serpens.de (Michael van Elst) wrote: |> r...@marples.name (Roy Marples) writes: |>>See here: |>>http://mail-index.netbsd.org/tech-userlevel/2016/03/21/msg009799.html Well, btw., the MUA i maintain forks, keeping a communication pipe to its parent, then creates the dotlock file, lingering on the channel to get the "delete file" info. Shall the parent die the channel will close, which also counts as "delete file". Thus there will be no lingering pid file unless someone maliciously kills that child or the system crashes: unfortunately there exists no O_ flag that could be used to overcome the latter problem, something that would allow file deletion but keep the name in the in-memory VFS layer, so to say, unless the reference goes. But that can't be helped from userspace. --steffen
