How to use same structure for two different platforms?

What do you mean, "does not exist"? Shirley, *you* decide what does and does NOT exist... (or, is this part of a commercial API you are licensing?)

Why can't you wedge those into the frqqd_config_t struct -- leaving unused members "undefined" (or, init to some arbitrary constant) and change data types accordingly for, e.g., the differences in "primary_channel"?

Presumably, you are also rewriting the code that *uses* these structs/types. So, do you need to support *both* in your code base? Or, can you just fork your development off at this point and abandon the old API?

Why are you using a pointer to a struct (type) in one case and the struct itself in the other? What makes the most *sense* to the design of the application -- does the frqqd_config_t belong *in* the spdwdir_config_t or should the spdwdir_config_t *reference* it instead?

The exact nature of your problem is unclear. Why not ask whomever changed the API *why* the changes were made and look at how that *intuitively* reflects on the design of the code. E.g., if they are intended to be compatible -- or not!

is

layer

new.

the

structure frqqd_config_t doesn't exist in new platform because it is owned by

lower layer library and they decided to remove it from the new platform. Their thought is that application may not need to provide frqqd configuration. Default frqqd configuration will be provided by the lower layer library. If

default frqqd configuration doesn't work for the application, they can change it by calling APIs.

This is not part of commercial API we are licensing.

pointer structure spdwdir_config_t is passed to lower layer library. If I init parameters, how will they get passed to lower layer library.

It doesn't exist in new platform.

Yes, both need to be supported in our code base.

struct frqqd_config_t exists in old platform. For new platfrom, I'm proposing pointer to new struct app_frqqd_config_t. Or it can be struct

itself. I asked which is preferred?

Yes.

--------------------------------------- Posted through

Anything not present in the API to that level *can't* be present in the gazintas and cumzoutas of your higher level. Period. That's the whole point of the interface contract.

You *might* choose to implement a frqqd_config_t (or similar) in an upper layer -- if it has some value to *that* layer. You just can't pass it across that interface.

OK. And, how does the upper layer *inspect* the "current state" of that struct (without giving it a name)?

So, you have: error_t get_tpu(&int) error_t set_tpu(int) error_t get_primary_channel(&int) error_t set_primary_channel(int) etc.? I.e., otherwise, how can you examine the current state of the struct in order to decide how you would *like* to change it?

If you have no control over the interface, then my suggestion doesn't apply -- you can't deviate from That What Hath Been Written.

Think of what the *data* suggests. Does the object make sense as an object in its own right? Could/would it stand on its own? Is it likely to be *shared* (referenced) by two or more things?

E.g., if there are 4 children in your family and you had to describe each of them, would you say:

typedef struct { char name[BUFSIZ]; int age; char mothers_name[BUFSIZ]; char fathers_name[BUFSIZ]; ... } child_t;

or, would you say:

typedef struct { char name[BUFSIZ]; int age; parent_t *mother; parent_t *father; ... } child_t;

typedef struct { char name[BUFSIZ]; ... } parent_t;

Note that the data model can suggest one, the other or even *both* of these approaches. And, whichever you choose has associated consequences.