You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by rb...@covalent.net on 2000/07/21 00:23:09 UTC
POSIX namespace.
So, I was talking to somebody at O'Reilly, and it turns out that POSIX has
the entire _t namespace. Do we want to change all of our names before we
release our first beta, or are we okay with infringing on POSIX?
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
RE: POSIX namespace.
Posted by "William A. Rowe, Jr." <wr...@lnd.com>.
> From: Greg Marr [mailto:gregm@alum.wpi.edu]
> Sent: Friday, July 21, 2000 1:00 PM
>
> At 01:51 PM 07/21/2000, Ryan Bloom wrote:
> >On Fri, 21 Jul 2000, William A. Rowe, Jr. wrote:
> >
> > > > From: Jeff Baker [mailto:jwb@saturn5.com]
> > > > Sent: Thursday, July 20, 2000 5:41 PM
> > > >
> > > > On Thu, 20 Jul 2000 rbb@covalent.net wrote:
> > > >
> > >
> > > <RANT>
> > > The rest of the C world has lived on prefixes for years... so I find a
> > > blanket suffix assumption to be an entirely bad practice.
> > > </RANT>
> > >
> > > I would like to see us retain a _t designation of sorts... something
> > > like ap_ourtype_dt (for data type?) Or if we want to stay entirely in
> > > the prefix world, perhaps ap_t_ourtype would be equally effective.
> >
> >The other option is to basically thumb our noses at a bad practice and
> >just use _t. I have very little opinion about this, but we need to do
> >this ASAP.
>
> I'd say that since _t is reserved for type names, and that APR is
> using them for type names, it is within the spirit of the
> specification. I think the point they were making was that people
> shouldn't end function or variable names with _t, since _t indicates
> a type. Since APR also has a namespace prefix on all its types, it
> should be safe.
That definately -not- what they state (and probably not what they mean)
but you are right, I agree we use these in the spirit of the spec.
So... I'm +.5 for leaving things as they are, and +.5 for using the
ap_t_bleh prefix ourselves. I can take this posix spec or leave it.
RE: POSIX namespace.
Posted by Greg Marr <gr...@alum.wpi.edu>.
At 01:51 PM 07/21/2000, Ryan Bloom wrote:
>On Fri, 21 Jul 2000, William A. Rowe, Jr. wrote:
>
> > > From: Jeff Baker [mailto:jwb@saturn5.com]
> > > Sent: Thursday, July 20, 2000 5:41 PM
> > >
> > > On Thu, 20 Jul 2000 rbb@covalent.net wrote:
> > >
> >
> > <RANT>
> > The rest of the C world has lived on prefixes for years... so I
> find a
> > blanket suffix assumption to be an entirely bad practice.
> > </RANT>
> >
> > I would like to see us retain a _t designation of sorts...
> something
> > like ap_ourtype_dt (for data type?) Or if we want to stay
> entirely in
> > the prefix world, perhaps ap_t_ourtype would be equally effective.
>
>The other option is to basically thumb our noses at a bad practice and
>just use _t. I have very little opinion about this, but we need to do
>this ASAP.
I'd say that since _t is reserved for type names, and that APR is
using them for type names, it is within the spirit of the
specification. I think the point they were making was that people
shouldn't end function or variable names with _t, since _t indicates
a type. Since APR also has a namespace prefix on all its types, it
should be safe.
--
Greg Marr
gregm@alum.wpi.edu
"We thought you were dead."
"I was, but I'm better now." - Sheridan, "The Summoning"
Re: POSIX namespace.
Posted by Sascha Schumann <sa...@schumann.cx>.
On Sat, 22 Jul 2000, Greg Stein wrote:
> On Fri, Jul 21, 2000 at 08:48:07PM -0500, Manoj Kasichainula wrote:
> > On Fri, Jul 21, 2000 at 10:51:21AM -0700, rbb@covalent.net wrote:
> > > The other option is to basically thumb our noses at a bad practice and
> > > just use _t.
> >
> > +1
>
> They're whacked if they believe that they can just take over the _t suffix.
> There is so *much* precedent for using that, that it seems bizarre to even
> think it is reasonable to claim that space.
POSIX was released in 1996. The new SUS III does not reserve
the _t suffix anymore, so it looks like it will be fixed in
the near future.
- Sascha
Re: POSIX namespace.
Posted by Greg Stein <gs...@lyra.org>.
On Fri, Jul 21, 2000 at 08:48:07PM -0500, Manoj Kasichainula wrote:
> On Fri, Jul 21, 2000 at 10:51:21AM -0700, rbb@covalent.net wrote:
> > The other option is to basically thumb our noses at a bad practice and
> > just use _t.
>
> +1
They're whacked if they believe that they can just take over the _t suffix.
There is so *much* precedent for using that, that it seems bizarre to even
think it is reasonable to claim that space.
+1 on continuing to use the _t suffix
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: POSIX namespace.
Posted by James Sutherland <ja...@cam.ac.uk>.
On Fri, 21 Jul 2000, Manoj Kasichainula wrote:
> On Fri, Jul 21, 2000 at 10:51:21AM -0700, rbb@covalent.net wrote:
> > The other option is to basically thumb our noses at a bad practice and
> > just use _t.
>
> +1
+1 as long as we have an Apache prefix/suffix as well - ap_*_t or similar.
James.
Re: POSIX namespace.
Posted by Manoj Kasichainula <ma...@io.com>.
On Fri, Jul 21, 2000 at 10:51:21AM -0700, rbb@covalent.net wrote:
> The other option is to basically thumb our noses at a bad practice and
> just use _t.
+1
Re: POSIX namespace.
Posted by David Reid <dr...@jetnet.co.uk>.
> The other option is to basically thumb our noses at a bad practice and
> just use _t. I have very little opinion about this, but we need to do
> this ASAP.
It's in the spirit of the reference, so +1.
RE: POSIX namespace.
Posted by rb...@covalent.net.
On Fri, 21 Jul 2000, William A. Rowe, Jr. wrote:
> > From: Jeff Baker [mailto:jwb@saturn5.com]
> > Sent: Thursday, July 20, 2000 5:41 PM
> >
> > On Thu, 20 Jul 2000 rbb@covalent.net wrote:
> >
>
> <RANT>
> The rest of the C world has lived on prefixes for years... so I find a
> blanket suffix assumption to be an entirely bad practice.
> </RANT>
>
> I would like to see us retain a _t designation of sorts... something
> like ap_ourtype_dt (for data type?) Or if we want to stay entirely in
> the prefix world, perhaps ap_t_ourtype would be equally effective.
The other option is to basically thumb our noses at a bad practice and
just use _t. I have very little opinion about this, but we need to do
this ASAP.
Ryan
_______________________________________________________________________________
Ryan Bloom rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------
RE: POSIX namespace.
Posted by "William A. Rowe, Jr." <wr...@lnd.com>.
> From: Jeff Baker [mailto:jwb@saturn5.com]
> Sent: Thursday, July 20, 2000 5:41 PM
>
> On Thu, 20 Jul 2000 rbb@covalent.net wrote:
>
> > So, I was talking to somebody at O'Reilly, and it turns out that POSIX has
> > the entire _t namespace. Do we want to change all of our names before we
> > release our first beta, or are we okay with infringing on POSIX?
>
> That was me. Since nobody seemed to believe me at the time
> :), here is a reference:
>
>
> www.gnu.org/manual/glibc-2.0.6/text/libc.txt
> "
> Some additional classes of identifier names are reserved for future
> extensions to the C language or the POSIX.1 environment. While using
> these names for your own purposes right now might not cause a problem,
> they do raise the possibility of conflict with future
> versions of the C or
> POSIX standards, so you should avoid these names.
>
> ...
>
> * Names that end with `_t' are reserved for additional type names."
>
> My two cents would be to regexp out the all those _t's.
<RANT>
The rest of the C world has lived on prefixes for years... so I find a
blanket suffix assumption to be an entirely bad practice.
</RANT>
I would like to see us retain a _t designation of sorts... something
like ap_ourtype_dt (for data type?) Or if we want to stay entirely in
the prefix world, perhaps ap_t_ourtype would be equally effective.
Bill
Re: POSIX namespace.
Posted by Jeff Baker <jw...@saturn5.com>.
On Thu, 20 Jul 2000 rbb@covalent.net wrote:
>
> So, I was talking to somebody at O'Reilly, and it turns out that POSIX has
> the entire _t namespace. Do we want to change all of our names before we
> release our first beta, or are we okay with infringing on POSIX?
That was me. Since nobody seemed to believe me at the time :), here is a
reference:
www.gnu.org/manual/glibc-2.0.6/text/libc.txt
"
Some additional classes of identifier names are reserved for future
extensions to the C language or the POSIX.1 environment. While using
these names for your own purposes right now might not cause a problem,
they do raise the possibility of conflict with future versions of the C or
POSIX standards, so you should avoid these names.
...
* Names that end with `_t' are reserved for additional type names.
"
My two cents would be to regexp out the all those _t's.
Cheers,
Jeffrey Baker
Re: POSIX namespace.
Posted by Sascha Schumann <sa...@schumann.cx>.
On Fri, 21 Jul 2000, Sascha Schumann wrote:
> On Thu, 20 Jul 2000 rbb@covalent.net wrote:
>
> >
> > So, I was talking to somebody at O'Reilly, and it turns out that POSIX has
> > the entire _t namespace. Do we want to change all of our names before we
> > release our first beta, or are we okay with infringing on POSIX?
>
> Actually, this is not the case.
Here SUS III and POSIX differ significantly. Whereas SUS III
does not make any statement about reserving suffices, POSIX
"2.7.2 POSIX.1 Symbols" clearly states
"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."
If I had to make the decision, I'd choose to follow the rules
of the new/future standard.
- Sascha
Re: POSIX namespace.
Posted by Sascha Schumann <sa...@schumann.cx>.
On Thu, 20 Jul 2000 rbb@covalent.net wrote:
>
> So, I was talking to somebody at O'Reilly, and it turns out that POSIX has
> the entire _t namespace. Do we want to change all of our names before we
> release our first beta, or are we okay with infringing on POSIX?
Actually, this is not the case. SUS III (successor of SUS II
and POSIX) allows the use of the suffix _t in any header file
of the implementation, but it does not reserve it.
If you carefully read "2.2.2 The Name Space" you will notice
that the proposal reserves only a couple of prefixes:
posix_
POSIX_
_POSIX_
And later:
_[A-Z_]
_ (file scope)
It also explicitly says
"No other identifiers are reserved."
- Sascha