GSoC IPPServer Functionality #120 #121 #122

[aakashlahoti]

No description provided.

[michaelrsweet]

Reopening so we can track these changes and make corrections as needed to fix the build.

[michaelrsweet]

@aakashlahoti Added review comments to pull request...

[michaelrsweet]

If the syntax is:

"string"(language)

then we need to verify that the token we've read starts and ends with "(" and ")".

[michaelrsweet]

Parse the value string into a buffer, don't copy/move stuff around. The buffer just needs to be 32767 bytes, e.g.:

unsigned char data[32767], *dataptr = data;
char *valptr = value + 1;

do
{
  while (isxdigit(valptr[0]) && isxdigit(valptr[1]))
  {
     // Decode hex digits and store in *dataptr;
     valptr += 2;
     dataptr ++;
     if (dataptr >= (data + sizeof(data))
       break;
  }

  if (*valptr == '>')
    break;
  else if (*valptr)
  {
    report_error(...);
    return (0);
  }

  if (!_ippFileReadToken(f, value, sizeof(value))
  {
    report_error(...);
    return (0);
  }

  valptr = value;
}

// data contains data, "dataptr - data" contains length

[michaelrsweet]

Use the same code for IPP_TAG_NAMELANG and IPP_TAG_TEXTLANG (with the two case statements together feeding into the same code).

[michaelrsweet]

Need "tolower" here, as "isxdigit" allows upper and lowercase letters.

[aakashlahoti]

Fixed!

[michaelrsweet]

Don't you need to read another token here?

[aakashlahoti]

Hi!
For input like "my string"(language), the var, value, at line 695, initially contains 'my string' , which then is fed into string.text.
Next a token i.e. (language) is read into var value at line 696, which then is fed into string.language.
I don't think another token needs to be read here, is it ?

[michaelrsweet]

Holding for later merge, pending other upstream changes coming into libcups.

[michaelrsweet]

A modified version of the changes has been accepted into upstream.

The other changes will need to wait for a future CUPS release, sorry...