IPP Mail Archive: Re: IPP>PRO: sorry, binary is better (?)

Re: IPP>PRO: sorry, binary is better (?)

Sylvan Butler (SBUTLER@hpbs2024.boi.hp.com)
Fri, 20 Jun 1997 10:18:59 -0700

>This stuff is really too easy and we shouldn't worry about the
>differences between
>ASCII and binary at this point. The code difference is trivial.

That is what I was thinking on Tuesday 6/17, but actually doing
something with it and covering all the possibilities with ASCII seems
noticably more complex to implement and to test, and for no apparent
benefit.

>I thought we have already made this decision?

Those at the meeting, including myself, had arrived at a
recommendation for the group. That is why I said "sorry" for
opening the issue again.

>You have to have tokenizing capability in an implementation anyway,
>to support the HTTP headers and chunking...

Somewhat different constraints, and conceivably a significantly
different part of the system.

>typedef struct {
> char *attrName;
> int attrLength;
> char *attrValue;
> } ATTR;
>
>/* Most optimizing compilers would attempt to inline the next_delim/next_token functions for performance */
>char *next_delim(char *stream)
>{
> while (!isspace(*stream)) ++stream;
>
> return(stream);
>}
>
>char *next_token(char *stream)
>{
> while (isspace(*stream)) ++ stream;
>
> return(stream);
>}
>
>/* This routine assumes that the current position in the input or buffer stream is placed at the first character of the attribute name */
>
>int GrabAttr(ATTR *pAttr, char *inpstream)
>{
> int sts = OK;
>
> pAttr->attrName = inpstream;
> inpstream = next_delim(inpstream);
> *inpstream++ = '\0';
> inpstream = next_token(inpstream);

I don't think we want to do that. We defined it as one <SP>,
skipping more will throw us off. Just removing next_token should be
fine.

> for (pAttr->attrLength = 0; (isdigit(*inpstream)); inpstream++)
> pAttr->attrLength = (pAttr->pAttrLength * 10) + (*inpstream -'0');
> pAttr->attrValue = next_token(inpstream);

Again.

>
> return(sts);
>}

I like that. Very clean.

It does have the same concern that Bob's raised, that of validating
the assumptions of the buffer containing the next delimiter. It
appears much easier to fix in this version however...

Like the binary solution, just quit making the assumption. With no
library routines then each loop also checks for the end of the data
(by count).

Both text parsers leave us with the need for doing strcmp's, etc. to
match keywords. And for what?

sdb

| Sylvan Butler | sbutler@boi.hp.com | AreaCode 208 Phone/TelNet 396-2282 |