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

20000320: dchrly core dump

>From: "Arthur A. Person" <address@hidden>
>Organization: .
>Keywords: 200003202136.OAA29033

>Hi...
>
>I've discovered that the following observation causes the version of
>dchrly I'm running (gempak 5.4 pl12) to core dump:
>
>   KRIC 131546Z 21013KT 3SM HZ SCT022 31/24 A2995 RMK AO2 SFC VIS=
>
>If you add a number to the end, then it's okay, e.g.
>
>   KRIC 131546Z 21013KT 3SM HZ SCT022 31/24 A2995 RMK AO2 SFC VIS 4=
>
>If this problem still exists in the current code version, perhaps it could
>be fixed to prevent a mysterious core dump (such as happened to me!). 
>
>                                       Thanks.
>
>                                         Art.
>
>Arthur A. Person
>Research Assistant, System Administrator
>Penn State Department of Meteorology
>email:  address@hidden, phone:  814-863-1563
>


Art,

Yes, they are supposed to report a visibility, and when none exists, and it is 
the last entry in the remark, the decoder will bomb.

To fix this, edit $GEMPAKHOME/source/bridge/metar/dcdmtrmk.c and insert
prior to line 941 (this is the line number in pl16, you might have
a slightly different line number) a check for the null pointer before
the nisdigit() call. See the code snip below for the line to insert:



   if((strcmp(*token,"SFC") != 0)||(*(token+1) == NULL))
      return FALSE;
   else
      {
      if( strcmp(*(++token),"VIS") != 0) {
        (*NDEX)++;
        return FALSE;
        }
      else
         {
         (++token);
         }
      }

   if(*token == NULL) return FALSE;             <<-- add this line ~line 941

   if( nisdigit(*token,
              strlen(*token)))
   {
      Mptr->SFC_VSBY = (float) atoi(*token);



I'll roll this in to the current distribution. 
The OSO code ignores the fact that not every metar report actually conforms
to the documented specification!

Thanks,

Steve Chiswell