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

Kang-Che Sung explorer09 at gmail.com
Sun Oct 8 11:18:22 UTC 2017


2017年10月8日 18:50,"James Clarke" <jrtc27 at jrtc27.com>寫道:

On 8 Oct 2017, at 02:34, Kang-Che Sung <explorer09 at gmail.com> wrote:
> On Sun, Oct 8, 2017 at 1:53 AM, James Clarke <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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/busybox/attachments/20171008/59c4bfbf/attachment.html>


More information about the busybox mailing list