From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 72967 invoked by alias); 13 Nov 2015 14:21:52 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 72947 invoked by uid 89); 13 Nov 2015 14:21:51 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mailbackend.panix.com MIME-Version: 1.0 X-Received: by 10.194.174.202 with SMTP id bu10mr27275137wjc.74.1447424506918; Fri, 13 Nov 2015 06:21:46 -0800 (PST) Date: Fri, 13 Nov 2015 14:21:00 -0000 X-Gmail-Original-Message-ID: Message-ID: Subject: RFC: remove from From: Zack Weinberg To: GNU C Library Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2015-11/txt/msg00253.txt.bz2 sys/sysmacros.h defines three macros - major, minor, makedev - that are likely to collide with user symbols. That would be fine, since it's off by itself, but sys/types.h includes sys/sysmacros.h under __USE_BSD, which means anyone who defines _BSD_SOURCE or _GNU_SOURCE and includes sys/types.h gets the macros. Moreover, under _GNU_SOURCE stdlib.h includes sys/types.h, and g++ defines _GNU_SOURCE by default (this is agreed to be suboptimal, but apparently libstdc++'s headers need it). This all adds up to what might not technically be a conformance violation but sure *looks* like it from the end-user perspective. At least two bug reports have been filed on this behavior: https://sourceware.org/bugzilla/show_bug.cgi?id=19239 and https://bugzilla.redhat.com/show_bug.cgi?id=130601 . These macros are potentially relevant to anything that wants to take apart an st_dev value in detail, but I have not personally encountered a piece of software that needs them in many years. Since sys/types.h does not provide these macros on SysV-derived systems, I would expect that portable software that needs them is prepared to include sys/sysmacros.h itself. Therefore, I propose we remove the inclusion of sys/sysmacros.h from sys/types.h. It's risky enough that I think it's worth doing a distro rebuild with that change to find out what, if anything, breaks - who do I talk to to make that happen? zw