Storable instance of () is broken

[Oleg Grenrus]

https://gcc.gnu.org/onlinedocs/gcc-4.4.3/gcc/Empty-Structures.html#Empty-Structures

> GCC permits a C structure to have no members:

     struct empty {
     };

> The structure will have size zero. In C++, empty structures are part
of the language. G++ treats empty structures as if they had a single
member of type char.

so it's either GCC is absurd, or it isn't.

Standard C also supports zero-width members (to force alignment),
whether to use () for that or not in modelling Haskell-Storable structs.
Could be
useful.https://stackoverflow.com/questions/13802728/what-is-zero-width-bit-field

- Oleg

On 5.1.2022 10.01, Harendra Kumar wrote:
> The Storable instance of () is defined in the "Foreign.Storable"
> module of the "base" package as follows:
>
> instance Storable () where
>   sizeOf _ = 0
>   alignment _ = 1
>   peek _ = return ()
>   poke _ _ = return ()
>
> The size of () is defined as 0. It sounds absurd for a Storable to
> have a size of 0? This means that we can read an infinite number of ()
> type values out of nothing (no memory location required) or store an
> infinite number of () type values without even requiring a memory
> location to write to.
>
> This is causing a practical problem in our Storable array
> implementation. The array is constrained to a Storable type. Since ()
> has a Storable instance, one can store () in the Storable array. But
> it causes a problem because we determine the array element size using
> sizeOf on the type. For () type it turns out to be 0. Essentially, the
> array of () would always be of size 0. Now, we cannot determine the
> length of the array from its byte length as you could store infinite
> such elements in an empty array. The Storable instance of () seems to
> be an oddity and makes us use a special case everywhere in the code to
> handle this, and this special casing makes it highly prone to errors
> when we change code.
>
> Can this be fixed? Is there a compelling argument to keep it like
> this? A possible fix could be to represent it by a single byte in
> memory which can be discarded when reading or writing. Another
> alternative is to not provide a Storable instance for it at all. Let
> the users write their own if they need it.
>
> If you think this does not have a problem, can you suggest how to
> elegantly handle the array implementation problem as I described
> above?
>
> Thanks,
> Harendra
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries