Re: Un-sucking EINVAL

On 2025-05-21 00:22, Poul-Henning Kamp wrote:
> The ip# on bridge member interfaces is yet another example of why
> "EINVAL" is the undisputedly least helpful errno of them all.
> 
> The laconic "Invalid argument" leaves both the userland programmer
> and the user to guess what might be wrong.
> 
> That's ok-ish for read(2) where the possibilities are so few that
> the manpage can tell you what you did wrong.
> 
> It breaks down totally for ioctl(2), setsockopt(2) and similar
> syscalls which can attempt very, complex operations with many
> parameters and subparameters.
> 
> Ifconfig(8) is ground zero for this and the manpage is not even trying:
> 
> 	DIAGNOSTICS
> 	     Messages indicating the specified interface does not exist, the 
> requested
> 	     address is unknown, or the user is not privileged and tried to alter 
> an
> 	     interface's configuration.
> 
> We should give errno a text-partner, so kernel code can:
> 
> 	if (p->n_mazel-vanes < 6 * p->n_dingle_arms) {
> 		error_text("Too few mazel-vanes per dingle-arm (min: 6)");
> 		return (EINVAL)
> 	}
> 
> The err(3) family of functions should retrieve the string, and when there
> is one, print it as part of the error message:
> 
> 	Invalid argument:  Too few mazel-vanes per dingle-arm (min: 6)

Thank you for addressing this. This has been an itch I've been dying too 
scratch for years.
But there's always been something shinier in front of me. My first target was 
"network error".
ie; couldn't do that; network error. That's the default for nearly *any* 
network error.
Drives me nuts. Is it better to place them directly with the function, or 
would a numbered index
be better? Using a linked list of numbers to error messages.

Thanks again.

-- 
sent from hardware written from and running on FreeBSD