Re: [PATCH 1/2] define daddr_t type

[Rich Felker <dalias@libc.org>]

On Fri, Jun 07, 2019 at 02:52:07PM +0200, Leah Neukirchen wrote:
> Rich Felker <dalias@libc.org> writes:
> 
> > On Fri, Jun 07, 2019 at 07:53:29AM +0200, Petr Vorel wrote:
> >> Hi Rich,
> >> 
> >> ....
> >> > > +++ b/include/sys/types.h
> >> > > @@ -29,6 +29,7 @@ extern "C" {
> >> > >  #define __NEED_clock_t
> >> > >  #define __NEED_suseconds_t
> >> > >  #define __NEED_blksize_t
> >> > > +#define __NEED_daddr_t
> >> ....
> >> 
> >> > daddr_t is not a standard type, so can't be exposed by default here
> >> > (aside from the dubious "*_t is always reserved" rule), and it's only
> >> So should it be wrapped by #if defined(_GNU_SOURCE) || defined(_BSD_SOURCE) ?
> >> 
> >> > proposed to be used in one header, so it doesn't belong in alltypes.h
> >> > either.
> >> Where should it be then? Shell I create bits/types.h for it?
> >> The goal is to be loadable from <sys/types.h>
> >
> > Why? It's not a reasonable type for any application to use -- we've
> > never gotten a report that something failed to build because of its
> > absence, and even if we did, it would almost surely be a case of "fix
> > the application".
> 
> FWIW, Void patches four packages that use daddr_t:
> 
> - gpart
> - kpartx
> - libtirpc
> - sleuthkit
> 
> Additionally, five packages use caddr_t:
> 
> - ifenslave
> - lwipv6
> - macchanger
> - sbcl
> - virtuoso

Thanks. Can you tell if they have any legitimate motivation for doing
so? What even is the conceptual definition of daddr_t? AIUI, caddr_t
was historically something like void * or uintptr_t, a type for
abstract addresses that might not actually point to objects, that
mainly existed because void * didn't yet exist, but I have no idea
what daddr_t is supposed to be.

Rich