Comedi use of standard types

[Tobin C. Harding]

On Wed, Feb 22, 2017 at 04:51:05PM +0300, Dan Carpenter wrote:
> On Wed, Feb 22, 2017 at 11:46:07AM +0000, Ian Abbott wrote:
> > On 21/02/17 21:27, Tobin C. Harding wrote:
> > >Comedi drivers make heavy use of standard types i.e unsigned
> > >short. According to Linux Device Drivers standard C data types are not
> > >the same size of all architectures.
> > >
> > >Should we be converting comedi/drivers to use kernel types u8, u16 etc
> > 
> > Linux kernel C data types have stricter requirements than the C
> > standard allows.  There is common agreement on the widths of 'char',
> > 'short', 'int', and 'long long', a choice of two widths for 'long'.
> > Signed integers are assumed to use 2's complement representation,
> > and null pointers are assumed to have an "all bits zero"
> > representation. Obviously, the "endianness" of the types will be
> > arch-specific.  (I probably missed some stuff.  For example, I'm not
> > sure if the Linux kernel requires a plain 'char' to be signed.  And
> > I don't know if any of this is officially documented anywhere, so
> > count it as my opinion.)

Thanks for clarifying. So, as I understand it now, as far as kernel
code goes;

u8 <=> unsigned char
u16 <=> unsigned short
u32 <=> unsigned int
u64 <=> unsigned long long

(where <=> means 'is equivalent to')

and

unsigned long is arch dependant.

> char can be signed (x86) or unsigned (s390) depending on the arch, yes.

Point noted.

> 
> > >Follow up question. Some comedi/drivers also use unsigned long for
> > >variables that are not memory addresses. If we are to convert standard
> > >types to kernel types how does one know the intended size of these
> > >variables. I see that the register values come from the manual
> > >
> > >http://www.ni.com/pdf/manuals/340934b.pdf
> > >
> > >Is the choice (size) of type in a struct (eg struct ni_private,
> > >comedi/drivers/ni_stc.h) a kernel design issue or is it a hardware
> > >issue and should I be reading the manual to find it.
> > 
> > It's mostly a design issue.  In general, there is no harm in making
> > local variables wider than they need to be up to 'int' size,
> > although the exact-width types such as 'u16' may be useful
> > sometimes.  In general, structure members and array elements should
> > not be excessively wide.  The use of 'long' or 'unsigned long'
> > should be viewed with suspicion unless there is a specific reason
> > for it.
> 
> Long and unsigned long are fairly normal types used everywhere.

One source said unsigned long are used for memory address, with the benefit
over pointers that they cannot be accidentally dereferenced.

> I don't understand really what Tobin is talking about without a specific
> example.

I won't use up more of you time with a specific example, I think I'm
across it now.

thanks,
Tobin.