From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id 166D821519 for ; Tue, 20 Aug 2024 12:16:56 +0200 (CEST) Received: (qmail 32457 invoked by uid 550); 20 Aug 2024 10:16:52 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 18174 invoked from network); 20 Aug 2024 09:50:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1724147414; x=1724752214; darn=lists.openwall.com; h=to:date:message-id:subject:mime-version:from:from:to:cc:subject :date:message-id:reply-to; bh=ECZOX5E5SkaW1SS3QLUOAp9GEYjURnxK2ZtZH3H9YTg=; b=lQX6loaRajnmIh21py9fa56w6Gpri8SA3AnDkiuNSREDcVhZs/JF25Sq58mP+Q9zry jIu1BhwLmOZaszsMn+VPoIC0vG45KcdIQUYWYuXcfuUBmDUi2l+86a9aHiq9VY0gAewQ 4cJeNU1nK2JmCmCYQJEArbd7vni53SvUS+4bp7iZ7JWVvoVCypfxgUZojTejrbCWbIG3 a6JvmjVV34IrMRTZRWoezTNordAI0fTxXpxUcgknrVcvAGWKhGZhlOI4+lIPS/EKCm5e 4VykD9nmBrQhwm0oWeu/Fwj9aibR4A8ZLavPfywGnrgOUqTdyjm6bGq5NOCdInAXmfo7 NYYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1724147414; x=1724752214; h=to:date:message-id:subject:mime-version:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=ECZOX5E5SkaW1SS3QLUOAp9GEYjURnxK2ZtZH3H9YTg=; b=gpMACN4EDjLzi7+FsoJZfP54umvlf/f/8q3VyPKyXZoog0yxs4XULq7bFZazyMFSt4 OQOGS/Q4ZoBPZ6B9666u8SHoRP2XM506Vd9osQVehwXAwmwV5A7CRkwG2z0MOqNExAyj lnGhjbynV5xlrCMzbGhIUUt7EZmQIURyiVqhIyPiT+5YKWDaD49MxjmKeT7blWQaIxNU NRR48nkoBMQ/LkoLi5xEOqVTI8hRx9kaFmMr2pRHwFEtBrTHb560rK81MwPM8oRXQe6N 3Jl7RZm34SzIhecP8uY3bR3wcQ49fdeLDOITuy3kAEVG9jxotHc9SiDymp56xFRFcSCy IOLA== X-Gm-Message-State: AOJu0YxiZGrObB8fw62U4CwQyySVovb0NFPHr66ytpObhw82490ls3hW Q5OvwuBuZc3eXL2PALQgS7QhBa0IzGMJzWBzKETn25Q3fMYFmuN/xXYTow== X-Google-Smtp-Source: AGHT+IEqXl8jeVUDxyNpy3Q6ewhhrrVTLn6jEUGKqGJ06pdZRBPga0t7FG0JxnbzWDvgKLofSgNqBw== X-Received: by 2002:a17:907:f707:b0:a7a:a2e3:372c with SMTP id a640c23a62f3a-a839292f3f2mr1008620566b.28.1724147413403; Tue, 20 Aug 2024 02:50:13 -0700 (PDT) From: Gil Pedersen Content-Type: multipart/alternative; boundary="Apple-Mail=_BFFB61CB-12AC-4257-B3C9-3B7FF4380924" Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51\)) Message-Id: Date: Tue, 20 Aug 2024 11:50:02 +0200 To: musl@lists.openwall.com X-Mailer: Apple Mail (2.3776.700.51) Subject: [musl] bug: isatty() can return wrong value --Apple-Mail=_BFFB61CB-12AC-4257-B3C9-3B7FF4380924 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, I found a musl related issue in systemd, where it relies on glibc = specific behaviour for isatty(), which happens to work out. When using = musl, it will fail in another way, causing some essential retry logic to = not run. The error occurs when the isatty() implementation calls an ioctl() that = sets the EIO error. glibc will directly forward any errors, while musl = remaps it to an ENOTTY error. Neither behaviour are POSIX compliant. glibc sets an undocumented errno, = while musl sets ENOTTY for something that is definitely a TTY. It seems that the correct fix is to remap the EIO to a success (1). See https://github.com/systemd/systemd/pull/34039 and = https://sourceware.org/bugzilla/show_bug.cgi?id=3D32103. I'm not on the mailing list, so please CC any replies. Regards, Gil= --Apple-Mail=_BFFB61CB-12AC-4257-B3C9-3B7FF4380924 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Hi,

I found a musl related = issue in systemd, where it relies on glibc specific behaviour for = isatty(), which happens to work out. When using musl, it will fail in = another way, causing some essential retry logic to not = run.

The error occurs when the isatty() = implementation calls an ioctl() that sets the EIO error. glibc will = directly forward any errors, while musl remaps it to an ENOTTY = error.

Neither behaviour are POSIX compliant. = glibc sets an undocumented errno, while musl sets ENOTTY for something = that is definitely a TTY.

It seems that the = correct fix is to remap the EIO to a success = (1).


I'm not on the mailing list, so please CC any = replies.

Regards,
Gil
= --Apple-Mail=_BFFB61CB-12AC-4257-B3C9-3B7FF4380924--