Detect array buffer lengths automatically

[Exiled1]

What is the feature you'd like to have?
Please provide a clear and concise description of what you want.

The ability for binary ninja to analyze a function, notice a buffer of a static size, and fill in the type and size of the array would be a very nice to have feature. Currently for basically every single array buffer, binary ninja just shows it as a void* and calls it good. The problem with this is that the void type is greyed out and combined with the fact that binja sometimes thinks that a variable isn't being used and greying out the whole line, the manual retyping process can get annoying. Ghidra has had this form of length auto detection for absolute ages, same with Ida, so it'd be nice for binary ninja to do the same.

Is your feature request related to a problem?
If applicable, please provide a clear and concise description of what the problem is.
The problem is mainly visibility. For the most part this is a nice to have but not really a deal breaker.

Are any alternative solutions acceptable?
Please provide a clear and concise description of any alternative solutions or features you've considered.

Yes, usually these types of buffers are next to a malloc call and it's normally pretty clear to figure out the size based on nearby context, then change the type to be something like char foo[0x30], to match what's shown. It's acceptable, just annoying to do manually when tools like Ghidra have had automatic buffer length detection for ages.

Additional Information:

An example is the highlighted lines, the buffer is clearly next to a malloc with a static size, and it's used in the strlen function as well, I don't really expect for the type to be filled in. But it should at least be pre filled as an array of 0x30 items, although in Ghidra, this is shown as a char foo[0x30] from the beginning.

Please add any other context or screenshots that would help us understand your feature request here.

[xusheng6]

Related to #2570 -- but I would say this particular case is simpler that #2570, but it is also quite often seen in actual RE process. So maybe we can solve a simpler case first before we dive into the more complex one?

[plafosse]

As #2570 is currently being worked on I'm going to close this issue in favor of that one.