Re: feature request

[Jacques A. Vidrine]

[ Please don't shoot the messenger :-) ]

On Tue, May 29, 2001 at 02:02:25AM +0200, Dirk Herrmann wrote:
> > I guess I'll repeat this here:  some type names are reserved by POSIX,
> > including those that  end in `_t'.  I'd quote  from POSIX 1003.1-1996,
> > but I'm not at home at the moment  to put my hands on it.  If you have
> > the draft POSIX 1003.1-200x, see XSH sec 2.2 Name Space, line 638.
> > 
> > I don't necessarily  advocate sweeping the tree and  removing the `_t'
> > type names, but I don't think we should be adding new ones.
> 
> Sorry for being insistent, but...
> 
> ... could you please verify and show us the corresponding passage?  

As I said,  I'm out of town so  I can't physically put my  hands on my
copy of  POSIX 1003.1-1996.  You  could look  up the reference  I gave
above, which  is an  entry in a  table of names  that are  reserved by
POSIX.   The draft is available at http://www.opengroup.org/austin/ if
you agree to the conditions.

I did  a web search  to find some alternative  source of info  for the
sake of  argument (or rather, for  the sake of avoiding  it :-). These
are among the first few hits:

  GNU libc documentation notes reserved identifiers
  <URL:http://www.delorie.com/gnu/docs/glibc/libc_11.html>
  ``Some  additional  classes of  identifier  names  are reserved  for
  future  extensions to  the C  language or  the POSIX.1  environment.
  [...]  Names that  end with  `_t' are  reserved for  additional type
  names.''

  A popular C style guide
  <URL:http://www.jetcafe.org/~jim/c-style.html>
  ``Typedef  Names: Capitalized, with  no  _t suffix  or other  cutesy
  thing to say ``I'm a type'' -  we can see that from it's position in
  the declaration!  (Besides, all names ending with _t are reserved by
  Posix.) The capitalization is needed  to distinguish type names from
  variable names -  often both want to use  the same application-level
  word.''

  A message from the libtool list
  <URL:http://mail.gnu.org/pipermail/libtool-patches/2000-November/000781.html>
  ``This  patch  is a  start  at  correcting  the violation  of  POSIX
   reserved namespace with `_t' suffixes''

Obviously none of these say anything official about POSIX, but I think
they back up my assertion.


> I
> really want to be sure about this one, because it seems to be quite a big
> demand to request all names ending with '_t', especially since it seems to
> be a widely used pattern to name types that way.  

This is  just because so many  people make the mistake  of copying the
POSIX convention.  They  see ``size_t'' and think, ``Oh,  that's not a
bad idea, I'll do that, too.''  It is a common mistake.

> Reserving names within
> some prefix range makes sense to me, but reserving names with a common
> postfix is strange.  The prefix is typically used to identify the package
> a definition comes from, and requesting some postfix _across all packages_
> is something that I somehow can not really believe without seeing the
> corresponding passages myself, sorry.

The  corresponding passages  are  somewhat  obtuse, and  if  I am  not
mistaken, the draft is _more_ obtuse  than the 1996 version IMHO.  The
draft says,

  ``The  identifiers  reserved  for  use  by  the  implementation  are
    described below:  [...] Each identifier with  file scope described
    in the  header section is reserved  for use as an  identifier with
    file scope in the same name space if the header is included.''

Followed by a big table that includes this entry:
  
  Header:        Prefix:                      Suffix:
  ANY header     POSIX_, _POSIX_, posix_      _t

which  with  context  is  understood   to  mean  ``if  an  application
includes any header  file described in this standard,  then file scope
identifiers which have a prefix of  POSIX_, _POSIX_ or _posix, or have
a suffix of _t, are reserved by the implementation''.

The following is a little clearer, but less detailed.  It comes under
the `rationale' section of the standard:

   ``(That  is,  the  symbols  classified below  might,  but  are  not
     required to, be  present when _POSIX_C_SOURCE is  defined to have
     the value 20010xL.)

     * Symbols  in  <limits.h>  and  <unistd.h> that  are  defined  to
       indicate support  for options  or limits  that are  constant at
       compile-time.

     * Symbols  in the name  space reserved for the  implementation by
       the ISO C standard.

     * Symbols  in  a  name  space  reserved  for  a  particular  type
       of  extension  (for  example,  type names  ending  with  _t  in
       <sys/types.h>).

     * Additional members of  structures or unions whose  names do not
       reduce the  name space  reserved for applications.   
       
     Since  both  implementations and  future  revisions  of IEEE  Std
     1003.1-200x  and other  POSIX standards  may use  symbols in  the
     reserved spaces described  in these tables, there  is a potential
     for name space clashes.''

> Personally, I like the usage of _t for types, and I would be sorry if all
> the recent efforts to unify this usage in guile would be made useless by
> some, well, I take the freedom to call it stupid, name reservation
> policy.  Sweeping the tree and _adding_ the _t postfix is exactly what has
> just been done, and IMO would be the right thing.

Oh,  I wish  I would  have  been here  earlier.  I  thought they  were
historical.  I take  a different stand than previously,  then:  I _do_
advocate removing `_t' from all type names.

> Assuming you are right, (why don't these folks reserve some prefix posix_
> and stay with it ?) is there a recommendation how to name user types then?  

I don't know of any such recommendation.

> Can we use SCM_BOOL_T, or is that also a problem?  ("Oh ... it makes me
> mad ... mad!"  -- "Easy, Mungo, easy ..." :-)

SCM_*_T  seems  safe to  me.   Personally,  I  don't care  for  ``type
tagging''.  But I also don't like typedef'ing away structs. *shrug*

What were they before?  scm_bool?  What was wrong with that?

Cheers,
-- 
Jacques Vidrine / address@hidden / address@hidden / address@hidden