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

[James Clarke]

[Dropping debian-h...@lists.debian.org as the Hurd defines all of them]

On 8 Oct 2017, at 12:18, Kang-Che Sung  wrote:
> 2017年10月8日 18:50，"James Clarke" 寫道：
>> On 8 Oct 2017, at 02:34, Kang-Che Sung  wrote:
>> > On Sun, Oct 8, 2017 at 1:53 AM, James Clarke  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.

I can understand your reasoning; the only reason I did it that way was because
coreutils/stty.c has a whole load of instances of this, including for IMAXBEL,
IUCLC and IXANY, but looking at it more closely I now see that all uses of them
are in fact guarded by whether they are non-zero, so I'm not sure whether
there's really much point even for that file. I shall therefore change it to
use #ifdef's for the OR just like you said to avoid potential confusion.

Regards,
James

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

[Kang-Che Sung]

2017年10月8日 18:50，"James Clarke" 寫道：

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

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

[James Clarke]

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

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

[Kang-Che Sung]

On Sun, Oct 8, 2017 at 1:53 AM, James Clarke  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?

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

[James Clarke]

Signed-off-by: James Clarke 
---
 libbb/xfuncs.c | 10 ++
 1 file changed, 10 insertions(+)

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
+
 /* Turn on nonblocking I/O on a fd */
 int FAST_FUNC ndelay_on(int fd)
 {
-- 
2.14.1