[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#49524: 28.0.50; make-serial-process is not portable

From: Ken Brown
Subject: bug#49524: 28.0.50; make-serial-process is not portable
Date: Mon, 12 Jul 2021 17:35:40 -0400
User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0

On 7/12/2021 9:27 AM, Ken Brown wrote:
On 7/11/2021 12:24 PM, Eli Zaretskii wrote:
From: Ken Brown <kbrown@cornell.edu>
Date: Sun, 11 Jul 2021 11:24:58 -0400

Fmake_serial_process calls Fserial_process_configure, which calls
serial_configure, which calls cfsetspeed with the speed argument equal to the
numerical baud rate (e.g., 9600).  But the documentation of cfsetspeed says that
the speed argument must be one of the Bnnn constants defined in termios.h (e.g.,
B9600).  See, for example,


This incorrect call of cfsetspeed happens to succeed on GNU/Linux because
glibc's cfsetspeed allows the argument to be the numerical baud rate, which it
converts to the appropriate Bnnn constant.  But I don't think emacs should be
relying on this undocumented behavior.  In particular, this doesn't work on
Cygwin.  And it wouldn't even work on GNU/Linux if emacs used the cfsetspeed
replacement defined in sysdep.c instead of glibc's cfsetspeed.

I think the way to fix this is to imitate the glibc code that converts the baud
rate to a Bnnn constant, but maybe someone has a better idea.

Converting in sysdep.c:serial_configure sounds TRT to me.

Patch attached.

BTW, we've decided to change Cygwin's cfsetspeed to be compatible with glibc's, so the problem fixed by my patch won't exist on Cygwin going forward. And I checked FreeBSD out of curiosity and found that there's no issue there either because of the way they define the Bnnn constants:

#define B0      0
#define B50     50
#define B75     75

So I should probably remove the reference to non-glibc platforms in my commit message.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]