This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH][BZ 17979][BZ 17721] Fix issues with sys/cdefs.h and uchar.h when using non-gcc compiler.
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Dwight Guth <dwight dot guth at runtimeverification dot com>
- Cc: <libc-alpha at sourceware dot org>
- Date: Fri, 29 Jan 2016 15:34:03 +0000
- Subject: Re: [PATCH][BZ 17979][BZ 17721] Fix issues with sys/cdefs.h and uchar.h when using non-gcc compiler.
- Authentication-results: sourceware.org; auth=none
- References: <27c31890079f41775175b94a4abedb0c dot squirrel at server316 dot webhostingpad dot com> <alpine dot DEB dot 2 dot 10 dot 1601282115100 dot 6102 at digraph dot polyomino dot org dot uk> <CACLXh_1_dQ5D1QrKQN0pVPzt001WmS4BgwcKZkULK8XnbEMb+g at mail dot gmail dot com> <alpine dot DEB dot 2 dot 10 dot 1601282246340 dot 6102 at digraph dot polyomino dot org dot uk> <CACLXh_3rAudocTEbtZQpVoDcWgm_ww3KcX6j9XCkSRTZVPTUMg at mail dot gmail dot com> <alpine dot DEB dot 2 dot 10 dot 1601282251350 dot 6102 at digraph dot polyomino dot org dot uk> <20160128225845 dot GE14840 at vapier dot lan> <CACLXh_2711o7YKAXZXU2-OGvhcN0Z1TrBoiqi7PK9GpR_sR_mQ at mail dot gmail dot com> <alpine dot DEB dot 2 dot 10 dot 1601282316440 dot 6102 at digraph dot polyomino dot org dot uk> <CACLXh_2ouWg0y0jPK-MOeDMx1s8FSsRBuB+yxZpFocpEF2=+RQ at mail dot gmail dot com> <alpine dot DEB dot 2 dot 10 dot 1601282330200 dot 6102 at digraph dot polyomino dot org dot uk> <CACLXh_1SS0-Ja_0N132vdKNu2qW9tddsd3gtkBFEKC75vpa-YA at mail dot gmail dot com> <alpine dot DEB dot 2 dot 10 dot 1601282348360 dot 6102 at digraph dot polyomino dot org dot uk> <CACLXh_3eZs=FQVJY7WA8hhkx9TfveLKKStEUE_Yq4mPfSa2aOQ at mail dot gmail dot com>
On Thu, 28 Jan 2016, Dwight Guth wrote:
> Alright, fair enough. So the solution you want to see is to move
> stdint.h out of sysdeps, move the definition of uint_least16_t and
> uint_least32_t to a definition of __*_t in bits/stdint.h, and then
> define uint_least16_t, uint_least32_t, char16_t, and char32_t on the
> basis of the __*_t types? Or is this overkill given that we are
> assuming that stdint.h doesn't need to be system-specific? Which would
> you prefer?
That seems logically right, though it might be overkill. The minimum is
cross-references between the headers pointing out the other places where
type information is embedded.
--
Joseph S. Myers
joseph@codesourcery.com