Bruce Korb <[email protected]> writes:
> On Mon, Mar 5, 2012 at 3:13 PM, Joseph S. Myers <[email protected]>
> wrote:
>> On Mon, 5 Mar 2012, Rainer Orth wrote:
>>
>>> * There are some fixincludes hacks that from their names seem to be
>>> osf-specific, but are not restricted to alpha*-dec-osf*. Bruce,
>>> what's the best way to handle those? Disable them e.g. with a mach
>>> clause like unused-alpha*-dec-osf* and see if anything else breaks?
>>
>> I'd favour just removing any fixes that it seems likely are no longer
>> useful.
>
> I favor it for now, but I think being more aggressive is a good thing.
> #define REGEX_COUNT 265
> #define MACH_LIST_SIZE_LIMIT 181
> #define FIX_COUNT 223
> I believe that headers have likely improved in the last decade.
> I do doubt that there are twice as many actively needed patches
> to headers required now versus then.
Certainly true, especially with old targets like Tru64 UNIX and IRIX on
the way out. My current list of fixes that are likely osf-specific, but
isn't tagged as such, includes
alpha___assert
alpha_assert
alpha_if_semicolon (osf4)
alpha_parens
cxx_unready
osf_namespace_a, tests/base/reg_types.h
osf_namespace_c, tests/base/regex.h
sysv68_string (ffs)
ultrix_const
ultrix_const2
Some of them appear to be more generic, so it's probably safer to keep
them until your proposed mechanism for collecting usage data is in
place.
Either way, they don't need to go in the first round of the removal
patch.
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University