diff options
| author | gman@google.com <gman@google.com@0039d316-1c4b-4281-b951-d872f2087c98> | 2009-07-11 03:32:34 +0000 |
|---|---|---|
| committer | gman@google.com <gman@google.com@0039d316-1c4b-4281-b951-d872f2087c98> | 2009-07-11 03:32:34 +0000 |
| commit | 0288c4228f20e07762c4322a5c2d868d4f61c6f1 (patch) | |
| tree | 3b7bf434d6fec24ca03d171e1b97a67e34555f93 /net/http/partial_data.cc | |
| parent | e99c5a5995b8f00e46f218f48df269ab3ef27071 (diff) | |
| download | chromium_src-0288c4228f20e07762c4322a5c2d868d4f61c6f1.zip chromium_src-0288c4228f20e07762c4322a5c2d868d4f61c6f1.tar.gz chromium_src-0288c4228f20e07762c4322a5c2d868d4f61c6f1.tar.bz2 | |
Document the O3D binary formats.
I just wrote up some small docs to kind of get this out
of the way. If Josie wants to write a more formal doc
to put on the website we can do that but at least with
this it's documented.
Going through it I have a minor concern. The Buffer
format is fine because it spells out exactly how much
data it expects.
The Skin and Curve formats do not so if pass in a
valid offset but an invalid length when you call
Cuvre::Set(myRawData, validOffset, invalidLength)
you get undefined results and possibly no errors
depedning on what data it runs into.
This may or may not matter as it's unlikely the
user will get very far with an invalid length. The
issue is just more that it's possible.
Review URL: http://codereview.chromium.org/155246
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20457 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'net/http/partial_data.cc')
0 files changed, 0 insertions, 0 deletions