From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <musl-return-15325-ml=inbox.vuxu.org@lists.openwall.com>
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org
X-Spam-Level: 
X-Spam-Status: No, score=-2.8 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS,
	MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,
	RCVD_IN_MSPIKE_WL,SUBJ_OBFU_PUNCT_FEW autolearn=ham autolearn_force=no
	version=3.4.2
Received: from mother.openwall.net (mother.openwall.net [195.42.179.200])
	by inbox.vuxu.org (OpenSMTPD) with SMTP id bda1309f
	for <ml@inbox.vuxu.org>;
	Wed, 29 Jan 2020 15:49:40 +0000 (UTC)
Received: (qmail 1565 invoked by uid 550); 29 Jan 2020 15:49:38 -0000
Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm
Precedence: bulk
List-Post: <mailto:musl@lists.openwall.com>
List-Help: <mailto:musl-help@lists.openwall.com>
List-Unsubscribe: <mailto:musl-unsubscribe@lists.openwall.com>
List-Subscribe: <mailto:musl-subscribe@lists.openwall.com>
List-ID: <musl.lists.openwall.com>
Reply-To: musl@lists.openwall.com
Received: (qmail 1547 invoked from network); 29 Jan 2020 15:49:38 -0000
Date: Wed, 29 Jan 2020 10:49:25 -0500
From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Message-ID: <20200129154925.GI30412@brightrain.aerifal.cx>
References: <20200129125012.GB29404@dell5510>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200129125012.GB29404@dell5510>
User-Agent: Mutt/1.5.21 (2010-09-15)
Sender: Rich Felker <dalias@aerifal.cx>
Subject: Re: [musl] MUSL not including <sys/ttydefaults.h> in <sys/ioctl.h>

On Wed, Jan 29, 2020 at 01:50:12PM +0100, Petr Vorel wrote:
> Hi,
> 
> Glibc is including <sys/ttydefaults.h> in <sys/ioctl.h> with following comment:
> 
> /* On a Unix system, the system <sys/ioctl.h> probably defines some of
>    the symbols we define in <sys/ttydefaults.h> (usually with the same
>    values).  The code to generate <bits/ioctls.h> has omitted these
>    symbols to avoid the conflict, but a Unix program expects <sys/ioctl.h>
>    to define them, so we must include <sys/ttydefaults.h> here.  */
> 
> I guess glibc is (as usual) wrong and therefore users who needs these
> definitions should load also <sys/ttydefaults.h> explicitly.

ioctl.h isn't governed by any current standard, so we could include
sys/ttydefaults.h here, but I don't think it makes sense to. These
macros logically have nothing to do with the ioctl interface; rather
they go with termios. Programs that want them should probably be
including the header explicitly, or better yet not using them at all.

I also found a couple small issues in that header I'm fixing now.

Rich