Change Os::* handles/descriptors to typedef to better support different OS platform types.

[timcanham]

See this discussion:

#2298

In some cases, defining the file descriptor m_fd to be NATIVE_INT_TYPE can force undesirable patterns like dynamic memory allocation after initialization and nasty typecasts.

This discussion would propose changing the NATIVE_INT_TYPE to a typedef (say PLATFORM_FD_TYPE) that could be defined on a platform by platform basis.

[sobkulir]

Can we make this more general, i.e., give all resource-owning OSAL types their handle macro type? This would allow Zephyr port to almost completely avoid dynamic allocation. As far as I can tell, these are Mutex, Queue, File, Directory, Task, InterruptLock, and WatchdogTimer.

As discussed in #2298, I would add these typedefs to PlatformTypes.h, as FpConfig.h is project-specific, while the issue here is platform-specific. WDYT?

[timcanham]

That is a good idea!

[timcanham]

Changed the title.

[LeStarch]

I am currently refactoring the Os::File interface. I will look into this!

[LeStarch]

After much discussion, it seems we can support this. It will come at the cost of extra memory allocation in some situations. OS implementers will be required to declare a FileHandle class to store any handle type they see fit:

// Linux file handle definition
class FileHandle {
    int file_handle; // Linux uses ints for file handles.
}
static_assert(sizeof(FileHandle) >= FW_HANDLE_MAX_SIZE, "FileHandle too large, increase FW_HANDLE_MAX_SIZE");

This class will be opaquely stored in the Os::File class as a pointer to the opaque type and a bounded byte-array to store the data. In this way we can allocate arbitrary FileHandle on the stack, store them, and not involve dynamic memory, casts, or other issues described here.

It will require a single complicated line for implementers:

void constructInernal() {
    this->m_handle = new(&this->m_handle_storage[0]) FileHandle;
}

This placement-news the arbitrary, but non-opaque, FileHandle class into the available storage and sets the opaque pointer to it. Thus it is usable to the implementer, stored on the stack, and opaque to the rest of F´.

We'd also recommend the above-shown static_assert to ensure that the byte buffer can store the full non-opaque type.

[LeStarch]

When I have finished the refactor, I will post the PR here for clarity.