-
Notifications
You must be signed in to change notification settings - Fork 141
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Silence compiler warnings #1800
Silence compiler warnings #1800
Conversation
Regarding compiler warnings, I'm getting the following one when building git main. No big deal, but I thought I'd mention it.
|
@MCUdude That's a known issue and we cannot do anything about it, as it's MacOS's flex that generates the code. |
@@ -394,10 +394,10 @@ void dfu_show_info(struct dfu_dev *dfu) | |||
msg_info(" USB Product : 0x%04hX\n", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't we also remove the h
and (unsigned short)
cast here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, that would change what happens. Right now printf's %hx will (unsigned short) the promoted int argument that itself already has been (unsigned short)-ed. We can remove either the h
or the (unsigned short)
cast of the (assuming at most int-wide) argument and the print will be the same. If we remove both then something else will be printed if the arg doesn't fit in an unsigned short.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Here an example:
#include <stdio.h>
int main() {
int i = 0x78000;
printf("%04hx\n", (unsigned short) i);
printf("%04x\n", (unsigned short) i);
printf("%04hx\n", i);
printf("%04x\n", i);
}
MinGW build still has some warnings.
|
|
Correct; this was introduced with C99, but we have in the past tried to be even compatible with pre-1999 C-libraries (#1608) so probably better to cast |
I wouldn't do so unless MSVC is still that far behind to require it. |
The C99 discussion was quite recent. Full details at #1594. I don't recall the details, but think someone built AVRDUDE in Windows 7 (that couldn't be upgraded) and the only problem they faced was |
Quite sad, it's only 15 years that have gone since … |
@stefanrueger and @dl8dtl My suggestion is to give up on that paticular configuration -- mingw32 cross compiler toolchain under Windows 7. If you read my comments in #1594, there is no issue using MSVC build and normal MSYS2 mingw32/64 build. |
MSVC is not the problem here. So one less worry. |
@dl8dtl and @stefanrueger and @MCUdude
Let's face it, Windows 7 was released on 22-Sept-2009 and Microsoft stopped the extended support on 10-Jan-2023 (main line support ended on 14-Jan-2020). I think it is perfectly fine that we drop the support of Windows 7 altogether. I do not have Windows 7 machine and I am not so sure if anyone of use still wants to carry out test under Windows 7. Same for Windows 8/8.1 -- both reached EoL status as well. Windows 8.1 reached the end of Mainstream Support on January 9, 2018, and reached the end of Extended Support on January 10, 2023. |
You're right about Win7. But then, I think it's fine to use the 'z' modifier, rather than casting stuff around. |
No issue with that. I just want to establish that we will not officially support Windows 7/8/8.1 from now on. It may still work well. However, if there are issues, we may rely on the users to provide non-intrusive patches if they really care about Windows 7/8/8.1. BTW, MSYS2 has dropped 32bit Windows support of libusb/libusb-compat/libftdi, so we have already dropped 32bit mingw support of avrdude as well. Take note Windows 10/11 only supports x86_64 and not 32bit x86. |
@stefanrueger and @dl8dtl Not sure if we can fix MSYS2 clang64 compiler warnings as well.
|
See here |
Fixes #1799
The
%hd
converts the int argument to short before printing, so I suspect #1799 is a matter of overzealous compiler warning.