>binary protocol. Also, my ANSI C book states that atoi assumes decimal, but
>recommends using strtol as I have done below.
Ahh, yes. How did I miss that...
>int GrabAttr(ATTR *pAttr)
>{
> char * pNext;
> int length;
>
> pNext = strchr(pBuf,' ');
Probably safe given my initial assumption that the buffer would hold
the entire name... But hard for the upper layer to validate.
> pAttr->nNameLength = pNext-pBuf;
> pAttr->pName = pBuf
> pBuf = pNext + 1;
>
> length = strtol(pBuf,&pNext,10); /* ANSI C function */
Doh! Hardcoding the base. I missed that one.
Again, we have the potentially hard to verify issue of searching
forward.
> pAttr->nValLen = length;
> pNext++;
> pAttr->pVal = pNext;
> pBuf = pNext + length;
> return ERROR_OK
>}
Looks good, better than I expected.
I am concerned with how the upper layer can validate the assumption
that the delimiters will be in the buffer for this lower layer. A
"pure" text (with max line lengths defined, CRLF endings, etc) can
read until it gets the entire line (or declare an error when the
line is found to be too long) and know it has the whole thing. With
unknown line lengths it is risky to assume that without verification.
With the binary lengths the GrabAttr doesn't loop searching for
anything and the layer above can compare lengths with the len of data
in the buffer to verify that all is well.
>would expect than an implementation might have a keywordToInt function
>which would map keywords to integers that in turn could be used in
Of course, but remind me again, what does an implementation gain by
having such a function as opposed to just communicating in binary?
>> From SBUTLER@hpbs2024.boi.hp.com Thu Jun 19 18:06:36 1997
...
>> What do we get with ASCII? My list of "pros"
>> from the meeting is really short. The biggest I've been able to
>> identify is vendor extensibility.
[proposal, examples, etc. deleted]
sdb
| Sylvan Butler | sbutler@boi.hp.com | AreaCode 208 Phone/TelNet 396-2282 |