Date: Thu, 25 Nov 2010 12:20:31 -0500
Subject: Re: [RFC/PATCH v6 02/12] media: Media device
Message-ID: <1q7hf5w7lvslx3nba6ooh9j2.1290705631030@email.android.com>
From: Andy Walls <awalls@md.metrocast.net>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
        Clemens Ladisch <clemens@ladisch.de>
Cc: linux-media@vger.kernel.org, linux-omap@vger.kernel.org,
        linux-kernel@vger.kernel.org, sakari.ailus@maxwell.research.nokia.com,
        broonie@opensource.wolfsonmicro.com, lennart@poettering.net
Content-Type: text/plain; charset=utf-8
Sender: linux-kernel-owner@vger.kernel.org
Content-Transfer-Encoding: 8bit
Content-Length: 1291
Lines: 39

The signedness of char is ambiguous for 8 bit data, which is why an API would normally use u8 (or s8, I guess).

Since this is known to be character data, I would think char would be fine.  I am assuming C compilers would never assume multibyte "char"s.

Regards,
Andy

Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote:

>Hi Clemens,
>
>Thanks for the review.
>
>On Thursday 25 November 2010 10:33:02 Clemens Ladisch wrote:
>> Laurent Pinchart wrote:
>> > +struct media_device {
>> > ...
>> > +	u8 model[32];
>> > +	u8 serial[40];
>> > +	u8 bus_info[32];
>> 
>> All drivers and userspace applications have to treat this as char[], so
>> why u8[]?
>
>Good question. I've copied the V4L2 practice of using u8 (or __u8) for fixed-
>length strings in structures. I can't think of any reason for that.
>
>I will replace u8 with char unless someone comes up with a good reason to keep 
>u8.
>
>-- 
>Regards,
>
>Laurent Pinchart
>--
>To unsubscribe from this list: send the line "unsubscribe linux-media" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
????{.n?+???????+%?????ݶ??w??{.n?+????{??G?????{ay?ʇڙ?,j??f???h?????????z_??(?階?ݢj"???m??????G????????????&???~???iO???z??v?^?m????????????I?