Re: include cpuid 0 string in dmesg for fw_update
On Sun, Jul 24, 2022 at 10:34:04AM -0700, Andrew Hewus Fresh wrote:
> I'll try to think about whether I can build a sed program that will
> spit out matches.
Unfortunately the sed version seems to be even slower than matching one
line at a time. Just building the patterns for sed is slower than the
original single match.
--- fw_update.sh.orig Sun Jul 24 10:07:40 2022
+++ fw_update.shSun Jul 24 20:50:02 2022
@@ -168,22 +168,34 @@
}
firmware_in_dmesg() {
- local _d _m _line _dmesgtail _last='' _nl=$( echo )
+ local _cmd
- # The dmesg can contain multiple boots, only look in the last one
- _dmesgtail="$( echo ; sed -n 'H;/^OpenBSD/h;${g;p;}'
/var/run/dmesg.boot )"
-
- grep -v '^[[:space:]]*#' "$FWPATTERNS" |
+ _cmd="$( grep -v '^[[:space:]]*#' "$FWPATTERNS" | (
+ _s='/^%s/i\\\n%s\n'
+ _last=
+ _patterns=
while read -r _d _m; do
- [ "$_d" = "$_last" ] && continue
- [ "$_m" ] || _m="${_nl}${_d}[0-9] at "
- [ "$_m" = "${_m#^}" ] || _m="${_nl}${_m#^}"
+ [ "$_m" ] || _m="^${_d}[0-9] at "
+ [ "$_m" = "${_m#*/}" ] || _m="$( printf "$_m" | sed 's,/,\\/,g'
)"
- if [[ $_dmesgtail = *$_m* ]]; then
- echo "$_d"
- _last="$_d"
+ if [ "$_patterns" ] && [ "$_d" != "$_last" ]; then
+ printf "$_s" "$_patterns" "$_last"
+ _last=
+ _patterns=
fi
+
+ _last="$_d"
+ if [ "$_patterns" ]; then
+ _patterns="$_patterns|$_m"
+ else
+ _patterns="$_m"
+ fi
done
+ [ "$_patterns" ] && printf "$_s" "$_patterns" "$_last"
+ ) )"
+
+ # The dmesg can contain multiple boots, only look in the last one
+ sed -n 'H;/^OpenBSD/h;${g;p;}' /var/run/dmesg.boot | sed -En "$_cmd"
}
firmware_filename() {
Re: powerpc64: retrigger deferred DEC interrupts from splx(9)
On Sat, Jul 23, 2022 at 08:14:32PM -0500, Scott Cheloha wrote:
>
> [...]
>
> I don't have a powerpc64 machine, so this is untested. [...]
gkoehler@ has pointed out two dumb typos in the prior patch. My bad.
Here is a corrected patch that, according to gkoehler@, actually
compiles.
Index: include/cpu.h
===
RCS file: /cvs/src/sys/arch/powerpc64/include/cpu.h,v
retrieving revision 1.31
diff -u -p -r1.31 cpu.h
--- include/cpu.h 6 Jul 2021 09:34:07 - 1.31
+++ include/cpu.h 25 Jul 2022 00:30:33 -
@@ -74,9 +74,9 @@ struct cpu_info {
uint64_tci_lasttb;
uint64_tci_nexttimerevent;
uint64_tci_nextstatevent;
- int ci_statspending;
volatile intci_cpl;
+ volatile intci_dec_deferred;
uint32_tci_ipending;
uint32_tci_idepth;
#ifdef DIAGNOSTIC
Index: powerpc64/clock.c
===
RCS file: /cvs/src/sys/arch/powerpc64/powerpc64/clock.c,v
retrieving revision 1.3
diff -u -p -r1.3 clock.c
--- powerpc64/clock.c 23 Feb 2021 04:44:31 - 1.3
+++ powerpc64/clock.c 25 Jul 2022 00:30:33 -
@@ -130,30 +130,23 @@ decr_intr(struct trapframe *frame)
mtdec(nextevent - tb);
mtdec(nextevent - mftb());
- if (ci->ci_cpl >= IPL_CLOCK) {
- ci->ci_statspending += nstats;
- } else {
- nstats += ci->ci_statspending;
- ci->ci_statspending = 0;
+ s = splclock();
+ intr_enable();
- s = splclock();
- intr_enable();
-
- /*
-* Do standard timer interrupt stuff.
-*/
- while (ci->ci_lasttb < prevtb) {
- ci->ci_lasttb += tick_increment;
- clock_count.ec_count++;
- hardclock((struct clockframe *)frame);
- }
+ /*
+* Do standard timer interrupt stuff.
+*/
+ while (ci->ci_lasttb < prevtb) {
+ ci->ci_lasttb += tick_increment;
+ clock_count.ec_count++;
+ hardclock((struct clockframe *)frame);
+ }
- while (nstats-- > 0)
- statclock((struct clockframe *)frame);
+ while (nstats-- > 0)
+ statclock((struct clockframe *)frame);
- intr_disable();
- splx(s);
- }
+ intr_disable();
+ splx(s);
}
void
Index: powerpc64/intr.c
===
RCS file: /cvs/src/sys/arch/powerpc64/powerpc64/intr.c,v
retrieving revision 1.9
diff -u -p -r1.9 intr.c
--- powerpc64/intr.c26 Sep 2020 17:56:54 - 1.9
+++ powerpc64/intr.c25 Jul 2022 00:30:33 -
@@ -139,6 +139,11 @@ splx(int new)
{
struct cpu_info *ci = curcpu();
+ if (ci->ci_dec_deferred && new < IPL_CLOCK) {
+ mtdec(0);
+ mtdec(UINT32_MAX); /* raise DEC exception */
+ }
+
if (ci->ci_ipending & intr_smask[new])
intr_do_pending(new);
Index: powerpc64/trap.c
===
RCS file: /cvs/src/sys/arch/powerpc64/powerpc64/trap.c,v
retrieving revision 1.51
diff -u -p -r1.51 trap.c
--- powerpc64/trap.c11 May 2021 18:21:12 - 1.51
+++ powerpc64/trap.c25 Jul 2022 00:30:33 -
@@ -65,9 +65,15 @@ trap(struct trapframe *frame)
switch (type) {
case EXC_DECR:
uvmexp.intrs++;
- ci->ci_idepth++;
- decr_intr(frame);
- ci->ci_idepth--;
+ if (ci->ci_cpl < IPL_CLOCK) {
+ ci->ci_dec_deferred = 0;
+ ci->ci_idepth++;
+ decr_intr(frame);
+ ci->ci_idepth--;
+ } else {
+ ci->ci_dec_deferred = 1;
+ mtdec(UINT32_MAX >> 1); /* clear DEC exception */
+ }
return;
case EXC_EXI:
uvmexp.intrs++;
Re: ssh_config.5: Document TOKEN support in ForwardAgent
On Sun, Jul 24, 2022 at 06:50:10PM +, Klemens Nanni wrote: > Just like IdentityAgent; tested with `-o ForwardAgent='~/test.sock'`. The behaviour of ForwardAgent is still confusing me and having read the code for IdentityAgent and ForwardAgent parsing just raises more questions. Please disregard this diff until I come up with more substantial stuff.
Re: include cpuid 0 string in dmesg for fw_update
On 2022/07/24 10:34, Andrew Hewus Fresh wrote: > On Sun, Jul 24, 2022 at 09:14:30AM -0700, Andrew Hewus Fresh wrote: > > On Sun, Jul 24, 2022 at 10:01:26AM -0600, Theo de Raadt wrote: > > > Jonathan Gray wrote: > > > > > > > On Sun, Jul 24, 2022 at 08:05:26AM -0600, Theo de Raadt wrote: > > > > > Why not match on cpu0: .*Intel > > > > > > > > I sent a diff a month ago with ^cpu0:*Intel(R) > > > > > > > > semarie mentioned false positives as it could match another > > > > Intel device on another line on a non-Intel CPU > > > > > > > > https://marc.info/?l=openbsd-tech&m=165579653107768&w=2 Why bother about false positives? It doesn't really hurt, it's only 6MB.
ssh_config.5: Document TOKEN support in ForwardAgent
Just like IdentityAgent; tested with `-o ForwardAgent='~/test.sock'`. OK? Index: ssh_config.5 === RCS file: /cvs/src/usr.bin/ssh/ssh_config.5,v retrieving revision 1.373 diff -u -p -r1.373 ssh_config.5 --- ssh_config.524 Jun 2022 04:27:14 - 1.373 +++ ssh_config.524 Jul 2022 18:45:48 - @@ -748,6 +748,15 @@ an explicit path to an agent socket or t .Sq $ ) in which to find the path. .Pp +Arguments to +.Cm ForwardAgent +may use the tilde syntax to refer to a user's home directory, +the tokens described in the +.Sx TOKENS +section and environment variables as described in the +.Sx ENVIRONMENT VARIABLES +section. +.Pp Agent forwarding should be enabled with caution. Users with the ability to bypass file permissions on the remote host (for the agent's Unix-domain socket)
Re: include cpuid 0 string in dmesg for fw_update
On Sun, Jul 24, 2022 at 09:14:30AM -0700, Andrew Hewus Fresh wrote:
> On Sun, Jul 24, 2022 at 10:01:26AM -0600, Theo de Raadt wrote:
> > Jonathan Gray wrote:
> >
> > > On Sun, Jul 24, 2022 at 08:05:26AM -0600, Theo de Raadt wrote:
> > > > Why not match on cpu0: .*Intel
> > >
> > > I sent a diff a month ago with ^cpu0:*Intel(R)
> > >
> > > semarie mentioned false positives as it could match another
> > > Intel device on another line on a non-Intel CPU
> > >
> > > https://marc.info/?l=openbsd-tech&m=165579653107768&w=2
> >
> > Well, then fw_update should be fixed to not perform the match over
> > multiple lines.
>
> I'm looking at fixing fw_update to match each line instead of the whole
> dmesg. I'll try to get a patch out for that today.
This patch matches patterns against each line in the dmesg instead of
anchoring on newlines and matching against the entire string at once
anchored by newlines. This would mean that ^cpu0:*Intel(R) would Just
Work.
The problem is that it's a little over 3 times slower on my laptop to do
the matching this way. If any ksh folks have tricks to speed that up,
I'd appreciate it. I'll try to think about whether I can build a sed
program that will spit out matches. Sadly at the moment, distracted by
a non-computer project that has been taking up all my free time.
Hopefully that will be finished in the next couple weeks though.
I think I could do some magic to replace the "^cpu:*Intel(R)" above with
"^cpu:*([!\n])Intel(R)" (although not with directly as ksh wouldn't
recognize it). That would be annoying to implement though, but would
then still be able to do the faster single match.
--- fw_update.sh.orig Sun Jul 24 10:07:40 2022
+++ fw_update.shSun Jul 24 10:14:21 2022
@@ -168,21 +168,31 @@
}
firmware_in_dmesg() {
- local _d _m _line _dmesgtail _last='' _nl=$( echo )
+ local _d _m _line _dmesgtail _last='' _oldifs="$IFS"
+ IFS='
+'
# The dmesg can contain multiple boots, only look in the last one
- _dmesgtail="$( echo ; sed -n 'H;/^OpenBSD/h;${g;p;}'
/var/run/dmesg.boot )"
+ set -A _dmesgtail $( sed -n 'H;/^OpenBSD/h;${g;p;}' /var/run/dmesg.boot
)
+ IFS="$_oldifs"
grep -v '^[[:space:]]*#' "$FWPATTERNS" |
while read -r _d _m; do
[ "$_d" = "$_last" ] && continue
- [ "$_m" ] || _m="${_nl}${_d}[0-9] at "
- [ "$_m" = "${_m#^}" ] || _m="${_nl}${_m#^}"
-
- if [[ $_dmesgtail = *$_m* ]]; then
- echo "$_d"
- _last="$_d"
+ [ "$_m" ] || _m="^${_d}[0-9] at "
+ if [ "$_m" = "${_m#^}" ]; then
+ _m="*$_m"
+ else
+ _m="${_m#^}"
fi
+
+ for _line in "${_dmesgtail[@]}"; do
+ if [[ $_line = $_m* ]]; then
+ echo "$_d"
+ _last="$_d"
+ break
+ fi
+ done
done
}
Re: include cpuid 0 string in dmesg for fw_update
On Sun, Jul 24, 2022 at 10:01:26AM -0600, Theo de Raadt wrote: > Jonathan Gray wrote: > > > On Sun, Jul 24, 2022 at 08:05:26AM -0600, Theo de Raadt wrote: > > > Why not match on cpu0: .*Intel > > > > I sent a diff a month ago with ^cpu0:*Intel(R) > > > > semarie mentioned false positives as it could match another > > Intel device on another line on a non-Intel CPU > > > > https://marc.info/?l=openbsd-tech&m=165579653107768&w=2 > > Well, then fw_update should be fixed to not perform the match over > multiple lines. I'm looking at fixing fw_update to match each line instead of the whole dmesg. I'll try to get a patch out for that today. > Absolutely noone expects a pattern containing '^' to match over > multiple lines. It is only a matter of time before another pattern > acts wrong, so I think fw_update should get a proper line-matcher > so that the pattern ^cpu0: *Intel' can be used. Agreed.
Re: include cpuid 0 string in dmesg for fw_update
Jonathan Gray wrote: > On Sun, Jul 24, 2022 at 08:05:26AM -0600, Theo de Raadt wrote: > > Why not match on cpu0: .*Intel > > I sent a diff a month ago with ^cpu0:*Intel(R) > > semarie mentioned false positives as it could match another > Intel device on another line on a non-Intel CPU > > https://marc.info/?l=openbsd-tech&m=165579653107768&w=2 Well, then fw_update should be fixed to not perform the match over multiple lines. Absolutely noone expects a pattern containing '^' to match over multiple lines. It is only a matter of time before another pattern acts wrong, so I think fw_update should get a proper line-matcher so that the pattern ^cpu0: *Intel' can be used.
Re: include cpuid 0 string in dmesg for fw_update
On Sun, Jul 24, 2022 at 08:05:26AM -0600, Theo de Raadt wrote: > Why not match on cpu0: .*Intel I sent a diff a month ago with ^cpu0:*Intel(R) semarie mentioned false positives as it could match another Intel device on another line on a non-Intel CPU https://marc.info/?l=openbsd-tech&m=165579653107768&w=2
Re: include cpuid 0 string in dmesg for fw_update
> Date: Sun, 24 Jul 2022 15:48:26 +1000
> From: Jonathan Gray
>
> include cpuid 0 string in dmesg for fw_update
>
> Intel CPUs used to have brand strings such as
> cpu0: Intel(R) Pentium(R) M processor 1200MHz ("GenuineIntel" 686-class) 1.20
> GHz
> cpu0: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz, 2494.61 MHz, 06-3d-04
> recent CPUs use
> cpu0: 11th Gen Intel(R) Core(TM) i5-1130G7 @ 1.10GHz, 30009.37 MHz, 06-8c-01
> cpu0: 12th Gen Intel(R) Core(TM) i5-12400, 4390.71 MHz, 06-97-02
> cpu0: 12th Gen Intel(R) Core(TM) i7-1260P, 1995.55 MHz, 06-9a-03
>
> after the diff:
>
> amd64:
> cpu0: GenuineIntel, 12th Gen Intel(R) Core(TM) i7-1260P, 1995.55 MHz, 06-9a-03
> cpu0: AuthenticAMD, AMD Ryzen 5 2600X Six-Core Processor, 3593.83 MHz,
> 17-08-02
>
> i386:
> cpu0: GenuineIntel, Intel(R) Pentium(R) M processor 1.60GHz (686-class) 1.60
> GHz, 06-0d-06
>
> changes the output of hw.model on i386 to not include the cpuid 0 string
Ugh, this is ugly.
> Index: sys/arch/amd64/amd64/identcpu.c
> ===
> RCS file: /cvs/src/sys/arch/amd64/amd64/identcpu.c,v
> retrieving revision 1.125
> diff -u -p -r1.125 identcpu.c
> --- sys/arch/amd64/amd64/identcpu.c 12 Jul 2022 04:46:00 - 1.125
> +++ sys/arch/amd64/amd64/identcpu.c 24 Jul 2022 05:14:07 -
> @@ -516,6 +516,11 @@ identifycpu(struct cpu_info *ci)
> int i;
> char *brandstr_from, *brandstr_to;
> int skipspace;
> + uint32_t vendor_regs[3];
> + char vendor[13];
> +
> + CPUID(0, dummy, vendor_regs[0], vendor_regs[2], vendor_regs[1]);
> + strlcpy(vendor, (char *)vendor_regs, sizeof(vendor));
>
> CPUID(1, ci->ci_signature, val, dummy, ci->ci_feature_flags);
> CPUID(0x8000, ci->ci_pnfeatset, dummy, dummy, dummy);
> @@ -605,7 +610,7 @@ identifycpu(struct cpu_info *ci)
>
> freq = cpu_freq(ci);
>
> - printf("%s: %s", ci->ci_dev->dv_xname, mycpu_model);
> + printf("%s: %s, %s", ci->ci_dev->dv_xname, vendor, mycpu_model);
>
> if (freq != 0)
> printf(", %llu.%02llu MHz", (freq + 4999) / 100,
> Index: sys/arch/i386/i386/machdep.c
> ===
> RCS file: /cvs/src/sys/arch/i386/i386/machdep.c,v
> retrieving revision 1.650
> diff -u -p -r1.650 machdep.c
> --- sys/arch/i386/i386/machdep.c 12 Jul 2022 05:45:49 - 1.650
> +++ sys/arch/i386/i386/machdep.c 24 Jul 2022 04:45:20 -
> @@ -1891,19 +1891,18 @@ identifycpu(struct cpu_info *ci)
>
> if (cachesize > -1) {
> snprintf(cpu_model, sizeof(cpu_model),
> - "%s (%s%s%s%s-class, %dKB L2 cache)",
> - cpu_brandstr,
> - ((*token) ? "\"" : ""), ((*token) ? token : ""),
> - ((*token) ? "\" " : ""), classnames[class], cachesize);
> + "%s (%s-class, %dKB L2 cache)",
> + cpu_brandstr, classnames[class], cachesize);
> } else {
> snprintf(cpu_model, sizeof(cpu_model),
> - "%s (%s%s%s%s-class)",
> - cpu_brandstr,
> - ((*token) ? "\"" : ""), ((*token) ? token : ""),
> - ((*token) ? "\" " : ""), classnames[class]);
> + "%s (%s-class)",
> + cpu_brandstr, classnames[class]);
> }
>
> - printf("%s: %s", cpu_device, cpu_model);
> + if (*token)
> + printf("%s: %s, %s", cpu_device, token, cpu_model);
> + else
> + printf("%s: %s", cpu_device, cpu_model);
>
> if (ci->ci_feature_flags && (ci->ci_feature_flags & CPUID_TSC)) {
> /* Has TSC, check if it's constant */
> Index: usr.sbin/fw_update/patterns.c
> ===
> RCS file: /cvs/src/usr.sbin/fw_update/patterns.c,v
> retrieving revision 1.3
> diff -u -p -r1.3 patterns.c
> --- usr.sbin/fw_update/patterns.c 10 Mar 2022 07:12:13 - 1.3
> +++ usr.sbin/fw_update/patterns.c 24 Jul 2022 05:36:11 -
> @@ -94,7 +94,7 @@ main(void)
> printf("%s\n", "bwfm");
> printf("%s\n", "bwi");
> printf("%s\n", "intel");
> - printf("%s\n", "intel ^cpu0: Intel");
> + printf("%s\n", "intel ^cpu0: GenuineIntel");
> printf("%s\n", "inteldrm");
> print_devices("inteldrm", i915_devices, nitems(i915_devices));
> printf("%s\n", "ipw");
>
>
Re: Latest sysupgrade (23/07/2022) fails SHA256 check
On 2022/07/23 21:00, Chris Narkiewicz wrote: > Hi, > > I tried to sysupgade but it fails to check SHA256. Tried multiple times to > exclude random bit flip: > > Verifying sets. > (SHA256) bsd.mp: FAILED > > Sysupgrade on 23/07/2022. > > Best regards, > Chris Narkiewicz > If it persists, please let us know which mirror you are using.
OpenBSD Errata: July 24, 2022 (xserver cron)
Errata patches for X11 server and cron daemon have been released for OpenBSD 7.0 and 7.1. Binary updates for the amd64, i386 and arm64 platform are available via the syspatch utility. Source code patches can be found on the respective errata page: https://www.openbsd.org/errata71.html https://www.openbsd.org/errata70.html
Re: remove rise detection from i386
On Sun, Jul 24, 2022 at 2:55 AM Jonathan Gray wrote: > > On Sun, Jul 24, 2022 at 02:16:23AM -0400, Daniel Dickman wrote: > >http://datasheets.chipdb.org/Rise/ > > > >Quoting the data sheet from this link: > > > >“The CMPXCHG8B instruction is supported and always enabled on the Rise > >mP6 processor; however, the default CPUID function bit is set to 0 to > >circumvent a reported bug in Windows NT” > > > >I don’t think we have a workaround for this quirk so I’m not sure > >there’s value in keeping the cpu ID code. > > The kernel shows if the CX8 bit is set, but doesn't use it otherwise. Agree. I think on this CPU the only consequence is that CX8 won't be shown in dmesg. The quirk needed would be to detect the Rise CPU and force showing CX8. But probably no real consequence beyond that as you say. > The toolchain assumes it exists as we default to -march=i586 since 2020. > I'd expect a mP6 to boot just not be as recognised after the diff. Makes sense. > > Still ok with the original diff. Will commit soon unless someone shows up saying they have a Rise CPU and they'd like to keep this code.
Re: include cpuid 0 string in dmesg for fw_update
Why not match on cpu0: .*Intel
Re: quiz(6): fully switch to getline(3)
Ben Fuller wrote:
> Did anyone have a look at this? Feedback is appreciated.
>
> On Sun, Jul 03, 2022 at 02:31:42 +0100, Ben Fuller wrote:
> > One of the fgetln(3)s was previously converted to getline(3), but not
> > the other.
> >
> > diff --git games/quiz/quiz.c games/quiz/quiz.c
> > index d4fd0604e0d..362fb1e24a8 100644
> > --- games/quiz/quiz.c
> > +++ games/quiz/quiz.c
> > @@ -224,7 +224,8 @@ quiz(void)
> > {
> > QE *qp;
> > int i;
> > - size_t len;
> > + size_t size;
> > + ssize_t len;
> > u_int guesses, rights, wrongs;
> > int next;
> > char *answer, *t, question[LINE_SZ];
> > @@ -275,12 +276,15 @@ quiz(void)
> > qp->q_answered = TRUE;
> > continue;
> > }
> > + size = 0;
> > + answer = NULL;
here you're leaking memory.
This whole block is in a loop so you're possibly overriding the memory
allocated in a previous cycle. size and answer should be initialized
outside of the loop.
otherwise the diff reads fine to me and game works fine.
> > qp->q_asked = TRUE;
> > (void)printf("%s?\n", question);
> > for (;; ++guesses) {
> > - if ((answer = fgetln(stdin, &len)) == NULL ||
> > + if ((len = getline(&answer, &size, stdin)) == -1 ||
> > answer[len - 1] != '\n') {
> > score(rights, wrongs, guesses);
> > + free(answer);
> > exit(0);
> > [...]
however, while limiting ourselves to replace fgetln with getline in
quiz(6) only? other games could take advantage of that :)
(i couldn't help myself not to tweak save_file_name in battlestar too)
briefly (play)tested the affected games, everything seems fine.
ok?
diff /usr/src
commit - faf550173e173cd2ef8642601dc48202a09fd44f
path + /usr/src
blob - f7b08498dfdda4b4021212344862399e3c71728b
file + games/battlestar/cypher.c
--- games/battlestar/cypher.c
+++ games/battlestar/cypher.c
@@ -84,8 +84,9 @@ cypher(void)
int n;
int junk;
int lflag = -1;
- char *filename, *rfilename;
- size_t filename_len;
+ char *line = NULL, *filename;
+ size_t linesize = 0;
+ ssize_t linelen;
while (wordnumber <= wordcount) {
if (wordtype[wordnumber] != VERB &&
@@ -357,19 +358,16 @@ cypher(void)
case SAVE:
printf("\nSave file name (default %s): ",
DEFAULT_SAVE_FILE);
- filename = fgetln(stdin, &filename_len);
- if (filename_len == 0
- || (filename_len == 1 && filename[0] == '\n'))
- rfilename = save_file_name(DEFAULT_SAVE_FILE,
- strlen(DEFAULT_SAVE_FILE));
+ linelen = getline(&line, &linesize, stdin);
+ if (linelen <= 1)
+ filename = save_file_name(DEFAULT_SAVE_FILE);
else {
- if (filename[filename_len - 1] == '\n')
- filename_len--;
- rfilename = save_file_name(filename,
- filename_len);
+ if (line[linelen - 1] == '\n')
+ line[linelen - 1] = '\0';
+ filename = save_file_name(line);
}
- save(rfilename);
- free(rfilename);
+ save(filename);
+ free(filename);
break;
case VERBOSE:
@@ -463,6 +461,9 @@ cypher(void)
}
if (!lflag)
newlocation();
+
+ free(line);
+
if (wordnumber < wordcount && !stop_cypher &&
(*words[wordnumber] == ',' || *words[wordnumber] == '.')) {
wordnumber++;
blob - 21f8dc722600d3e169260e6e885319864c856807
file + games/battlestar/extern.h
--- games/battlestar/extern.h
+++ games/battlestar/extern.h
@@ -357,7 +357,7 @@ void ravage(void);
void restore(const char *);
int ride(void);
void save(const char *);
-char *save_file_name(const char *, size_t);
+char *save_file_name(const char *);
int shoot(void);
int take(unsigned int[]);
int takeoff(void);
blob - 5c2044a918e667bc505d35a2f27718d4dad0ba4a
file + games/battlestar/init.c
--- games/battlestar/init.c
+++ games/battlestar/init.c
@@ -66,7 +66,7 @@ initialize(const char *filename)
for (p = dayobjs; p->room != 0; p++)
SetBit(location[p->room].objects, p->obj);
} else {
- savefile = save_file_name(filename, strlen(filename));
+ savefile = save_file_name(filename);
Re: pf.conf(5): document new anchors limit
On Sat, Jul 23, 2022 at 01:32:32PM +0100, Jason McIntyre wrote: > thanks, i've managed to fill in the blanks with your help/ looking for > oks now. This reads OK to me, thanks.
