[cups.bugs] CUPS 1.4.7 IPP Compliance Test failure

[Michael Sweet]

Jerry,

The output doesn't make a whole lot of sense to me since line 4 is a comment ("Verify that the server ...") - almost like getc or ungetc are failing or you have mixed system/GCC headers?


On Aug 17, 2012, at 2:31 PM, Jerry Fowler <jfowler at cerner.com> wrote:
> Currently architecture where this is failing is POWER 5.  I have two machines where I am getting the same result.  I have narrowed it down a bit by adding printf statements at certain places in ipptest.c.
> 
> When I run ipptest.c on the HP-UX platform with these changes I get the following behavior:
> 
> Running IPP compliance tests...
> Performing 4.1-requests.test...
> "4.1-requests.test":
> Comment, got new line
> Comment, got new line
> Comment, got new line
> Comment, got new line
> Comment, got new line
> Comment, got new line
> Comment, got new line
> Comment, got new line
> Comment, got new line
> WS delim txt, ungetting ch = {
> WS space or comment, ch =
> 
> Results from first get_token call - token = {, linenum = 10
> 
> When I run the same mods on AIX I get the following:
> 
> Running IPP compliance tests...
> Performing 4.1-requests.test...
> "4.1-requests.test":
> Comment, got new line
> Comment, got new line
> Comment, got new line
> WS delim txt, ungetting ch = a
> WS space or comment, ch =
> 
> Results from first get_token call - token = attributes-natural-language, linenum = 4
> Unexpected token attributes-natural-language seen on line 4 - aborting test!
> 
> Here is an excerpt from the modified version of ipptest.c (get_token function):
> 
>    if (ch == EOF)
>    {
>      printf("EOF reached \n");
>      return (NULL);
>    }
>    else if (ch == '\'' || ch == '\"')
>    {
>     /*
>      * Quoted text...
>      */
> 
>      quote  = ch;
>      bufptr = buf;
>      bufend = buf + buflen - 1;
> 
>      while ((ch = getc(fp)) != EOF)
>        if (ch == quote)
>          break;
>        else if (bufptr < bufend)
>          *bufptr++ = ch;
> 
>      *bufptr = '\0';
>      return (buf);
>    }
>    else if (ch == '#')
>    {
>     /*
>      * Comment...
>      */
> 
>      while ((ch = getc(fp)) != EOF)
>        if (ch == '\n')
>        {
>          printf("Comment, got new line \n");
>          break;
>        }
> 
>      (*linenum) ++;
>    }
>    else
>    {
>     /*
>     /*
>      * Whitespace delimited text...
>      */
> 
>      printf("WS delim txt, ungetting ch = %c \n", ch);
>      ungetc(ch, fp);
> 
>      bufptr = buf;
>      bufend = buf + buflen - 1;
> 
>      while ((ch = getc(fp)) != EOF)
>        if (isspace(ch) || ch == '#')
>        {
>          printf("WS space or comment, ch = %c \n", ch);
>          break;
>        }
>        else if (bufptr < bufend)
>          *bufptr++ = ch;
> 
>      if (ch == '#')
>        ungetc(ch, fp);
> 
>      *bufptr = '\0';
>      return (buf);
>    }
>  }
> }
> 
> 
>> What architecture are you running on? Power or ???
>> 
>> 
>> On Aug 9, 2012, at 12:14 PM, Jerry Fowler <jfowler at cerner.com> wrote:
>> 
>>>> It also appears that there are multiple places in the ipptest.c code where the message "Unexpected token" can be generated.
>>> 
>>> Correction: it appears that the get_token function in ipptest.c is not recognizing the entire comment statement.
>>> 
>>> The first 10 lines of 4.1-requests.test are as follows (with line numbers):
>>> 
>>>    1  #
>>>    2  # "$Id: 4.1-requests.test 8235 2009-01-13 00:55:16Z mike $"
>>>    3  #
>>>    4  #   Verify that the server requires the following attributes:
>>>    5  #
>>>    6  #       attributes-charset
>>>    7  #       attributes-natural-language
>>>    8  #       printer-uri/job-uri
>>>    9  #
>>>   10  {
>>> 
>>> Even though the message from the test indicates:
>>> 
>>> "4.1-requests.test":
>>> Unexpected token attributes-natural-language seen on line 4 - aborting test!
>>> 
>>> I suspect that there is some bug in this function for the AIX platform at least that is causing it not to recognize line 7 as a comment and storing the "attributes-natural-language" at the first part of token buffer and causing the get_token to throw it out as the first character of token must be a left brace.
>>> 
>>> Does that make sense?
>>> _______________________________________________
>>> cups-bugs mailing list
>>> cups-bugs at easysw.com
>>> http://lists.easysw.com/mailman/listinfo/cups-bugs
>> 
>> _________________________________________________________
>> Michael Sweet, Senior Printing System Engineer, PWG Chair
>> 
> 
> _______________________________________________
> cups-bugs mailing list
> cups-bugs at easysw.com
> http://lists.easysw.com/mailman/listinfo/cups-bugs

__________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair