fix mac address for rndis response

[hathach]

• remove cflags -fshort-enums
• clean up webserver descriptor

this PR will fix the issue with optimization option with tud_descriptor_string_cb() for #304 . The option accidentally allow the existence of tud_network_mac_address. GCC is very smart to detect that tud_network_mac_address isn't used since the OID_802_3_CURRENT_ADDRESS, OID_802_3_PERMANENT_ADDRESS only use the pointer address only.

Again, Linux driver is more forgiving on this matter than Windows :D

[pigrew]

Can you remove the suppression of the lto-type-mismatch warning, and check if you get errors? I think the short-enum thing isn't yet correct.

[pigrew]

@hathach, I'm still getting the warnings about the enum size mismatches, but I'm willing to just say it's due to my older version of gcc 7.3....

I'm happy to accept this PR, as it's likely my enum issues are something unique to my installation. I'll let you know if I solve it. Removing the warning suppression means that if this issue happens for others, it'll be evident.

Yeah, there is reason that option is there. I was using gcc 7 back then. Eventually it will go away.

[pigrew]

@hathach
Just updated to gcc 9.2.1 toolchain from the ARM website, and still getting Warnings. Ugh.

Adding -fshort-enums to CFLAGS in board.mk "fixes" it, but I don't know why I'm getting the warning, but you are not.

[hathach]

@pigrew I have no idea, I installed it from the xpac https://github.com/xpack-dev-tools/arm-none-eabi-gcc-xpack since there is no official apt any more. It is the same as ci which doesn't throw out warnings as well. What is your warning message ?

[pigrew]

@pigrew I have no idea, I installed it from the xpac https://github.com/xpack-dev-tools/arm-none-eabi-gcc-xpack since there is no official apt any more. It is the same as ci which doesn't throw out warnings as well. What is your warning message?

Perhaps I should do a fresh checkout of tinyusb... (ADDENDUM: didn't help)

Bunches of lines like:

c:/program files (x86)/gnu tools arm embedded/9 2019-q4-major/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/bin/ld.exe: warning: c:/program files (x86)/gnu tools arm embedded/9 2019-q4-major/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/lib/thumb/v6-m/nofp\libnosys.a(isatty.o) uses variable-size enums yet the output is to use 32-bit enums; use of enum values across objects may fail
c:/program files (x86)/gnu tools arm embedded/9 2019-q4-major/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/bin/ld.exe: warning: c:/program files (x86)/gnu tools arm embedded/9 2019-q4-major/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/lib/thumb/v6-m/nofp\libnosys.a(lseek.o) uses variable-size enums yet the output is to use 32-bit enums; use of enum values across objects may fail

[hathach]

@pigrew I have no idea, I installed it from the xpac https://github.com/xpack-dev-tools/arm-none-eabi-gcc-xpack since there is no official apt any more. It is the same as ci which doesn't throw out warnings as well. What is your warning message?

Perhaps I should do a fresh checkout of tinyusb... (ADDENDUM: didn't help)

Bunches of lines like:

c:/program files (x86)/gnu tools arm embedded/9 2019-q4-major/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/bin/ld.exe: warning: c:/program files (x86)/gnu tools arm embedded/9 2019-q4-major/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/lib/thumb/v6-m/nofp\libnosys.a(isatty.o) uses variable-size enums yet the output is to use 32-bit enums; use of enum values across objects may fail
c:/program files (x86)/gnu tools arm embedded/9 2019-q4-major/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/bin/ld.exe: warning: c:/program files (x86)/gnu tools arm embedded/9 2019-q4-major/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/lib/thumb/v6-m/nofp\libnosys.a(lseek.o) uses variable-size enums yet the output is to use 32-bit enums; use of enum values across objects may fail

This is probably the issue with pre-built nanolib library by ARM on windows, the pre-built from XPacks can have slightly difference. Let's revert to have short-enum back, we could revisit this later on. Surely it is there for a reason :)