Steve, All,
Thanks for the feedback! :-)
On 2016-08-15 12:30 -0400, Steve Dickson spake thusly:
> On 08/15/2016 11:48 AM, Yann E. MORIN wrote:
> > On 2016-08-15 11:16 -0400, Steve Dickson spake thusly:
[--SNIP--]
> >> Any idea what could break by removing them??
> >
> > Virtually nothing. If you look at the glibc code, __P(arg) just expands
> > to its argument arg:
> >
> > /* These two macros are not used in glibc anymore. They are kept here
> > only because some other projects expect the macros to be defined. */
> > #define __P(args) args
> > #define __PMT(args) args
[--SNIP--]
> hmm... it just worries me to remove things from code that
> is this aged ;-) 9 out 10 times something break.
Yes, I understand your position. "If it aint' broke, don't fix it."
But I argue it is broken. ;-)
Just to expand on my position, I did some more research. glibc has
dropped K&R support since 2000 (16 yeas ago!):
commit 7f4e0e588681d0670c78472f81c21e63bb5772d6
Author: Ulrich Drepper <drepper@xxxxxxxxxx>
Date: Fri Mar 31 04:17:54 2000 +0000
Update.
2000-03-30 Andreas Jaeger <aj@xxxxxxx>
* misc/sys/cdefs.h: Remove K&R support.
And since then, __P() has been defined to just expand to its argument.
The current code was commited in 2004, in d19687d6 (which touches a lot
of files, unfortunately, so not reproducing it here...)
So, trying a little thought experiment now. All versions of gcc that we
are supposed to encounter nowadays are ANSI-compliant; they don;t need
__P().
The other compiler worth investigating is clang. I haven't checked, but
I would expect it is ANSI-compliant too.
Just as a joke, tinycc claims to be C99, so ANSI-compliant as well.
We're left with obscur or commercial compilers now. Which one would not
be ANSI-compliant and would still use K&R rules? If that was the case,
they would not be able to build even 1% of the corpus of open source
code available.
And even if such a compiler existed, would we want to support it?
> >>> Post both to the mailing lists and folks here can decide which is
> >>> better.
> >>>
> >>> You might not have time for all that ;-) so you could pick one and
> >>> add a strong technical argument in the patch description why that
> >>> is the best choice.
> >>>
> >>> I think I like 2. overall as it should leave the rpcbind source
> >>> code a little easier to read, no new autoconf logic is needed, and
> >>> there appears to be one distro that is already going that way.
> >> I lean more toward taking the patch as is and failing the
> >> configuration if the header file does not exist..
> >
> > Still the case with the above explanations?
> I do see your points... It still worries me but lets hope
> nothing breaks when they are removed...
So, does that mean you're OK with a patch to get rid of them (at least
to review it)?
Regards,
Yann E. MORIN.
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ |
| +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. |
'------------------------------^-------^------------------^--------------------'
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
