This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 1/2] PowerPC - Add a new header for PowerPC specific functions


On Thu, Apr 5, 2012 at 1:02 PM, Roland McGrath <roland@frob.com> wrote:
>> So by this do you mean that the API is always defined in
>> sys/platform/<foo>.h and particular OS implementation details (like
>> #defines) are pulled from bits/<foo.h>, but that an API itself will
>> never be wholely defined in bits/<foo>.h?
>
> All I meant is that the API specification for applications to use will
> never involve mention of a bits/*.h header file.
>
>> This was suggested by Carlos O'Donell. ?Do you have a preference, one
>> way or the other for how it should be? ?I know we (Power) have a
>> number of functions that we're interested in providing, so in the
>> interest of keeping the number of new headers down I'm in favor of
>> ppc.h.
>
> I don't have a particular opinion about whether there is one header with
> many interfaces in it or many headers each with few interfaces. ?My point
> is that the public API for a given interface must always be specified to
> say that an application uses exactly one specific header file for a given
> interface. ?We don't say, "#include <foo.h> for the foo function and
> #include <bar.h> for the bar function or #include <foobar.h> for both".
> For foo, either it's <foo.h> or it's <foobar.h>.

You say "must always", but you really mean that?

I know that it's existing practice to do this, and the reason is
because it makes life easier for users.

However, does it have to be a "must always?"

Cheers,
Carlos.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]