2017年10月8日 18:50，"James Clarke" <jrt...@jrtc27.com>寫道：
On 8 Oct 2017, at 02:34, Kang-Che Sung <explore...@gmail.com> wrote: > On Sun, Oct 8, 2017 at 1:53 AM, James Clarke <jrt...@jrtc27.com> wrote: >> diff --git a/libbb/xfuncs.c b/libbb/xfuncs.c >> index 9cbfb2836..95dac656a 100644 >> --- a/libbb/xfuncs.c >> +++ b/libbb/xfuncs.c >> @@ -22,6 +22,16 @@ >> */ >> #include "libbb.h" >> >> +#ifndef IMAXBEL >> +# define IMAXBEL 0 >> +#endif >> +#ifndef IUCLC >> +# define IUCLC 0 >> +#endif >> +#ifndef IXANY >> +# define IXANY 0 >> +#endif >> + > > I wonder, how do these break, and why does defining them as 0 solve the problem? FreeBSD (well, GNU/kFreeBSD at least) does not define IUCLC. They are only used in the line: > newterm.c_iflag &= ~(BRKINT|INLCR|ICRNL|IXON|IXOFF|IUCLC|IXANY|IMAXBEL); Thus, by defining them as 0 when not present, it is as if they were omitted from that list, without needing a bunch of confusing #ifdef's in the expression itself. While IMAXBEL and IXANY are defined everywhere Debian cares about, they are still non-standard, so I did the same for them in case there is a platform out there without them. Regards, James Why not just fix that usage line so that the bitwise OR's are all enclosed in #ifdef lines? I think it's better than defining the macros to a value that may cause further problems when reused. Analogy: You probably won't define an unsupported signal, say SIGUSR3, to a zero value anyway. They are undefined for a reason. Hope you understand.
