$BAUD is strange on Linux for 115200

$BAUD is strange on Linux for 115200

[Janos Farkas]

If I am using an 'extended' speed (i.e. >38400), BAUD used to be
something like 4098, because the original logic in this code thought
that if the speed code returned by cfget?speed() is larger than
100, then it's the real baud rate, not a symbolic value.  This
is not so on Linux.  [Taking the opportunity, I added some recently
added baud rates to the list]. Anyone can see any problems with the code
below?

Janos

diff -urN zsh-2.6-beta21.orig/Src/utils.c zsh-2.6-beta21/Src/utils.c
--- zsh-2.6-beta21.orig/Src/utils.c	Wed Jun 19 22:01:40 1996
+++ zsh-2.6-beta21/Src/utils.c	Sun Jun 23 22:55:21 1996
@@ -2715,9 +2715,16 @@
 
 # if defined(HAVE_TCGETATTR) && defined(HAVE_TERMIOS_H)
     tempbaud = cfgetospeed(&shttyinfo->tio);
+#if defined CBAUDEX && CBAUDEX > 100
+    /* If we have CBAUDEX, then it's a mask of the extended
+       speeds, and the baud rates are still encoded.  At least
+       this is so on Linux, and I hope this logic is true on
+       most systems.  */
+#else
     if (tempbaud >= 100)
         return tempbaud;
     else
+#endif
         speedcode = (int) tempbaud;
 # else
     speedcode = shttyinfo->tio.c_cflag & CBAUD;
@@ -2784,6 +2791,22 @@
     case EXTB:
 	return (38400L);
 # endif
+#endif
+#ifdef B57600
+    case B57600:
+	return (57600L);
+#endif
+#ifdef B115200
+    case B115200:
+	return (115200L);
+#endif
+#ifdef B230400
+    case B230400:
+	return (230400L);
+#endif
+#ifdef B460800
+    case B460800:
+	return (460800L);
 #endif
     default:
 	break;

Re: $BAUD is strange on Linux for 115200

[Zoltan Hidvegi]

Janos Farkas wrote:
> 
> If I am using an 'extended' speed (i.e. >38400), BAUD used to be
> something like 4098, because the original logic in this code thought
> that if the speed code returned by cfget?speed() is larger than
> 100, then it's the real baud rate, not a symbolic value.  This
> is not so on Linux.  [Taking the opportunity, I added some recently
> added baud rates to the list]. Anyone can see any problems with the code
> below?
> 
> Janos
> 
> diff -urN zsh-2.6-beta21.orig/Src/utils.c zsh-2.6-beta21/Src/utils.c
> --- zsh-2.6-beta21.orig/Src/utils.c	Wed Jun 19 22:01:40 1996
> +++ zsh-2.6-beta21/Src/utils.c	Sun Jun 23 22:55:21 1996
> @@ -2715,9 +2715,16 @@
>  
>  # if defined(HAVE_TCGETATTR) && defined(HAVE_TERMIOS_H)
>      tempbaud = cfgetospeed(&shttyinfo->tio);
> +#if defined CBAUDEX && CBAUDEX > 100
> +    /* If we have CBAUDEX, then it's a mask of the extended
> +       speeds, and the baud rates are still encoded.  At least
> +       this is so on Linux, and I hope this logic is true on
> +       most systems.  */
> +#else
>      if (tempbaud >= 100)
>          return tempbaud;
>      else
> +#endif
>          speedcode = (int) tempbaud;
>  # else
>      speedcode = shttyinfo->tio.c_cflag & CBAUD;

Is'n it better to move the tempbaud >= 100 check to the default case in
switch (speedcode) (modifying the type of speedcode from int to long)?
I'm sure that if cfgetospeed() returns the value of a B... macro than its
the logical meaning should always be used.

Zoltan

Re: $BAUD is strange on Linux for 115200

[Janos Farkas]

On Mon, 24 Jun 1996, Zoltan Hidvegi wrote:
[about the following patch]
> >  # if defined(HAVE_TCGETATTR) && defined(HAVE_TERMIOS_H)
> >      tempbaud = cfgetospeed(&shttyinfo->tio);
> > +#if defined CBAUDEX && CBAUDEX > 100
> > +    /* If we have CBAUDEX, then it's a mask of the extended
> > +       speeds, and the baud rates are still encoded.  At least
> > +       this is so on Linux, and I hope this logic is true on
> > +       most systems.  */
> > +#else
> >      if (tempbaud >= 100)
> >          return tempbaud;
> >      else
> > +#endif

> Is'n it better to move the tempbaud >= 100 check to the default case in
> switch (speedcode) (modifying the type of speedcode from int to long)?
> I'm sure that if cfgetospeed() returns the value of a B... macro than its
> the logical meaning should always be used.

For me, it's ok; but I thought it were there for purpose.  Maybe POSIX
doesn't define that speed_t can only contain Bxxxx constants, or some
(maybe non-POSIX) systems are broken in this aspect, or maybe some can
get away with B9600=9600 and so they don't really need constants...

This way, we hopefully won't break on anyone's system...  Or, that's what
beta-testing is for? :)

Janos