[MPlayer-dev-eng] [RFC] defines for demux seek flags

[Reimar Döffinger]

Hello,
On Mon, Jan 28, 2008 at 03:00:56PM +0200, Uoti Urpala wrote:
> On Mon, 2008-01-28 at 13:00 +0100, Reimar Döffinger wrote:
> > > > > -    demux_seek(priv->ad,pos,audio_delay,1);
> > > > > +    demux_seek(priv->ad,pos,audio_delay,(struct seekflags){.absolute=1});
> > > > 
> > > > I find this really, really ugly.
> > 
> > To the question if that's not just because I am not used to the syntax:
> > I doubt that is the reason, I really dislike it when an assortment of
> > special characters band together: (){.=}) - I'm quite sure I'll love
> > LISP before I find this non-ugly. That the "struct seekflags" wastes
> > quite a lot of characters to provide not much information isn't a plus
> > either. If C could do without this "cast" I could probably somewhat like
> > it.
> 
> There aren't that many special characters together, longest is 3
> characters...

I mind more the fact that it uses lots of different ones than the number
of consecutive ones (for that, the "){})){" is a better example).

> Anyway I think this should be a pretty minor issue, there
> aren't many cases of compound literals but quite a lot of other uses of
> the struct. Do you consider this to matter for the overall patch? Any
> comments about the rest?

I really had not intended to have a split of how the flags are handled
between mplayer.c and the demuxer code (and the resulting - admittedly
one line - interface code). This would have been good if the idea was to
give libmpdemux a proper API an MPlayer being a mere user of this
library, but I don't think there is a point in such a break of semantics
in the current situation.

> Personally I'd be OK with committing the current version, but there are
> still 2 things that I think could perhaps be done differently: the
> naming of the 'percent' field and use of 'struct seekflags' vs a typedef
> name.

Well, actually the naming was the only question I _intended_ to ask
about in my first mail.

Greetings,
Reimar Döffinger