From owner-freebsd-x11@freebsd.org Wed Jun 5 22:06:32 2019 Return-Path: Delivered-To: freebsd-x11@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E7E8D15BA68D for ; Wed, 5 Jun 2019 22:06:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 612886ECFA for ; Wed, 5 Jun 2019 22:06:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 17A1B15BA686; Wed, 5 Jun 2019 22:06:31 +0000 (UTC) Delivered-To: x11@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0393B15BA685 for ; Wed, 5 Jun 2019 22:06:31 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 75ECC6ECF7 for ; Wed, 5 Jun 2019 22:06:30 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id BC685F613 for ; Wed, 5 Jun 2019 22:06:29 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id x55M6TIc025619 for ; Wed, 5 Jun 2019 22:06:29 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id x55M6TWc025618 for x11@FreeBSD.org; Wed, 5 Jun 2019 22:06:29 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" From: bugzilla-noreply@freebsd.org To: x11@FreeBSD.org Subject: maintainer-feedback requested: [Bug 238351] x11-clocks/xclock: xclock -strftime option misinterprets/mishandles the %n specification Date: Wed, 05 Jun 2019 22:06:29 +0000 X-Bugzilla-Type: request X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: x11@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? Message-ID: In-Reply-To: References: X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2019 22:06:32 -0000 Bugzilla Automation has asked freebsd-x11 mailing li= st for maintainer-feedback: Bug 238351: x11-clocks/xclock: xclock -strftime option misinterprets/mishan= dles the %n specification https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D238351 --- Description --- When xclock is invoked with both the -digital and -strftime options, the man page for xclock(1) suggests that the string given as the argument to the -strftime option will be interpreted as if it were a format specification g= iven to the strftime() libc function. This is mostly true with the exception of the %n (newline) conversion specification, which is utterly mishandled by xclock. Instead of introduci= ng a newline at that point in the rendered digital xclock image, xclock instead displays something that looks like an empty box character at the correspond= ing point in the rendered digital xclock image. This is just wrong, and it obviously violates the Principal of Least Surpri= se.=20 If the user has explicitly requested a newline at some certain point in the format string, then he/she did so for a reason, and xclock should honor that request by splitting the rendered digital xclock image across two (or more) lines, exactly as the user had explicitly requested. There is no compelling reason not to do so.