Issue #2910 has been updated by swildner.

If Linux understands __printf as NULL being allowed for the format, defining 
__printf as __printf0like instead sounds reasonable. I'll leave that to whoever 
brings in such code in the future.

Regarding the second question about having both __printflike and __printf0like, 
I'm not sure I understand. As long as __printflike implies __nonnull, we need 
an extra macro for cases where a NULL format shall be allowed. If we removed 
__nonnull__ from __printflike, we'd have to add __nonnull to all prototypes 
that have __printflike right now, in order to not lose these checks.


----------------------------------------
Bug #2910: Rethinking __printflike in the context of drm's __printf
http://bugs.dragonflybsd.org/issues/2910#change-12870

* Author: davshao
* Status: New
* Priority: Normal
* Assignee: 
* Category: 
* Target version: 
----------------------------------------
Currently DragonFly drm defines __printf to be __printflike.  It seems likely 
to me that Linux drm actually expects behavior __printf0like, without the 
__nonnull__(fmtarg) attribute.  

For example, more recent versions of Linux drm want to define a function like 
this:

extern __printf(6, 7)
int drm_crtc_init_with_planes(struct drm_device *dev,
                              struct drm_crtc *crtc,
                              struct drm_plane *primary,
                              struct drm_plane *cursor,
                              const struct drm_crtc_funcs *funcs,
                              const char *name, ...);

and call it sometimes (well strangely enough, so far all of the time) with name 
== NULL.
Then inside the newer versions of the function is something like this:

        if (name) {
                __va_list ap;

                __va_start(ap, name);
                crtc->name = kvasprintf(GFP_KERNEL, name, ap);
                __va_end(ap);
        } else {
                crtc->name = kasprintf(GFP_KERNEL, "crtc-%d",
                                       drm_num_crtcs(dev));
        }

The obvious fix is in sys/dev/drm/include/linux/compiler.h
to redefine __printf as __printf0like.

For curiosity's sake, given the gcc 4+ series of compilers now used for 
DragonFly in 2015
as opposed to 2004 when the __printflike and __printf0like distinction was 
made, is it
still necessary to have both __printflike and printf0like?



-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
http://bugs.dragonflybsd.org/my/account

Reply via email to