bader+@andrew.cmu.edu (Miles Bader) (01/20/90)
karl@haddock.ima.isc.com (Karl Heuer) writes: > Likewise, you should probably not use _t for your own typedefs, because POSIX > reserves this entire class for use in <sys/types.h>. Now that's an incredibly stupid thing to do, given the large number of people who already do use _t suffixes. It's sort of like reserving all macro names that use ALLCAPS... [I hope you mis-read this or something] -Miles
karl@haddock.ima.isc.com (Karl Heuer) (01/20/90)
In article <YZhuprK00Vsa4O07JO@andrew.cmu.edu> bader+@andrew.cmu.edu (Miles Bader) writes: >karl@haddock.ima.isc.com (Karl Heuer) writes: >> Likewise, you should probably not use _t for your own typedefs, because >> POSIX reserves this entire class for use in <sys/types.h>. > >Now that's an incredibly stupid thing to do, given the large number of people >who already do use _t suffixes. Well, let me rephrase it. If you're *not* using <sys/types.h>, then you're safe; there are only a finite number of _t names reserved outside of that header (e.g. size_t). If you *are* using <sys/types.h> in a program intended to be portable, then you'd better not use any of the _t namespace, because the implementation is permitted to have nonstandard extensions visible as long as they use that spelling. (E.g., ushort_t.) I think this is better than the old method, where there was no guarantee at all about the namespace of <sys/types.h>, and one vendor would typedef ushort while another would do u_short, the end result being that both names are reserved and neither is usuable. Karl W. Z. Heuer (karl@haddock.isc.com or ima!haddock!karl), The Walking Lint
karl@haddock.ima.isc.com (Karl Heuer) (01/20/90)
In article <YZhuprK00Vsa4O07JO@andrew.cmu.edu> bader+@andrew.cmu.edu (Miles Bader) writes: >karl@haddock.ima.isc.com (Karl Heuer) writes: >> Likewise, you should probably not use _t for your own typedefs, because >> POSIX reserves this entire class for use in <sys/types.h>. > >Now that's an incredibly stupid thing to do, given the large number of people >who already do use _t suffixes. Well, let me rephrase it. If you're *not* using <sys/types.h>, then you're safe; there are only a finite number of _t names reserved outside of that header (e.g. size_t). If you *are* using <sys/types.h> in a program intended to be portable, then you'd better not use any of the _t namespace, because the implementation is permitted to have nonstandard extensions visible as long as they use that spelling. (E.g., ushort_t.) I think this is better than the old method, where there was no guarantee at all about the namespace of <sys/types.h>, and one vendor would typedef ushort while another would do u_short, the end result being that both names are reserved and neither is usable. Karl W. Z. Heuer (karl@haddock.isc.com or ima!haddock!karl), The Walking Lint
fred@mindcraft.com (Fred Zlotnick) (02/01/91)
In article <1991Jan29.210100.8105@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: >In article <1212@tredysvr.Tredydev.Unisys.COM> paul@tredysvr.Tredydev.Unisys.COM (Paul Siu) writes: > . . . >>Can anyone also tell me what is the most common style convention for type >>names, I usually put them all in capitals. > >Insofar as there is a consensus, it's to put them in lower case with a >suffix "_t", e.g. "uid_t" as the type for userids. While this has been the consensus, the POSIX.1 standard (ISO/IEC 9945-1:1990, or IEEE 1003.1-1990 if you prefer) has reserved the "_t" namespace for the system implementor. (That is, application programs should not use symbols ending in "_t"). The standard states (clause 2.7.2, lines 804-806): If any header defined by this part of ISO/IEC 9945 is included, all symbols with the suffix _t are reserved for use by the implementation, both before and after the #include directive. So, if you want your programs to port to POSIX.1 conforming systems, this convention is no longer ok. I had previously used an "_t" suffix for typedef names, but have stopped. My current convention is to use "_T" (and to use lower case letters for the rest of the type name), but I'm not thrilled with it. Any suggestions? ---- Fred Zlotnick | #include <std.disclaimer> fred@mindcraft.com | #include <brilliant.quote> ...!{decwrl,ames,hpda}!mindcrf!fred | -- Fred Zlotnick | #include <std.disclaimer> fred@mindcraft.com | #include <brilliant.quote> ...!{decwrl,ames,hpda}!mindcrf!fred |
gceych@romeo.caltech.edu (Amateurgrammer) (02/01/91)
fred@mindcraft.com (Fred Zlotnick) writes... :henry@zoo.toronto.edu (Henry Spencer) writes: :>paul@tredysvr.Tredydev.Unisys.COM (Paul Siu) writes: :> . . . :>>Can anyone also tell me what is the most common style convention for type :>>names, I usually put them all in capitals. :> :>Insofar as there is a consensus, it's to put them in lower case with a :>suffix "_t", e.g. "uid_t" as the type for userids. : :While this has been the consensus, the POSIX.1 standard (ISO/IEC 9945-1:1990, :or IEEE 1003.1-1990 if you prefer) has reserved the "_t" namespace for :the system implementor. (That is, application programs should not use :symbols ending in "_t"). [deletion] My current convention is to use "_T" :(and to use lower case letters for the rest of the type name), but I'm :not thrilled with it. Any suggestions? Since my first typedefs were structures, I adopted _st as my typedef convention, as in typedef structure { /*stuff*/ } param_st; It's not the best solution, but it works :-) :---- %VNEWS-I-ENDOFPOST, signature file appended to end of posted message Glenn C. Eychaner \_ "Do you qualify to be alive, or is the limit Big Bear Solar Observatory \_ of your senses so as only to survive?" eychaner@suncub.bbso.caltech.edu \ -Ray Stevens, _Mr._Businessman_
dave@tygra.UUCP (David Conrad) (02/01/91)
In article <665344102.6268@mindcraft.com> fred@mindcraft.com (Fred Zlotnick) writes: >So, if you want your programs to port to POSIX.1 conforming systems, this >convention is no longer ok. I had previously used an "_t" suffix for >typedef names, but have stopped. My current convention is to use "_T" >(and to use lower case letters for the rest of the type name), but I'm >not thrilled with it. Any suggestions? >---- >Fred Zlotnick | #include <std.disclaimer> >fred@mindcraft.com | #include <brilliant.quote> >...!{decwrl,ames,hpda}!mindcrf!fred | Yes, I'd like to suggest that the POSIX.1 standard sucks. Let the programmer have _t, make the system use _t_ or something equally ugly. -- David Conrad tygra!dave@uunet.uu.net tygra!dave@sharkey.cc.umich.edu (The address in the last line below is BROKEN.) -- = CAT-TALK Conferencing Network, Computer Conferencing and File Archive = - 1-313-343-0800, 300/1200/2400/9600 baud, 8/N/1. New users use 'new' - = as a login id. AVAILABLE VIA PC-PURSUIT!!! (City code "MIDET") = E-MAIL Address: dave@DDMI.COM
sarima@tdatirv.UUCP (Stanley Friesen) (02/03/91)
In article <1991Feb1.112141.28914@tygra.UUCP> dave@tygra.UUCP (David Conrad) writes: |Yes, I'd like to suggest that the POSIX.1 standard sucks. | |Let the programmer have _t, make the system use _t_ or something equally ugly. Agreed! This restriction is wholy unnecessary. Who do we write to to get it changed!?!? -- --------------- uunet!tdatirv!sarima (Stanley Friesen)
chip@tct.uucp (Chip Salzenberg) (02/04/91)
According to dave@tygra.UUCP (David Conrad):
>Let the programmer have _t ...
Too late. Can you say size_t, dev_t, ptrdiff_t, ... ?
--
Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip>
"I want to mention that my opinions whether real or not are MY opinions."
-- the inevitable William "Billy" Steinmetz