Property Encoding
- Namespace
- Ubiquity.NET.InteropHelpers
- Assembly
- Ubiquity.NET.InteropHelpers.dll
Encoding
Gets or sets the ExecutionEncoding for the native code
public static Encoding Encoding { get; set; }Property Value
Remarks
On Windows and MSVC (.NET Framework) the default encoding is that of the OS/Platform runtime. On .NET Core/Linux UTF8 has reached a level of common standard that you can assume it is the default unless documented otherwise. Not so much on Windows. [To be fair. there's a LOT more legacy client code targeting Windows to contend with.] This often doesn't matter for const strings as they tend to fall in the ASCII/ANSI (Latin1) encoding ranges. However, that isn't guaranteed, which makes for all sorts of "interesting" latent bugs.
note
Even as well documented and well thought out as LLVM is, it remains silent on this point. Spelunking the build system generated for LLVM itself by CMake there is NOTHING to set either the source or execution encodings for Windows, MSVC or any other tool-set that I can see so they seem to be left at defaults. (LLVM is just an example as it was where this library began, but it is not limited to that.)