On 2023-07-11 15:28, Mouse wrote:
I don't get it. Why the "void *" stuff? That is where I think the real badness lies, and I agree we should not have that.But defining something liketypedef struct bus_dma_tag *bus_dma_tag_t;would mean we could easily change what bus_dma_tag_t actually is, keeping it opaque, while at the same time keeping the type checking.Um, no, you get the type checking only as long as "what [it] actually is" is a tagged type - a struct, union, or (I think; I'd have to check) enum. Make it (for example) a char *, or an unsigned int, and you lose much of the typechecking.
Sure. If you declare something as derived from char *, then anything that expects something char * would be happy with it.
But if you say typedef struct bus_dma_tag *bus_dma_tag_t;then any function that expects this will not be happy with something that translates to char *.
Basically, you get as much type checking as you could ever expect/require/demand.
But I could agree with your point of not hiding the pointer in the typedef, and have it explicit as well, for some situations. But for something this opaque, I would actually think the pointer in there makes sense.
Example:
---
typedef struct dma_bus_tag *dma_bus_tag_t;
typedef struct dma_bus2_tag *dma_bus2_tag_t;
int test(dma_bus_tag_t foo)
{
return 0;
}
int foo(void)
{
dma_bus2_tag_t x;
return test(x);
}
---
This fails at compilation because x is not of the correct type for the
function test(). If you change x to be of type dma_bus_tag_t, then the
compilation is happy. Typechecking just as you would expect it, while
being totally unaware of what this type actually looks like.
Something that actually uses the value obviously needs to have the full definition of the structure, and dereference it, and so on. But all other code do not need any of that, and can be kept totally in the dark.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt%softjar.se@localhost || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol