axxel

@LibRaw Thanks for your input from my side as well (and sorry again for my tone earlier - I just spend so much time on this and saw it all...

> because decode of cr2 files was really slow I can only agree with that. I used dcraw in my original design as well. Having pretty much all of my...

> I'm wiling to bet that they are not Rust names, but linux Meaning what exactly in the context of my question? If you have an opinion about 1) and/or...

> No, at this point i'm unable to state my opinion/choice. Ok. > But, in either case the changes will be rather intrusive so it will be better to not...

Very good. I'll do that then (the consistent `size_t` introduction).

This turned out to be less of a no-brainer than I thought: simply switching from a 32bit `size_type` to a 64bit one introduces overload resolution issues. The problem is, that...

> So if we pick the linux/rust types, what are the PRINTF(3) specifiers for them? The exact same as with the current type names? My intention with 1) was simply...

Because your question makes me suspect you had a different understanding of what exactly I was talking about in section 1): I'm suggesting to replace `using ushort16 = unsigned short;`...

@LebedevRI @schenlap @LibRaw any feedback on this? (I guess a developer mailing list would have been the better place to post this, but since there is none...)

That is what I also wanted to suggest in the "how to get there" department after there has been some consensus on what the library should behave, as seen from...