[llvm-dev] RFC: Adding llvm::ThinStream

[Zachary Turner via llvm-dev]

There are two ways that integers can get read/written

1) by calling the function

Error readInteger<T>(T& Dest)

In this case the endianness of the integer is assumed to be that which you
constructed the Reader/Writer with. This is the only way to read something
where the endianness is only known at runtime

2) By calling

Error readObject<T>(const T*& Dest)

In this the underlying bytes are reinterpet_casted to a const T*. So if
endianness matters to you when using this function, it will have to be part
of the type T

So it's not ideal, but you could read each field out of a struct
independently using #1. This kills any performance gain you get by
eliminating copying, but I suspect this is already how the code you have in
mind works.

Or You can do what you said with multiple types and a runtime dispatch

Also you mention byte size. There is currently no mechanism for
reading/writing pointer sized values with runtime specified pointer size,
but this would be only a couple of lines to add.

Also, you can always inherit from the readers/writers and add new methods
if the core methods are insufficient
On Thu, Feb 23, 2017 at 2:25 AM Pavel Labath <labath at google.com> wrote:

> On 22 February 2017 at 19:57, Zachary Turner via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> >> Oh, reinterpret casting... hrm. That kind of file reading/writing scheme
> >> usually makes me a bit uncomfortable due to portability concerns
> (having to
> >> align, byte swap, etc, structs to match the on-disk format can make
> those
> >> structures problematic to work with - if you have to byte swap anyway,
> you'd
> >> need to copy the data out of the underlying buffer anyway, right?)
> >
> > For byte swapping usually this is done by using llvm's endian aware
> types.
> > If you have a struct with a bunch of llvm::support::ulittle16_t's, then
> it
> > doesn't matter what platform you're on, you can reinterpret_cast the
> pointer
> > to that struct, and when you read the values they will be correct.
>
> How would this work if the endiannes and byte size of the struct (e.g.
> ELF header) is only decided at runtime. For example, if I need a
> single piece of code to handle both x86_64 little endian and arm32 big
> endian versions of a struct. Am I supposed to template everything
> based byte size and endiannes (with some runtime dispatch at the top
> level)? Or is this not a use case that you have in mind here?
>
> pl
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170223/1e9475ab/attachment-0001.html>