[DragonFlyBSD - Bug #2910] (Closed) Rethinking __printflike in the context of drm's __printf
    bugtracker-admin at leaf.dragonflybsd.org 
    bugtracker-admin at leaf.dragonflybsd.org
       
    Thu Jun  2 13:45:52 PDT 2016
    
    
  
Issue #2910 has been updated by swildner.
Status changed from New to Closed
Closing this issue.
Whoever brings in Linux code that may pass NULL to a function which itself is decorated with __printf, could change the macro to __printf0like().
----------------------------------------
Bug #2910: Rethinking __printflike in the context of drm's __printf
http://bugs.dragonflybsd.org/issues/2910#change-12915
* Author: davshao
* Status: Closed
* 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
    
    
More information about the Bugs
mailing list