On Thu, Feb 01, 2007 at 06:33:12PM -0800, Martin Rubli wrote:
> On Thu, 01 Feb 2007 12:12:00 -0800, Luigi Rizzo <[EMAIL PROTECTED]> wrote:
...
> > the other reason for concern is ease of porting to other systems --
> > things like pragmas and attributes are easy to remap with a one time
> > #define, but unnamed extensions are a pain to handle because you
> > have to modify all references to the fields in the source.
> >
> > and of course - there is the issue of code safety, because
> > 1)this feature can cause ambiguous constructs, and 2) it doesn't
> > suggest the programmer that multiple items are sharing the same
> > memory location. The union name at least gives you some hints,
> > especially if you call it 'u' ...
>
> I somewhat agree with the portability part. However, these Linux system
> structures (they're part of V4L2 and, therefore, the official Linux
> kernel) are not designed to be portable.
yes i know - probably not a smart decision given that they define an API,
so the impact is not just on the kernel but also third party
code written for userland.
I find it also somewhat ironical that someone writing GPL code (where
the license claims "... the GNU General Public License is intended
to guarantee your freedom to share and change free software") may
also assert that their code is not designed to be portable, because
this negates the share/reuse principle in the first place.
On the other hand, i understand that changing things now would
be problematic. In my version of videodev2.h i do this:
/*
* This file has some anonymous unions that are invalid for C99,
* but required by some linux apps that use this interface.
* As a workaround, we put a default name of 'u' to them,
* unless the caller compiles with -DANONYMOUS_UNION
* and then we set to the empty string.
*/
#ifndef ANONYMOUS_UNION
#define ANONYMOUS_UNION u
#else
#undef ANONYMOUS_UNION /* clear previous value */
#define ANONYMOUS_UNION /* and set to empty */
#endif
...
union { /* Frame size */
struct v4l2_frmsize_discrete discrete;
struct v4l2_frmsize_stepwise stepwise;
} ANONYMOUS_UNION;
...
so at compile time you can adapt to both dialect.
> of gcc I think you'd have a hard time finding a platform to port V4L2 to
> that doesn't support these constructs.
right - but sometimes you need to build software from various sources
and it is a pain to use different compiler settings for each source file.
> If you want, you can raise the discussion on the V4L2 mailing list. When
i suspect it would turn into a religion war.
For the time being i just wanted to raise the portability issues to
this project, and would just be happy if you would take the
the pros and cons in proper consideration.
thanks for the feeback
luigi
_______________________________________________
Linux-uvc-devel mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
