Re: [PATCH 2/3] drm: move edid null check to the first part of drm_edid_block_valid
On Mon, Jul 01, 2013 at 07:06:32PM +0900, Seung-Woo Kim wrote: If raw_edid is null, it will crash, so checking in bad label is meaningless. It would be an error on part of the caller, but the defense looks sane. As the function is a bool, I would have preferred it returned true/false, but your patch is correct wrt to the rest of the function. Signed-off-by: Seung-Woo Kim sw0312@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com Reviewed-by: Chris Wilson ch...@chris-wilson.co.uk -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm: move edid null check to the first part of drm_edid_block_valid
On Mon, Jul 1, 2013 at 12:21 PM, Chris Wilson ch...@chris-wilson.co.uk wrote: On Mon, Jul 01, 2013 at 07:06:32PM +0900, Seung-Woo Kim wrote: If raw_edid is null, it will crash, so checking in bad label is meaningless. It would be an error on part of the caller, but the defense looks sane. As the function is a bool, I would have preferred it returned true/false, but your patch is correct wrt to the rest of the function. If we consider passing a NULL raw_edid here a caller-error, shouldn't this be a WARN on top? And I concur on the s/0/false/ bikeshed, return 0 could be misleading since for errno returning functions that reads as success. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/3] drm: move edid null check to the first part of drm_edid_block_valid
Hi Daniel, On 2013년 07월 01일 23:56, Daniel Vetter wrote: On Mon, Jul 1, 2013 at 12:21 PM, Chris Wilson ch...@chris-wilson.co.uk wrote: On Mon, Jul 01, 2013 at 07:06:32PM +0900, Seung-Woo Kim wrote: If raw_edid is null, it will crash, so checking in bad label is meaningless. It would be an error on part of the caller, but the defense looks sane. As the function is a bool, I would have preferred it returned true/false, but your patch is correct wrt to the rest of the function. If we consider passing a NULL raw_edid here a caller-error, shouldn't this be a WARN on top? And I concur on the s/0/false/ bikeshed, return 0 could be misleading since for errno returning functions that reads as success. Yes, you are right. WARN_ON() is better because there was no crash until now. and I will also update all return values as false/true instead of 0/1. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel -- Seung-Woo Kim Samsung Software RD Center -- ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
