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

Re: 19990622: pqact handling of bad action lines

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: Re: 19990622: pqact handling of bad action lines
  • Date: Tue, 10 Aug 1999 15:13:14 -0600 (MDT)
On Tue, 10 Aug 1999, Steven Danz wrote:

> Glad to help.  One thing I added was an error message that gets
> logged so the admin. can at least see there is a pqact.conf
> problem.
> 
> Does this mean the 5.0.8 that I see on the ftp server isn't
> the 'final' one yet?

Steven,

Noop, it started out as a Linux test release that wasn't announce but
people installed it. The final release of 5.0.8 will be Fri. I wanted to
test it first.

Robb...


> 
> -swd
> 
> Robb Kambic wrote:
> 
> > Steven,
> >
> > Thanks for the bug report and the fix. It works fine. palt just skips the
> > incorrect \n request and continues processing the RE.  The file name
> > construction omits the incorrect \n also.  This fix will be in the ldm
> > 5.0.8 release.
> >
> > Robb...
> >
> > On Tue, 22 Jun 1999, Unidata Support wrote:
> >
> > >
> > > ------- Forwarded Message
> > >
> > > >To: support-ldm <address@hidden>
> > > >From: Steven Danz <address@hidden>
> > > >Subject: Minor pqact problem in 5.0.8
> > > >Organization: .
> > > >Keywords: 199906221828.MAA26656
> > >
> > > Hi
> > >
> > > I've noticed that pqact in 5.0.8 is much less forgiving
> > > of bad pqact.conf pattern/action statements than 5.0.6.
> > > The situation I've run across is where the action requests
> > > more fields from the pattern than were defined, for example:
> > > WMO ^WS.... .... ([0-3][0-9])([0-2][0-9]) FILE foo/\1\2\3.out
> > >
> > > Around line 706 in palt.c, there is no bounds checking on
> > > variable no to make sure it doesn't try to index into
> > > pal->pmatchp past where there is valid data and when it does,
> > > a core file appears shortly after.  I'm guessing bounds checking
> > > on the no variable would fix the problem, something like
> > > } else if ( no <= pal->prog.re_nsub && pal->pmatchp[no].rm_so >= 0
> > >             && pal->pmatchp[no].rm_eo > pal->pmatchp[no].rm_so) {
> > > but I'm not sure what the right response is when the problem
> > > shows up (silently ignore, or error message and return?).
> > > I'm not sure why 5.0.6 doesn't have this problem (beyond the
> > > obvious regsub replacement).
> > >
> > > Thanks
> > >
> > > Steven Danz
> > >
> > >
> > > ------- End of Forwarded Message
> > >
> >
> > ===============================================================================
> > Robb Kambic                                Unidata Program Center
> > Software Engineer III                      Univ. Corp for Atmospheric 
> > Research
> > address@hidden                   WWW: http://www.unidata.ucar.edu/
> > ===============================================================================
> 

===============================================================================
Robb Kambic                                Unidata Program Center
Software Engineer III                      Univ. Corp for Atmospheric Research
address@hidden             WWW: http://www.unidata.ucar.edu/
===============================================================================