Yes, this code should not fail in that circumstance. It should silently
carry on.
Note the code:
#if NUCOM > 0
case HW_UCOMNAMES: {
If the kernel has no USB com, the sysctl code is disabled. That is why
it MUST silently carry on.
But your bug report is incomplete. Where is the full dmesg for the machine
where this happened?
Probably this diff.
Index: cu.c
===================================================================
RCS file: /cvs/src/usr.bin/cu/cu.c,v
diff -u -p -u -r1.30 cu.c
--- cu.c 21 Dec 2023 11:25:38 -0000 1.30
+++ cu.c 10 Feb 2024 02:37:32 -0000
@@ -488,13 +488,13 @@ get_ucomnames(void)
size = 0;
for (;;) {
if (sysctl(mib, 2, NULL, &size, NULL, 0) == -1 || size == 0)
- err(1, "hw.ucomnames");
+ return NULL;
if ((names = realloc(names, size)) == NULL)
err(1, NULL);
if (sysctl(mib, 2, names, &size, NULL, 0) != -1)
break;
if (errno != ENOMEM)
- err(1, "hw.ucomnames");
+ return NULL;
}
return names;
}
The code that uses the return value from get_ucomnames() may be safe.
I'm rushed, don't want to burn dinner.
aphekz <aph...@kroczynski.net> wrote:
> hi
>
> ~ > cu -l cua00 -s 115200
> (on -stable) quits with an error
> cu: hw.ucomnames: Operation not supported
>
> as there is only
> com0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
> and no any ucom devices on that machine
>
> so as below there is no hw.ucomnames value
> ~ > sysctl hw.ucomnames
> sysctl: hw.ucomnames: value is not available
>
> seems one of last changes
> src/usr.bin/cu/cu.c 2023/10/02 1.29
>
> in
> char *
> get_ucomnames(void)
> ...
> if (sysctl(mib, 2, NULL, &size, NULL, 0) == -1 || size == 0)
> err(1, "hw.ucomnames");
>
> makes problem in my case.
>
> shouldn't we have
> - err(1, "hw.ucomnames");
> + break;
>
> as i'm not experienced enough to suggest diff (i might be missing sth)
> so.. verify that please.
>
> aphekz
>
