memory stream API?

[Alpha (Hin-Chung) Lam]

Hello Chromium people,

I'm reviewing a piece of code and wonder if we have any base code that can take a memory pointer and parse it into various data types, e.g.

class MemoryInputStream {

  MemoryInputStream(const StringPiece& buffer);

  void Read(int bytes, uint8* output);

  void ReadUInt8(uint8* output);

  void ReadInt8(int8* output);

  void ReadUInt16BE(uint16* output);

  void ReadInt16BE(int16* output);

  // ... etc.. you know what I mean.

};

or write various data types to a string buffer, e.g.

class MemoryOutputStream {

  MemoryOutputStream(std::string* buffer);

  void Write(int bytes, uint8* data);

  void WriteUInt16BE(uint16* output);

  // ... yeah many of them ...

};

I've written some of these little endian / big endian code it seems to me there's more places that duplicates these functions now, e.g. media, network, crypto and even now in the speech code too.

Any suggestions here?

Alpha

[Denis Lagno]

base/pickle*?

> --
> Chromium Developers mailing list: chromi...@chromium.org
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-dev
>

[Alpha (Hin-Chung) Lam]

I mean size is not know..

2011年8月10日14:04 Alpha (Hin-Chung) Lam <hc...@google.com>:

There's several limitations of this class:

1. Doesn't support endianess.

2. Doesn't append to the stream if the size of now known.

Alpha

2011年8月10日13:59 Denis Lagno <dil...@chromium.org>:

[Alpha (Hin-Chung) Lam]

There's several limitations of this class:

1. Doesn't support endianess.

2. Doesn't append to the stream if the size of now known.

Alpha

2011年8月10日13:59 Denis Lagno <dil...@chromium.org>:

base/pickle*?

[Jonathan Dixon]

I thought I'd seen something like this in net/ but beats me. Certainly http_auth_handler_ntlm_portable.cc seems to just roll its own (for example).

[Brett Wilson]

On Wed, Aug 10, 2011 at 6:04 AM, Alpha (Hin-Chung) Lam <hc...@google.com> wrote:
> There's several limitations of this class:
> 1. Doesn't support endianess.

Why do we need to support endianness in this case?

Chrome has never compiled on any big endian platform and likely never
will. We've explicitly not handled endianness. If you have code that
you know will be sensitive to endianness, write a compiler assert or
something so if we ever port, people will know to write big endian
versions of your functions.

Brett

[Alpha (Hin-Chung) Lam]

What I mean here is write a be16 or be32 to a buffer or reading a be16 or be32. This is quite common in network or crypto code.

Alpha

2011年8月10日16:21 Brett Wilson <bre...@chromium.org>:

[Denis Lagno]

For example, we speak websocket protocol, and it uses network order of
bytes (big endian).
The only alleviation that it is done in WebKit, not chromium itself.

[Wez]

Don't most platforms provide htons() and htonl(), which take care of endian-swapping to big-endian, and will continue to work even if Chrome ends up on a big-endian platform?

Wez

[Denis Lagno]

They do. Following satisfies all trybots:

#if defined(OS_WIN)
#include <winsock2.h> // for htonl
#else
#include <arpa/inet.h>
#endif

However htonl is still 32-bit, not 64-bit.