fortune: allow to use symlinks
Hello, all.
This allows fortune(6) to open fortune files via symlinks.
Maybe this is a stupid idea, I dunno, but it seems inconsistent
that I can't put a symlink to my fortunes collection in
/usr/share/games/fortune and then simply call "fortune foo"
instead of "fortune /usr/local/share/games/fortune/ru/foo".
I decided to call readlink(2) explicitly rather than adding
check of file type being open, since that resulted in less code.
Ah, and yes, I have a port of Russian fortune files pending,
but that's for another list and another day.
So... okay/notokay anyone? :)
--
WBR,
Vadim Zhukov
Index: fortune.c
===
RCS file: /cvs/src/games/fortune/fortune/fortune.c,v
retrieving revision 1.60
diff -u -p -r1.60 fortune.c
--- fortune.c 10 Aug 2017 17:00:08 - 1.60
+++ fortune.c 14 Dec 2020 22:05:33 -
@@ -39,6 +39,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -388,8 +389,9 @@ add_file(int percent, char *file, char *
FILEDESC *parent)
{
FILEDESC*fp;
+ ssize_t lnklen;
int fd;
- char*path, *offensive;
+ char*path, *offensive, lnkpath[PATH_MAX];
boolwas_malloc;
boolisdir;
@@ -420,8 +422,22 @@ add_file(int percent, char *file, char *
}
DPRINTF(1, (stderr, "adding file \"%s\"\n", path));
+
over:
+ lnklen = readlink(path, lnkpath, PATH_MAX);
+ if (lnklen == -1) {
+ if (errno != EINVAL)
+ goto openfailed;
+ } else {
+ lnkpath[lnklen] = '\0';
+ if (was_malloc)
+ free(path);
+ path = strdup(lnkpath);
+ was_malloc = 1;
+ }
+
if ((fd = open(path, O_RDONLY)) < 0) {
+openfailed:
/*
* This is a sneak. If the user said -a, and if the
* file we're given isn't a file, we check to see if
Re: Remove variable count from kqueue_scan()
ok mvs@
> On 14 Dec 2020, at 18:40, Visa Hankala wrote:
>
> In function kqueue_scan(), variables count and nkev follow relation
> count + nkev == maxevents. The code becomes a bit simpler if count
> is removed.
>
> OK?
>
> Index: kern/kern_event.c
> ===
> RCS file: src/sys/kern/kern_event.c,v
> retrieving revision 1.147
> diff -u -p -r1.147 kern_event.c
> --- kern/kern_event.c 9 Dec 2020 18:58:19 - 1.147
> +++ kern/kern_event.c 14 Dec 2020 15:32:57 -
> @@ -950,13 +950,11 @@ kqueue_scan(struct kqueue_scan_state *sc
> {
> struct kqueue *kq = scan->kqs_kq;
> struct knote *kn;
> - int s, count, nkev = 0, error = 0;
> + int s, error = 0, nkev = 0;
>
> - count = maxevents;
> - if (count == 0)
> + if (maxevents == 0)
> goto done;
> retry:
> - KASSERT(count == maxevents);
> KASSERT(nkev == 0);
>
> if (kq->kq_state & KQ_DYING) {
> @@ -1005,7 +1003,7 @@ retry:
> }
>
> TAILQ_INSERT_HEAD(>kq_head, >kqs_start, kn_tqe);
> - while (count) {
> + while (nkev < maxevents) {
> kn = TAILQ_NEXT(>kqs_start, kn_tqe);
> if (kn->kn_filter == EVFILT_MARKER) {
> if (kn == >kqs_end)
> @@ -1042,7 +1040,6 @@ retry:
> *kevp = kn->kn_kevent;
> kevp++;
> nkev++;
> - count--;
> scan->kqs_nevent++;
>
> /*
>
Re: Double entry in /usr/src/lib/libcurses/curs_util.3
On Mon, Dec 14, 2020 at 09:06:21PM +, Stuart Henderson wrote: > > This is present in the latest release upstream, could you report it > there please? > https://invisible-island.net/ncurses/announce.html#h2-development > > SEE ALSO are usually in (at least roughly) alphabetical order so it's > probably the first one that wants removing. Here they seem to list curses > before curs_ in all files, which is out of strict order but seems like > it's intentional. > OK, sent upstream with first entry deleted. Chris Bennett
Re: Double entry in /usr/src/lib/libcurses/curs_util.3
On 2020/12/14 14:45, Chris Bennett wrote: > See also has a double entry. > > Chris Bennett This is present in the latest release upstream, could you report it there please? https://invisible-island.net/ncurses/announce.html#h2-development SEE ALSO are usually in (at least roughly) alphabetical order so it's probably the first one that wants removing. Here they seem to list curses before curs_ in all files, which is out of strict order but seems like it's intentional. > > Index: curs_util.3 > === > RCS file: /cvs/src/lib/libcurses/curs_util.3,v > retrieving revision 1.6 > diff -u -p -u -p -r1.6 curs_util.3 > --- curs_util.3 12 Jan 2010 23:21:59 - 1.6 > +++ curs_util.3 14 Dec 2020 20:41:51 - > @@ -250,8 +250,7 @@ be conditioned using NCURSES_VERSION. > \fBcurses\fR(3), > \fBcurs_initscr\fR(3), > \fBcurs_kernel\fR(3), > -\fBcurs_scr_dump\fR(3), > -\fBlegacy_coding\fR(3). > +\fBcurs_scr_dump\fR(3). > .\"# > .\"# The following sets edit modes for GNU EMACS > .\"# Local Variables: >
Double entry in /usr/src/lib/libcurses/curs_util.3
See also has a double entry. Chris Bennett Index: curs_util.3 === RCS file: /cvs/src/lib/libcurses/curs_util.3,v retrieving revision 1.6 diff -u -p -u -p -r1.6 curs_util.3 --- curs_util.3 12 Jan 2010 23:21:59 - 1.6 +++ curs_util.3 14 Dec 2020 20:41:51 - @@ -250,8 +250,7 @@ be conditioned using NCURSES_VERSION. \fBcurses\fR(3), \fBcurs_initscr\fR(3), \fBcurs_kernel\fR(3), -\fBcurs_scr_dump\fR(3), -\fBlegacy_coding\fR(3). +\fBcurs_scr_dump\fR(3). .\"# .\"# The following sets edit modes for GNU EMACS .\"# Local Variables:
Re: bgpd send side hold timer
Hi all,
This patch appears to be a very elegant solution to a thorny subtle
problem: what to do when a peer is not accepting new routing information
from you?
I've seen in the wild that some crashed BGP implementations continue to
be able to generate KEEPALIVE messages, and are able to TCP ACK
keepalives you are sending, but won't actually accept anything you send
to such a problematic peer. A red flag is when the peer keeps telling
you not to send it anything by signalling a TCP Receive Window of 0.
The consequences are quite dire: in situations like these you know for a
fact that the peer is operating based on stale routing information (you
have proof they are not accepting your KEEPALIVEs and more importantly
UPDATEs, as those are all stuck in your OutQ).
If a peer is not progressing new routing information coming from you,
how can we trust it was processing any updates coming from other
neighbors? Are the routes the peer told us in the past (what we have in
Adj-RIB-In) still valid? Seems unlikely to me... it seems safer to
destroy the BGP-4 session, log an error, and generate WITHDRAW messages
for all routes pointing towards the broken peer so the network can
converge to healthier paths.
IDR discussions here
https://mailarchive.ietf.org/arch/msg/idr/L9nWFBpW0Tci0c9DGfMoqC1j_sA/
OK job@
Kind regards,
Job
On Mon, Dec 14, 2020 at 06:45:47PM +0100, Claudio Jeker wrote:
> The BGP protocol has a keepalive packet which resets the hold timer when a
> packet is received. The problem is this covers only one side of the
> transmission. It seems that some BGP implementations fail to process
> messages in some cases but still send out KEEPALIVE packets. So bgpd
> thinks everything is fine even though no updates where processed by the
> other side (including our KEEPALIVE packets). The session is stuck in
> limbo and with it some prefixes and routes.
>
> Because of this I think it makes sense to add a send hold timer that is
> reset whenever a write call to the socket is made. If a socket does not
> become writable for holdtime seconds (90s by default) then the session is
> reset similar to the hold timer expiring because no data was received.
>
> This send holdtimer is not part of the BGP spec right now but looking at
> discussions on the IDR mailing list I assume something like this may be
> added at one point.
>
> I would like to know what other people think and would especially like to
> know if this diff causes session resets that should not happen.
>
> Cheers
> --
> :wq Claudio
>
>
> Index: bgpd.h
> ===
> RCS file: /cvs/src/usr.sbin/bgpd/bgpd.h,v
> retrieving revision 1.405
> diff -u -p -r1.405 bgpd.h
> --- bgpd.h5 Nov 2020 11:52:59 - 1.405
> +++ bgpd.h13 Dec 2020 14:56:47 -
> @@ -1467,6 +1467,7 @@ static const char * const timernames[] =
> "ConnectRetryTimer",
> "KeepaliveTimer",
> "HoldTimer",
> + "SendHoldTimer",
> "IdleHoldTimer",
> "IdleHoldResetTimer",
> "CarpUndemoteTimer",
> Index: session.c
> ===
> RCS file: /cvs/src/usr.sbin/bgpd/session.c,v
> retrieving revision 1.406
> diff -u -p -r1.406 session.c
> --- session.c 11 Dec 2020 12:00:01 - 1.406
> +++ session.c 13 Dec 2020 14:52:42 -
> @@ -373,6 +373,7 @@ session_main(int debug, int verbose)
> if ((pt = timer_nextisdue(>timers, now)) != NULL) {
> switch (pt->type) {
> case Timer_Hold:
> + case Timer_HoldSend:
> bgp_fsm(p, EVNT_TIMER_HOLDTIME);
> break;
> case Timer_ConnectRetry:
> @@ -597,6 +598,7 @@ bgp_fsm(struct peer *peer, enum session_
> switch (event) {
> case EVNT_START:
> timer_stop(>timers, Timer_Hold);
> + timer_stop(>timers, Timer_HoldSend);
> timer_stop(>timers, Timer_Keepalive);
> timer_stop(>timers, Timer_IdleHold);
>
> @@ -875,6 +877,7 @@ change_state(struct peer *peer, enum ses
> timer_stop(>timers, Timer_ConnectRetry);
> timer_stop(>timers, Timer_Keepalive);
> timer_stop(>timers, Timer_Hold);
> + timer_stop(>timers, Timer_HoldSend);
> timer_stop(>timers, Timer_IdleHold);
> timer_stop(>timers, Timer_IdleHoldReset);
> session_close_connection(peer);
> @@ -923,6 +926,7 @@ change_state(struct peer *peer, enum ses
> timer_stop(>timers, Timer_ConnectRetry);
> timer_stop(>timers, Timer_Keepalive);
> timer_stop(>timers, Timer_Hold);
> + timer_stop(>timers, Timer_HoldSend);
> timer_stop(>timers,
bgpd send side hold timer
The BGP protocol has a keepalive packet which resets the hold timer when a
packet is received. The problem is this covers only one side of the
transmission. It seems that some BGP implementations fail to process
messages in some cases but still send out KEEPALIVE packets. So bgpd
thinks everything is fine even though no updates where processed by the
other side (including our KEEPALIVE packets). The session is stuck in
limbo and with it some prefixes and routes.
Because of this I think it makes sense to add a send hold timer that is
reset whenever a write call to the socket is made. If a socket does not
become writable for holdtime seconds (90s by default) then the session is
reset similar to the hold timer expiring because no data was received.
This send holdtimer is not part of the BGP spec right now but looking at
discussions on the IDR mailing list I assume something like this may be
added at one point.
I would like to know what other people think and would especially like to
know if this diff causes session resets that should not happen.
Cheers
--
:wq Claudio
Index: bgpd.h
===
RCS file: /cvs/src/usr.sbin/bgpd/bgpd.h,v
retrieving revision 1.405
diff -u -p -r1.405 bgpd.h
--- bgpd.h 5 Nov 2020 11:52:59 - 1.405
+++ bgpd.h 13 Dec 2020 14:56:47 -
@@ -1467,6 +1467,7 @@ static const char * const timernames[] =
"ConnectRetryTimer",
"KeepaliveTimer",
"HoldTimer",
+ "SendHoldTimer",
"IdleHoldTimer",
"IdleHoldResetTimer",
"CarpUndemoteTimer",
Index: session.c
===
RCS file: /cvs/src/usr.sbin/bgpd/session.c,v
retrieving revision 1.406
diff -u -p -r1.406 session.c
--- session.c 11 Dec 2020 12:00:01 - 1.406
+++ session.c 13 Dec 2020 14:52:42 -
@@ -373,6 +373,7 @@ session_main(int debug, int verbose)
if ((pt = timer_nextisdue(>timers, now)) != NULL) {
switch (pt->type) {
case Timer_Hold:
+ case Timer_HoldSend:
bgp_fsm(p, EVNT_TIMER_HOLDTIME);
break;
case Timer_ConnectRetry:
@@ -597,6 +598,7 @@ bgp_fsm(struct peer *peer, enum session_
switch (event) {
case EVNT_START:
timer_stop(>timers, Timer_Hold);
+ timer_stop(>timers, Timer_HoldSend);
timer_stop(>timers, Timer_Keepalive);
timer_stop(>timers, Timer_IdleHold);
@@ -875,6 +877,7 @@ change_state(struct peer *peer, enum ses
timer_stop(>timers, Timer_ConnectRetry);
timer_stop(>timers, Timer_Keepalive);
timer_stop(>timers, Timer_Hold);
+ timer_stop(>timers, Timer_HoldSend);
timer_stop(>timers, Timer_IdleHold);
timer_stop(>timers, Timer_IdleHoldReset);
session_close_connection(peer);
@@ -923,6 +926,7 @@ change_state(struct peer *peer, enum ses
timer_stop(>timers, Timer_ConnectRetry);
timer_stop(>timers, Timer_Keepalive);
timer_stop(>timers, Timer_Hold);
+ timer_stop(>timers, Timer_HoldSend);
timer_stop(>timers, Timer_IdleHold);
timer_stop(>timers, Timer_IdleHoldReset);
session_close_connection(peer);
@@ -1780,6 +1784,8 @@ session_dispatch_msg(struct pollfd *pfd,
return (1);
}
p->stats.last_write = getmonotime();
+ if (p->holdtime > 0)
+ timer_set(>timers, Timer_HoldSend, p->holdtime);
if (p->throttled && p->wbuf.queued < SESS_MSG_LOW_MARK) {
if (imsg_rde(IMSG_XON, p->conf.id, NULL, 0) == -1)
log_peer_warn(>conf, "imsg_compose XON");
Index: session.h
===
RCS file: /cvs/src/usr.sbin/bgpd/session.h,v
retrieving revision 1.148
diff -u -p -r1.148 session.h
--- session.h 11 Dec 2020 12:00:01 - 1.148
+++ session.h 13 Dec 2020 14:52:17 -
@@ -180,6 +180,7 @@ enum Timer {
Timer_ConnectRetry,
Timer_Keepalive,
Timer_Hold,
+ Timer_HoldSend,
Timer_IdleHold,
Timer_IdleHoldReset,
Timer_CarpUndemote,
Remove variable count from kqueue_scan()
In function kqueue_scan(), variables count and nkev follow relation
count + nkev == maxevents. The code becomes a bit simpler if count
is removed.
OK?
Index: kern/kern_event.c
===
RCS file: src/sys/kern/kern_event.c,v
retrieving revision 1.147
diff -u -p -r1.147 kern_event.c
--- kern/kern_event.c 9 Dec 2020 18:58:19 - 1.147
+++ kern/kern_event.c 14 Dec 2020 15:32:57 -
@@ -950,13 +950,11 @@ kqueue_scan(struct kqueue_scan_state *sc
{
struct kqueue *kq = scan->kqs_kq;
struct knote *kn;
- int s, count, nkev = 0, error = 0;
+ int s, error = 0, nkev = 0;
- count = maxevents;
- if (count == 0)
+ if (maxevents == 0)
goto done;
retry:
- KASSERT(count == maxevents);
KASSERT(nkev == 0);
if (kq->kq_state & KQ_DYING) {
@@ -1005,7 +1003,7 @@ retry:
}
TAILQ_INSERT_HEAD(>kq_head, >kqs_start, kn_tqe);
- while (count) {
+ while (nkev < maxevents) {
kn = TAILQ_NEXT(>kqs_start, kn_tqe);
if (kn->kn_filter == EVFILT_MARKER) {
if (kn == >kqs_end)
@@ -1042,7 +1040,6 @@ retry:
*kevp = kn->kn_kevent;
kevp++;
nkev++;
- count--;
scan->kqs_nevent++;
/*
Re: rw_lock_held() & friends
On Mon, Dec 14, 2020 at 10:59:05AM -0300, Martin Pieuchot wrote:
> On 08/12/20(Tue) 14:39, Visa Hankala wrote:
> > On Mon, Dec 07, 2020 at 03:25:00PM -0300, Martin Pieuchot wrote:
> > > Simple diff below to add the rw_lock_held() as well as a read & write
> > > version.
> > >
> > > This allows us to reduce the difference with NetBSD in UVM by adding the
> > > following checks:
> > >
> > > KASSERT(rw_write_held(amap->am_lock));
> > >
> > > ok?
> > >
> > > Index: sys/rwlock.h
> > > ===
> > > RCS file: /cvs/src/sys/sys/rwlock.h,v
> > > retrieving revision 1.26
> > > diff -u -p -r1.26 rwlock.h
> > > --- sys/rwlock.h 16 Jul 2019 01:40:49 - 1.26
> > > +++ sys/rwlock.h 7 Dec 2020 18:22:03 -
> > > @@ -168,6 +168,11 @@ int rw_enter(struct rwlock *, int);
> > > void rw_exit(struct rwlock *);
> > > int rw_status(struct rwlock *);
> > >
> > > +#define rw_read_held(rwl) (rw_status(rwl) == RW_READ)
> > > +#define rw_write_held(rwl) (rw_status(rwl) == RW_WRITE)
> > > +#define rw_lock_held(rwl) (rw_write_held(rwl) ||
> > > rw_read_held(rwl))
> >
> > I think rw_lock_held() should invoke rw_status() only once. This would
> > reduce the overhead. It could even be a proper C function.
>
> As below?
Yes. OK visa@
> Index: sys/rwlock.h
> ===
> RCS file: /cvs/src/sys/sys/rwlock.h,v
> retrieving revision 1.26
> diff -u -p -r1.26 rwlock.h
> --- sys/rwlock.h 16 Jul 2019 01:40:49 - 1.26
> +++ sys/rwlock.h 14 Dec 2020 13:35:41 -
> @@ -168,6 +168,29 @@ int rw_enter(struct rwlock *, int);
> void rw_exit(struct rwlock *);
> int rw_status(struct rwlock *);
>
> +static inline int
> +rw_read_held(struct rwlock *rwl)
> +{
> + return (rw_status(rwl) == RW_READ);
> +}
> +
> +static inline int
> +rw_write_held(struct rwlock *rwl)
> +{
> + return (rw_status(rwl) == RW_WRITE);
> +}
> +
> +static inline int
> +rw_lock_held(struct rwlock *rwl)
> +{
> + int status;
> +
> + status = rw_status(rwl);
> +
> + return (status == RW_READ || status == RW_WRITE);
> +}
> +
> +
> void _rrw_init_flags(struct rrwlock *, const char *, int,
> const struct lock_type *);
> int rrw_enter(struct rrwlock *, int);
>
[diff] usr.sbin/smtpd: fix event handling upon exit
Hello,
Upon termination, the parent process will call parent_shutdown() which will in
turn call mproc_clear() to properly terminate IPC with child processes.
In mproc_clear(), event_del() is called but a check is lacking to ensure
event_add() was called prior to this.
On OpenBSD, this doesn’t seem to cause any issue but on other systems with a
different libevent, calling event_del() without a matching event_add() either
causes a runtime warning or a crash upon exit.
Gilles
diff --git a/usr.sbin/smtpd/mproc.c b/usr.sbin/smtpd/mproc.c
index bde229e1..dac38af2 100644
--- a/usr.sbin/smtpd/mproc.c
+++ b/usr.sbin/smtpd/mproc.c
@@ -90,7 +90,8 @@ mproc_clear(struct mproc *p)
{
log_debug("debug: clearing p=%s, fd=%d, pid=%d", p->name,
p->imsgbuf.fd, p->pid);
- event_del(>ev);
+ if (p->events)
+ event_del(>ev);
close(p->imsgbuf.fd);
imsg_clear(>imsgbuf);
}
Re: rw_lock_held() & friends
On 08/12/20(Tue) 14:39, Visa Hankala wrote:
> On Mon, Dec 07, 2020 at 03:25:00PM -0300, Martin Pieuchot wrote:
> > Simple diff below to add the rw_lock_held() as well as a read & write
> > version.
> >
> > This allows us to reduce the difference with NetBSD in UVM by adding the
> > following checks:
> >
> > KASSERT(rw_write_held(amap->am_lock));
> >
> > ok?
> >
> > Index: sys/rwlock.h
> > ===
> > RCS file: /cvs/src/sys/sys/rwlock.h,v
> > retrieving revision 1.26
> > diff -u -p -r1.26 rwlock.h
> > --- sys/rwlock.h16 Jul 2019 01:40:49 - 1.26
> > +++ sys/rwlock.h7 Dec 2020 18:22:03 -
> > @@ -168,6 +168,11 @@ intrw_enter(struct rwlock *, int);
> > void rw_exit(struct rwlock *);
> > intrw_status(struct rwlock *);
> >
> > +#definerw_read_held(rwl) (rw_status(rwl) == RW_READ)
> > +#definerw_write_held(rwl) (rw_status(rwl) == RW_WRITE)
> > +#definerw_lock_held(rwl) (rw_write_held(rwl) ||
> > rw_read_held(rwl))
>
> I think rw_lock_held() should invoke rw_status() only once. This would
> reduce the overhead. It could even be a proper C function.
As below?
Index: sys/rwlock.h
===
RCS file: /cvs/src/sys/sys/rwlock.h,v
retrieving revision 1.26
diff -u -p -r1.26 rwlock.h
--- sys/rwlock.h16 Jul 2019 01:40:49 - 1.26
+++ sys/rwlock.h14 Dec 2020 13:35:41 -
@@ -168,6 +168,29 @@ intrw_enter(struct rwlock *, int);
void rw_exit(struct rwlock *);
intrw_status(struct rwlock *);
+static inline int
+rw_read_held(struct rwlock *rwl)
+{
+ return (rw_status(rwl) == RW_READ);
+}
+
+static inline int
+rw_write_held(struct rwlock *rwl)
+{
+ return (rw_status(rwl) == RW_WRITE);
+}
+
+static inline int
+rw_lock_held(struct rwlock *rwl)
+{
+ int status;
+
+ status = rw_status(rwl);
+
+ return (status == RW_READ || status == RW_WRITE);
+}
+
+
void _rrw_init_flags(struct rrwlock *, const char *, int,
const struct lock_type *);
intrrw_enter(struct rrwlock *, int);
Re: diff: replace useless use of MCLGETL with MCLGET
On Sat, Dec 12, 2020 at 02:05:48PM +0100, Jan Klemkow wrote: > Thus, this diff removes '(void)' from the MCLGET macro > -#define MCLGET(m, how) (void) m_clget((m), (how), MCLBYTES) > +#define MCLGET(m, how) m_clget((m), (how), MCLBYTES) The MCLGET API is to add a cluster to an existing mbuf. Returning the mbuf changes that. I don't think a macro cleanup justifies an API change. bluhm
snmp - remove BER_TYPE_BOOLEAN
I can't find any reference in RFC2578 for a boolean type, nor have I
seen it in the wild and the TruthValue diff I just committed give me a
strong indication that this was added without any real reason.
OK to remove?
martijn@
Index: usr.bin/snmp/smi.c
===
RCS file: /cvs/src/usr.bin/snmp/smi.c,v
retrieving revision 1.13
diff -u -p -r1.13 smi.c
--- usr.bin/snmp/smi.c 14 Dec 2020 07:44:26 - 1.13
+++ usr.bin/snmp/smi.c 14 Dec 2020 11:12:29 -
@@ -95,9 +95,6 @@ smi_debug_elements(struct ber_element *r
case BER_TYPE_EOC:
fprintf(stderr, "end-of-content");
break;
- case BER_TYPE_BOOLEAN:
- fprintf(stderr, "boolean");
- break;
case BER_TYPE_INTEGER:
fprintf(stderr, "integer");
break;
@@ -196,9 +193,6 @@ smi_debug_elements(struct ber_element *r
goto invalid;
switch (root->be_encoding) {
- case BER_TYPE_BOOLEAN:
- fprintf(stderr, "%s", value);
- break;
case BER_TYPE_INTEGER:
case BER_TYPE_ENUMERATED:
fprintf(stderr, "value %s", value);
@@ -255,7 +249,6 @@ smi_print_element(struct ber_oid *oid, s
struct textconv tckey;
size_t len, i, slen;
long longv, ticks;
- int d;
int is_hex = 0, ret;
struct ber_oid o;
char strbuf[BUFSIZ];
@@ -277,17 +270,6 @@ smi_print_element(struct ber_oid *oid, s
}
switch (root->be_encoding) {
- case BER_TYPE_BOOLEAN:
- if (ober_get_boolean(root, ) == -1)
- goto fail;
- if (print_hint) {
- if (asprintf(, "INTEGER: %s(%d)",
- d ? "true" : "false", d) == -1)
- goto fail;
- } else
- if (asprintf(, "%s", d ? "true" : "false") == -1)
- goto fail;
- break;
case BER_TYPE_INTEGER:
case BER_TYPE_ENUMERATED:
if (ober_get_integer(root, ) == -1)
Index: usr.sbin/snmpd/smi.c
===
RCS file: /cvs/src/usr.sbin/snmpd/smi.c,v
retrieving revision 1.27
diff -u -p -r1.27 smi.c
--- usr.sbin/snmpd/smi.c24 Oct 2019 12:39:27 - 1.27
+++ usr.sbin/snmpd/smi.c14 Dec 2020 11:12:29 -
@@ -317,9 +317,6 @@ smi_debug_elements(struct ber_element *r
case BER_TYPE_EOC:
fprintf(stderr, "end-of-content");
break;
- case BER_TYPE_BOOLEAN:
- fprintf(stderr, "boolean");
- break;
case BER_TYPE_INTEGER:
fprintf(stderr, "integer");
break;
@@ -417,9 +414,6 @@ smi_debug_elements(struct ber_element *r
goto invalid;
switch (root->be_encoding) {
- case BER_TYPE_BOOLEAN:
- fprintf(stderr, "%s", value);
- break;
case BER_TYPE_INTEGER:
case BER_TYPE_ENUMERATED:
fprintf(stderr, "value %s", value);
@@ -473,17 +467,10 @@ smi_print_element(struct ber_element *ro
char*str = NULL, *buf, *p;
size_t len, i;
long longv;
- int d;
struct ber_oid o;
char strbuf[BUFSIZ];
switch (root->be_encoding) {
- case BER_TYPE_BOOLEAN:
- if (ober_get_boolean(root, ) == -1)
- goto fail;
- if (asprintf(, "%s(%d)", d ? "true" : "false", d) == -1)
- goto fail;
- break;
case BER_TYPE_INTEGER:
case BER_TYPE_ENUMERATED:
if (ober_get_integer(root, ) == -1)
