Documentation of and access to M-ARRAY being contiguous

[BrianSipos]

The current main documentation for M-ARRAY in the README.md does not explicitly state that the array allocation is contiguous in memory and there is no way to access the memory explicitly. From inspecting the source I can see this is the case currently, but having a stable guarantee would be nice.

mlib/m-array.h

Lines 182 to 186 in 2c0db40

	typedef struct M_F(name, _s) { \
	size_t size; /* Number of elements in the array */ \
	size_t alloc; /* Allocated size for the array base */ \
	type *ptr; /* Pointer to the array base */ \
	} array_t[1]; \

It would be nice if the documentation explained that the array guarantees contiguous memory and if there was a name_data() type access function similar to how std::vector::data() operates.

[P-p-H-d]

Technically, the objects in the array may not be contiguous. Some padding may be present between each object (for example with struct s{ char x[3]; }

I don't see the point of having such an API (std::vector::data). Not that I have any plan to change the internal representation, but I really don't like such low level API that break encapsulation of a container.

Why do you need such an API or such a property?

[BrianSipos]

My actual desire is to have a sequential bytestring builder the same way that the m_string_t allows sequential text string building. I could do this with an M-Array of uint8_t but would need some stable way to use the raw array. I know this can be done today using non documented access but would prefer if there was a documented way.

Alternatively maybe some guidance about how an m_string_t could be used with non text data (e.g. what functions to avoid using) would also meet the desire.

[P-p-H-d]

I can see potential solutions

• A new API for array:

** void name_acquire_direct_access(type **ptr, size_t *size, name_t array) : acquire a direct access to the container array. While the direct access is acquires, no function of array can be called except :
** void name_release_direct_access(name_t array, type *ptr, size_t size); : release the direct access. The array functions works normally now.

I have yet to find how to make it works with the exception model. What should happen if an exception occurs within the direct access? Mmmmm.....

• Using a custom serializer for your needs? using _out_serial. I am not sure it will work.

• Allow \0 in strings. At first glance, several API fuctions already support it (even if the slow assertion fails, it is not enabled by default, only in test mode): string_init, string_init_set, string_equal, string_push_back, string_size, string_capacity, string_reserve, string_get_cstr, string_clear, string_clear_get_cstr, string_reset, string_set_char, string_empty_p, string_set, string_set_n, string_init_move, string_move, string_cat, string_left, string_right, string_mid, string_hash, string_get_str, string_parse_str, string_out_str, string_in_str, string_out_serial, string_in_serial,