Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <kst-u@mib.org>
Newsgroups: comp.lang.c
Subject: Re: _mingw_off_t.h
Date: Sat, 01 Dec 2018 12:08:35 -0800
Organization: None to speak of
Lines: 38
Message-ID: <lnmuppm2m4.fsf@kst-u.example.com>
References: <65a75cae-d78c-4cab-8bf2-e5762dc61dd9@googlegroups.com> <XLcLD.75681$lKb.3224@fx15.am4> <ptjnsi$ebr$1@dont-email.me> <pSdLD.412437$p%6.103429@fx26.am4> <ptkh5q$cge$1@dont-email.me> <05mLD.656101$aw7.71699@fx04.am4> <ptlg4l$pcf$1@dont-email.me> <y6vLD.301445$5A2.62978@fx25.am4> <ptm8h6$9er$1@dont-email.me> <2ayLD.347780$kh6.95743@fx32.am4> <ptokkc$4ah$1@dont-email.me> <V7RLD.331336$_E4.97068@fx10.am4> <rHRLD.256822$LL1.154067@fx23.iad> <WHSLD.336101$6N5.323946@fx29.am4> <n42MD.576249$oM2.383068@fx07.iad> <DC9MD.425734$1C7.343564@fx38.am4> <ExaMD.1145190$RN2.392744@fx40.iad> <bwbMD.807035$8Q.519947@fx36.am4> <tIcMD.282403$6y.230304@fx09.iad> <kfn4lbxw8nm.fsf@x-alumni2.alumni.caltech.edu> <tGAMD.386950$SG2.363737@fx29.iad>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: reader01.eternal-september.org; posting-host="dcd473f9e421e43d48acf9d2cb1b118b"; logging-data="1918"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19FvGAdMJpWVaNg74zB2iH6"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)
Cancel-Lock: sha1:ZOPbExPvoQ549vOCxlqm8P244BY= sha1:xKdLyzEOtSQMwHim864YXFnjpqI=
Xref: csiph.com comp.lang.c:138474

Richard Damon <Richard@Damon-Family.org> writes:
> On 12/1/18 10:47 AM, Tim Rentsch wrote:
>> Richard Damon <Richard@Damon-Family.org> writes:
>>> The type time_t started in the user name space, so the
>>> implementation wasn't allowed to create a definition for it until
>>> an appropriate header was include[d]
>> 
>> I believe that is still true.
>> 
>>> (C99 put all of *_t into the implementation name space as I
>>> remember allowing things to be simplified if you didn't need
>>> backwards compatibility)
>> 
>> I believe that names of the form *_t are reserved only for
>> typedef names, and only if they begin 'int' or 'uint', and
>> then only if <stdint.h> has been #include'd.  (Of course
>> other specific names ending in _t are reserved if a header
>> that declares them has been #include'd.)
>> 
>> References:  7.1.3, 7.31.10
>
> I may have been remembering a best-practices document then. The
> committee has shown a tendency when defining a new standard type to make
> it end in _t (after including the enabling header), so to future proof
> your code, you should avoid making your types end in _t, unless of
> course you figure you code would need to be changed in those areas
> anyway if the standard were to define something like that.

I believe that POSIX reserves identifiers ending with "_t".  ISO C
does not (except for [u]int*_t).

[...]

-- 
Keith Thompson (The_Other_Keith) kst@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"