Date: Wed, 13 Aug 2025 07:36:54 -0700 From: Adrian Chadd <adrian@freebsd.org> To: Andrew Wood <andrew1tree@gmail.com> Cc: freebsd-current@freebsd.org Subject: Re: Libprocstat printing warnings & errors Message-ID: <CAJ-Vmo=r9FEXTAnFG6cgQC=NOWKVFFxdRCf=odk=ftBhxSBHgQ@mail.gmail.com> In-Reply-To: <77BF12CC-B922-4B8D-BB57-F6AF95124B8E@gmail.com>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] hi! On Mon, 11 Aug 2025 at 09:21, Andrew Wood <andrew1tree@gmail.com> wrote: > Hi all, > > Is it normal that a library will print errors/warnings in addition to > setting an error/errno value on functions whose purpose isn't printing? > I've been working with libprocstat lately and the program I'm writing is > prone to checking processes that no longer exist a lot of the time (but is > built to handle this), but I'm disappointed about the fact that I've > seemingly got to choose between having my stderr riddled with warnings and > disabling my ability to use the err/warn function suite (by calling > err_set_file to set it to /dev/null). I'd much prefer if there were a > separate function for finding out what an error was, like perhaps a > procstat_strerror function? It seems perfectly doable given the state > tracking that's already done in the procstat struct. Are there any design > considerations to explain why a data-fetching would choose to print > warnings without any request to, rather than let the programmer decide > whether it's worth printing anything? Is this something I could change and > make a PR for and just let any discussion over it happen there, or is there > some person or group I need to talk to about this? > Yes, absolutely; I think it'd be fine to change the library to make warn() optional. Please do put up a PR and a diff and let's see where it goes! -adrian > > Apologies if this isn't the right spot to vent about this, I'm not sure > where the proper place is. > [-- Attachment #2 --] <div dir="ltr"><div dir="ltr">hi!</div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Mon, 11 Aug 2025 at 09:21, Andrew Wood <<a href="mailto:andrew1tree@gmail.com">andrew1tree@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi all,<br> <br> Is it normal that a library will print errors/warnings in addition to setting an error/errno value on functions whose purpose isn't printing? I've been working with libprocstat lately and the program I'm writing is prone to checking processes that no longer exist a lot of the time (but is built to handle this), but I'm disappointed about the fact that I've seemingly got to choose between having my stderr riddled with warnings and disabling my ability to use the err/warn function suite (by calling err_set_file to set it to /dev/null). I'd much prefer if there were a separate function for finding out what an error was, like perhaps a procstat_strerror function? It seems perfectly doable given the state tracking that's already done in the procstat struct. Are there any design considerations to explain why a data-fetching would choose to print warnings without any request to, rather than let the programmer decide whether it's worth printing anything? Is this something I could change and make a PR for and just let any discussion over it happen there, or is there some person or group I need to talk to about this?<br></blockquote><div><br></div><div>Yes, absolutely; I think it'd be fine to change the library to make warn() optional. Please do put up a PR and a diff and let's see where it goes!</div><div><br></div><div><br></div><div><br></div><div>-adrian</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br> Apologies if this isn't the right spot to vent about this, I'm not sure where the proper place is.<br> </blockquote></div></div>home | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-Vmo=r9FEXTAnFG6cgQC=NOWKVFFxdRCf=odk=ftBhxSBHgQ>