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

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

Sylvan Butler SBUTLER at hpbs2024.boi.hp.com
Fri Jun 20 13:18:59 EDT 1997


>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 at boi.hp.com | AreaCode 208 Phone/TelNet 396-2282 |



More information about the Ipp mailing list