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

[LDM #RMD-957295]: Adding additional supported BAUD rates to pqing



Bill,

> Yes, attached the wrong file.
> 
> Bill

The changes to "tty.c"

diff --git a/pqing/tty.c b/pqing/tty.c
old mode 100644
new mode 100755
index f161b78..1d75840
--- a/pqing/tty.c
+++ b/pqing/tty.c
@@ -278,6 +278,10 @@ tty_speed(const char *baud)
        speed = B19200;
     else if (strcmp(baud, "38400") == 0)
        speed = B38400;
+    else if (strcmp(baud, "57600") == 0)
+        speed = B57600;
+    else if (strcmp(baud, "115200") == 0)
+        speed = B115200;
     else {
        speed = '?';            /* assumes '?' will never be a valid speed code 
*/
     }

are fine and will be in the next release.

The changes to "pqing.c" are a bit more problematical. This change

@@ -391,14 +391,14 @@ setFeedDefaults(feedtypet type)
         /* set up defaults for feed according to type */
         switch (type) {
         case DDPLUS :
-                baud = "19200";
-                parity = "even";
+                baud = "115200";
+                parity = "none";
                 break;
         case PPS :
         case DDS :
         case IDS :
-                baud = "9600";
-                parity = "even";
+                baud = "115200";
+                parity = "none";
                 break;
         case HDS :
                 baud = "19200";

would cause the default baud rate and parity to change for the IDS and DDPLUS 
input; consequently, existing scripts that relied on that default behavior 
would no longer work. Also, it's possible to explicitly specify the baud rate 
and parity on the input via the "-b" and "-p" options. Given this effect on 
expected behavior and a simple workaround, I'm afraid I can't accept this 
change.

These changes:

@@ -533,10 +533,8 @@ main(int ac, char *av[])
     #endif /* NET */
                     case 's': {
                             unsigned long size;
-                            int           nbytes;
 
-                            if (sscanf(optarg, "%lu %n", &size, &nbytes) != 1 
||
-                                    optarg[nbytes] != 0 || 1 > size) {
+                            if (sscanf(optarg, "%lu", &size) != 1 || 1 > size) 
{
                                 LOG_ADD1("Invalid maximum data-product size: 
\"%s\"",
                                         optarg);
                                 log_log(LOG_ERR);
@@ -590,10 +588,6 @@ main(int ac, char *av[])
 
         if(logpath == NULL || !(*logpath == '-' && logpath[1] == 0))
         {
-                if (logfd < 0) {
-                    uerror("logfd < 0");
-                    return 1;
-                }
                 setbuf(fdopen(logfd, "a"), NULL);
         }       

eliminate reasonable error-checking and so won't be accepted (I think the 
sscanf() check is relatively recent -- so you might have modified an older 
version).

The last change:

@@ -616,7 +610,7 @@ main(int ac, char *av[])
          */
         if(strcmp(progname, "feedtest") != 0)
         {
-                if((ready = pq_open(pqpath, PQ_DEFAULT, &pq)))
+                if(ready = pq_open(pqpath, PQ_DEFAULT, &pq))
                 {
                         if (PQ_CORRUPT == ready) {
                             uerror("The product-queue \"%s\" is 
inconsistent\n",

also won't be accepted because it was put in there to get the Eclipse 
code-checker to shut up about an assignment in an "if" statement.

I'm glad to see that others are looking at the code.

Regards,
Steve Emmerson

Ticket Details
===================
Ticket ID: RMD-957295
Department: Support LDM
Priority: Normal
Status: Closed


NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.