[oss-devel] small misc fixes

[François Revol]

Hi,

> > - #define MIDI_DISABLED in oss_config.h, as it's not done unlike 
> > what 
> > the online commented version says.
> >   
> This is defined in the v4.0 "stable" version. However the v4.1 
> "testing" 
> version doesn't have it. The idea is that the MIDI code will be 
> finished 
> in the final v4.1 version.

I see, but I had an undefined midi_operations somewhere, then I found 
this define in the online doc and it seemed to do the job.

> > There are other fixes needed for my platform beside specific code, 
> > but 
> > they are more involved, biggest due to wrong assumptions about 
> > error 
> > code sign due to incoherent standards. But I don't want to spoil 
> > anything yet :)
> >   
> Hmm. Some explanation would be welcome.

http://www.opengroup.org/onlinepubs/009695399/basedefs/errno.h.html
"Values for errno are now required to be distinct positive values 
rather than non-zero values. This change is for alignment with the ISO/
IEC 9899:1999 standard."

I don't know if that was because of this, or just because it seems 
cleaner (IMO it is), but the platform I use does stuff this way:
#define FOO_ERROR LONG_MIN
#define BAR_ERROR (LONG_MIN+1)
#define EFOO FOO_ERROR
...
resulting in POSIX errors not being positive, which has the nice 
advantage of not having to care if you forgot a - when returning them.

However this conflicts with the traditional usage from Unix kernel 
internals of returning -EFOO everywhere to let the syscall handler set 
errno to (-ret), shame usage which seems to spread out of unix kernels 
unfortunately.

I had to fix ffmpeg already, and other stuff.
The only sensible solution is to 

#if EINVAL > 0
#define RETERR(e) (-e)
#else
#define RETERR(e) (e)
#endif

in some global header and dig all the code to replace it with return 
RETERR(EFOO) or return RETERR(errno).

And, no I can't fix my platform, it has been so since the dawn of its 
time.

> > Btw, it could be useful to have a cvs/svn if possible.
> >   
> Our current plan is not to use any cvs/svn style systems. Instead we 
> will produce ~weekly snapshots and use some kind of patch submission 
> system (oss-devel list at this moment). However some kind of file 
> server 
> might be possible later.

Even without giving away write access, doing a cvs up is much simpler 
than diffing against the old org source, removing it, unzipping newer 
twice, patching the newer, ...

> > I suppose some platforms don't imply GNU make so caching `uname -m` 
> > with a
> > unamem=$(shell uname -m) in makefiles to speed it a little won't 
> > work.
> >   
> We have to support the native make commands under each platform so 
> features not available in all of them cannot be used. In addition 
> this 
> kind of optimizations don't improve the compile speed that much.

Yes I thought so.

François.