For STM32_USB_Device_Library please provide a version symbol

[waclawek.jan]

In STM32_USB_Device_Library for 'L4, ST kindly changed a key struct definition between versions, changing amongst other things the type of pUserData from plain pointer to an array of pointers.

That of course threw a bunch of errors in related user code.

For one of my clients, I need to maintain some code which uses this library (legacy thing, client does not change that). It's been built on several machines and some of them for reasons beyond my control have been updated with a newer version of CubeL4, resulting in that bunch of errors.

I would like to fix the user code in a way which is compatible with both versions of the STM32_USB_Device_Library . It would be nice to have a preprocessor symbol defined for the Library Version (so that this affair can be solved purely by conditionals with no runtime code) but I can't find any.

If the answer is "oh, there's none", then consider this to be a feature request.

JW

[BarryWhit]

I mention this only as a very dirty workaround if ST doesn't come through.

`sizeof(struct)` is determined at compile-time. So, you if include a conditional based on it, the compiler should optimize away all but one branch, and then it would optimize away the conditional entirely and simply inline the body, resulting in zero run-time overhead.

 

#include <stdio.h>
#include <stddef.h>

struct a {
 int b[10];
};

#define LIBVER (sizeof(struct a) > 4 && offsetof(struct a,b) == 0 ? 0x55 : 0xaa)

int main(int argc, char const *argv[]) {
 printf("%x\n", LIBVER);
 return 0;
}

$ gcc -g -O2 -o 1 ./1.c

(gdb) disassemble main
Dump of assembler code for function main:
 0x0000000000401040 <+0>: sub rsp,0x8
 0x0000000000401044 <+4>: mov esi,0x55
 0x0000000000401049 <+9>: mov edi,0x402010
 0x000000000040104e <+14>: xor eax,eax
 0x0000000000401050 <+16>: call 0x401030 <printf@plt>
 0x0000000000401055 <+21>: xor eax,eax
 0x0000000000401057 <+23>: add rsp,0x8
 0x000000000040105b <+27>: ret

 

Update: extended to show use of offsetof(type,name), which may prove useful as well.

[waclawek.jan]

Thanks.

I of course don't wait until ST comes up with something, that's why it's more of a feature request or rant.

Btw., Cube as such might benefit from having the version symbols exposed, rather than having them behind stub functions.

JW

[Andrew Neil]

---

@waclawek.jan wrote:

Btw., Cube as such might benefit from having the version symbols exposed, rather than having them behind stub functions.

---

+1 to that! :thumbs_up:

There's been plenty of threads in the past which would have benefitted from that!

Typical case is when someone "inherits" an old project - and doesn't know what version(s) of ST code were used.

@FBL 

[FBL]

Hi @waclawek.jan 

Thank you for reporting this issue.

An internal ticket 185284 has been reported to make the necessary changes.

[Saket_Om]

Hello @waclawek.jan 

 

Thank you for bringing this issue to our attention.

I reported this internally.

Internal ticket number: 185288 (This is an internal tracking number and is not accessible or usable by customers).

[Saket_Om]

Hello @waclawek.jan 

This update was made to support composite since a while now, it was deployed in other STM32 products since 2022. Now user should update his application to be aligned with this update.

[Andrew Neil]

So now we have 2 tickets: 

1. 185284 raised by @FBL 
2. 185288 raised by @Saket_Om 

Are they both addressing the same issue, or is one about the original, specific issue with STM32_USB_Device_Library for 'L4, and the other about the more general issue with ST-supplied code?

[waclawek.jan]

> Typical case is when someone "inherits" an old project - and doesn't know what version(s) of ST code were used.

There *is* a versioning system in place, but those symbols are private to that .c, and they are exposed through a function. This is not always the optimal solution.

I normally don't use Cube so don't care; here I am trying to accomodate external requirements.

JW

[waclawek.jan]

Hi @Saket_Om ,

I am not questioning the changes as such here.

I am requesting symbols holding the version numbers, so that I can write my portion of code in a way which can use *either* version of the library. Blindly accomodating updates is not an option.

And I would like that to be as compile-time as possible for efficiency reasons, thus functions returning the version are not adequate for that.

JW