Skip to content
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

core: do not use m4 to define PRINTF_FORMAT #1352

Draft
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

hjelmn
Copy link
Member

@hjelmn hjelmn commented Nov 28, 2023

The PRINTF_FORMAT macro is intended to allow changing how libusb gets warnings about coding warnings for internal logging methods. At this time there is only a single definition and it is always used. It is better to just define it in libusbi.h and not bother with the m4.

The PRINTF_FORMAT macro is intended to allow changing how libusb gets warnings
about coding warnings for internal logging methods. At this time there is only
a single definition and it is always used. It is better to just define it in
libusbi.h and not bother with the m4.

Signed-off-by: Nathan Hjelm <hjelmn@google.com>
@@ -100,7 +100,7 @@ extern int ezusb_load_eeprom(libusb_device_handle *device,
/* Verbosity level (default 1). Can be increased or decreased with options v/q */
extern int verbose;

extern void logerror(const char *format, ...) PRINTF_FORMAT(1, 2);
extern void logerror(const char *format, ...);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why remove it here?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think it is actually useful to have it in this particular case. I am not 100% convinced this file should even be including config.h really. Let me run through the code one more time and think this through a bit more. I am not a fan of overloading config.h with things that we shouldn't define using m4. This macro is a good example since the different versions can be determined with a simple #if check.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not 100% convinced this file should even be including config.h really

I'm convinced it shouldn't (logically). A good public example shouldn't use any of the internals sources.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removing this takes away the compiler's ability to warn about messing up the format string, and format string screwups can be a source of security issues.

I agree we don't need m4, autotools, cmake or anything else, we just need to create a WeWishCHadThis.h with a bunch of #if / #else to create a PRINTF_FORMAT macro.

@@ -20,7 +20,8 @@
#ifndef LIBUSB_TESTLIB_H
#define LIBUSB_TESTLIB_H

#include <config.h>
#include "config.h"
#include "libusbi.h"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess this is the disadvantage of not using m4 (and config.h), now "user" programs need to include this internal header file.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, not exactly a user program so it is not terrible for it to use the internal header. It can't use any of the internal methods but can make use of the defines in there.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Even if it is defined by the m4 - it is still unusable by the end-user as no one includes these m4 files into their code-bases direcly.

Things like __attribute__/__format__ are not standard/compiler-specific and this is one of the cases where each mature-enough project, where cross-platform support is needed, defines its own set of support/macros.

Right here we're only leveraging the fact that this is still "our" (libusb internal) code and we can share/use other code indended for the "main" code-base.

@hjelmn
Copy link
Member Author

hjelmn commented Nov 28, 2023

I guess the main thing is I am having second thoughts on the usefulness of:

f2e551a

Putting this in so many different places like that doesn't make much sense. libusbi.h seems like the right place but maybe we should have another internal header specifically for this kind of thing. config.h is mean for things that will change at configure time not static code.

@hjelmn
Copy link
Member Author

hjelmn commented Nov 28, 2023

I am leaning toward a new header: libusb_compat.h that will hold the two compatibility macros we currently define in config.h. These are PRINTF_FORMAT and DEFAULT_VISIBILITY neither of which would exist except that they differ on windows.

@@ -310,6 +310,8 @@ int usbi_vsnprintf(char *dst, size_t size, const char *format, va_list args);
#define LIBUSB_PRINTF_WIN32
#endif /* defined(_MSC_VER) && (_MSC_VER < 1900) */

#define PRINTF_FORMAT(a,b) __attribute__((__format__ (__printf__, a, b)))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

shouldn't it be under ifder/compiler-specific?
I believe this is __GNUC__-specific - MSVC doesn't support it

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

and I believe we need an #else fallback as well

@mcuee mcuee added core Related to common codes Examples Examples labels Nov 29, 2023
@seanm
Copy link
Contributor

seanm commented Jan 6, 2024

+1 for not using m4.

How about just #defining PRINTF_FORMAT in libusb.h, just like LIBUSB_DEPRECATED_FOR and ZERO_SIZED_ARRAY.

@tormodvolden
Copy link
Contributor

This is still WIP or under discussion, right? Feel free to un-DRAFT it when it seems ready,

@tormodvolden tormodvolden marked this pull request as draft July 28, 2024 12:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
core Related to common codes Examples Examples
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants