From nobody Wed Aug 13 14:36:54 2025 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4c29tr0Pd2z64yTT for ; Wed, 13 Aug 2025 14:37:08 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Received: from mail-qk1-f179.google.com (mail-qk1-f179.google.com [209.85.222.179]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "WR4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4c29tq31KBz3Zrc for ; Wed, 13 Aug 2025 14:37:07 +0000 (UTC) (envelope-from adrian.chadd@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of adrian.chadd@gmail.com designates 209.85.222.179 as permitted sender) smtp.mailfrom=adrian.chadd@gmail.com; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=freebsd.org (policy=none) Received: by mail-qk1-f179.google.com with SMTP id af79cd13be357-7e6974a290eso626451485a.3 for ; Wed, 13 Aug 2025 07:37:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1755095826; x=1755700626; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Qst2v563T1iFw0fHI1JEjJw+zr/N7bErNIWhXloLJo0=; b=r2qwRY0NoQch3/8Z065PCUmK0TT2Jvi5JC18ft775CK+BWnXTZW2Um/btiDNpalhL/ NE0zo1BtScQj3YRsfuVpd6WkFRGNhDA9gQYfeuyXMiT9YHtuURWL65D6TK4jFBlZlssu nPQxbRFYBVfOHumcXGLvYhCxkUvrIsjG2y3et5LOGtdBsMQViNow0OEdKRmOSaAovM2K gLswbx2GzgKmyg+6qw7T27n9iJQGmSunsMDxuqSS3p8zxdu1jCGSbxYX/rJWTVvN5m7O nlE6+WZLcMrlXRRdTdS5O/VrQhWHdANvlGApY/ME7QMktmdJ/TZ/DUBQ4WozGw2K5RCB QR2Q== X-Gm-Message-State: AOJu0Ywn0ojg7omJMwMe2RxbHSs9slqjzAYuYtPbpMLNs+5Lk/ViQ7x5 Tjt41QVLX/STLwonpUvR8bIxbdF/xEwzMpLw+ATl0avc/AxqBY4r0QFWuZNdkZCHL/khi6vmd2Z k1QXOH9dkEqZSGL8kGlJX/UUyFJnMDg2r0w== X-Gm-Gg: ASbGnct5qQ4buarEOqh/BM+iATAOW+Y0wgPj6klZjkpHb+QCe8iEx3GRP0OCqaZouyR NpmXUby7BzzVlfUqb3px428sc7gmfkOEQkHsO9mz7pqRAVIbcu3Gwoa5th4O75rS8KkxrKlF3PJ KyklzME+1XgPn39Je38e7xFDLVmewE8FJL71jqEvaHWCT8mu2rcRLTpMFKg9Jpt6Ur74AthS2Q0 IeTeNA= X-Google-Smtp-Source: AGHT+IEIfugiqH4R+lte9u8X1HNyhwzNRvbI9BIYgel1R64yNyASX+kXTI4VI0JAg9z9yq562WxAdpR7bESMu3KQUgs= X-Received: by 2002:a05:620a:5783:b0:7e0:892b:e447 with SMTP id af79cd13be357-7e86526ddd6mr343273085a.22.1755095826557; Wed, 13 Aug 2025 07:37:06 -0700 (PDT) List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@FreeBSD.org MIME-Version: 1.0 References: <77BF12CC-B922-4B8D-BB57-F6AF95124B8E@gmail.com> In-Reply-To: <77BF12CC-B922-4B8D-BB57-F6AF95124B8E@gmail.com> From: Adrian Chadd Date: Wed, 13 Aug 2025 07:36:54 -0700 X-Gm-Features: Ac12FXxMukXII-1iSU7GMDDIs2wLkeKcbBNN2JviwrkGoFylbycw2nkX6NJaUvQ Message-ID: Subject: Re: Libprocstat printing warnings & errors To: Andrew Wood Cc: freebsd-current@freebsd.org Content-Type: multipart/alternative; boundary="00000000000049f28a063c4017fd" X-Spamd-Result: default: False [-2.18 / 15.00]; NEURAL_HAM_SHORT(-0.99)[-0.994]; NEURAL_HAM_LONG(-0.98)[-0.985]; NEURAL_HAM_MEDIUM(-0.30)[-0.303]; FORGED_SENDER(0.30)[adrian@freebsd.org,adrianchadd@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17:c]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; DMARC_POLICY_SOFTFAIL(0.10)[freebsd.org : SPF not aligned (relaxed), No valid DKIM,none]; FROM_HAS_DN(0.00)[]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; FREEMAIL_TO(0.00)[gmail.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ARC_NA(0.00)[]; TO_DN_SOME(0.00)[]; TAGGED_FROM(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; FREEMAIL_ENVFROM(0.00)[gmail.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_NEQ_ENVFROM(0.00)[adrian@freebsd.org,adrianchadd@gmail.com]; MISSING_XM_UA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-current@freebsd.org]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.222.179:from]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; RCVD_IN_DNSWL_NONE(0.00)[209.85.222.179:from] X-Rspamd-Queue-Id: 4c29tq31KBz3Zrc X-Spamd-Bar: -- --00000000000049f28a063c4017fd Content-Type: text/plain; charset="UTF-8" hi! On Mon, 11 Aug 2025 at 09:21, Andrew Wood 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. > --00000000000049f28a063c4017fd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
hi!

On Mon, 11 Aug 2= 025 at 09:21, Andrew Wood <andr= ew1tree@gmail.com> wrote:
Hi all,

Is it normal that a library will print errors/warnings in addition to setti= ng an error/errno value on functions whose purpose isn't printing? I= 9;ve been working with libprocstat lately and the program I'm writing i= s prone to checking processes that no longer exist a lot of the time (but i= s 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 sepa= rate function for finding out what an error was, like perhaps a procstat_st= rerror function? It seems perfectly doable given the state tracking that= 9;s already done in the procstat struct. Are there any design consideration= s 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 p= rinting anything? Is this something I could change and make a PR for and ju= st let any discussion over it happen there, or is there some person or grou= p I need to talk to about this?

Yes, ab= solutely; I think it'd be fine to change the library to make warn() opt= ional. Please do put up a PR and a diff and let's see where it goes!



-adrian
=C2= =A0

Apologies if this isn't the right spot to vent about this, I'm not = sure where the proper place is.
--00000000000049f28a063c4017fd--