[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Mon, 10 Jun 2019 16:30:40 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: [PATCH 1/2] define daddr_t type
On Fri, Jun 07, 2019 at 11:25:45AM -0400, Rich Felker wrote:
> On Fri, Jun 07, 2019 at 02:52:07PM +0200, Leah Neukirchen wrote:
> > Rich Felker <dalias@...c.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.
OK, some Google-fu turns up that the historical meaning of daddr_t was
"disk address" (as opposed to caddr_t which AIUI means "core
address"). In that light, defining it would be completely wrong, since
the definition should match off_t (long long), not int/long, but
changing it to match would break any actual historical use of it...
This should probably be treated as a bug against the mtio interface
definition...
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
