[PATCH 4/7] xfuncs: Handle missing non-POSIX termios constants

[Ralf Friedl]

Kang-Che Sung wrote:
> 2017年10月8日 18:50，"James Clarke" <jrtc27 at jrtc27.com 
> <mailto:jrtc27 at jrtc27.com>>寫道：
>
>     On 8 Oct 2017, at 02:34, Kang-Che Sung <explorer09 at gmail.com
>     <mailto:explorer09 at gmail.com>> wrote:
>     > On Sun, Oct 8, 2017 at 1:53 AM, James Clarke <jrtc27 at jrtc27.com
>     <mailto:jrtc27 at 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.
>
>
> 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.
Because the way the line is now is one line with 8 values. Changing that 
to use ifdefs for each value would change that one line to 3*8+2=26 
lines, that makes the code much harder to read and maintain. And there 
may be other places where it is used. It's perfectly legitimate to 
define the values as 0, like you would define O_BINARY as 0 on platforms 
that don't need/supply it.
> 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.
There is nothing wrong with that. It is possible to use "#if SIGUSR3" to 
test for SIGUSR being defined and nonzero. It has the additional benefit 
that you can use the value in a C statement (as opposed to a C 
preprocessor test) and let the compiler optimize it out. Busybox does 
that a lot.