Truncate MIDI SysEx messages after termination byte

[Christian Costa]

2013/1/10 Johannes Kroll <jkroll at lavabit.com>

> On Thu, 10 Jan 2013 12:04:02 +0100
> Christian Costa <titan.costa at gmail.com> wrote:
>
> > In your code you stop checking F7 just before the last byte (until
> > position lpMidiOutHdr->dwBufferLength-2);
> > You can check the last byte as well. This is also valid and simplify the
> > condition.
> > The missing F7 byte case is handled by the for loop.
>
> Ah, you mean that check. Yes, it's not strictly necessary, it just
> decides whether it has to save & restore dwBufferSize or not.
>
>
> > Regarding the single MMDRV_Message call, I was thinking about something
> > like below.
> > This also enable printing a WARN when F7 is missing which can be useful
> for
> > debug.
> >
> >     DWORD oldBufferLength = lpMidiOutHdr->dwBufferLength;
> >     DWORD ret;
> >
> >     for(i = 0; i < lpMidiOutHdr->dwBufferLength; i++)
> >
> >        /* SysEx messages are terminated by a 0xF7 byte. If the buffer
> > contains additional
> >           bytes, send only the bytes up to the termination byte. */
> >         if((unsigned char)lpMidiOutHdr->lpData[i] == 0xF7)
> >         {
> >             lpMidiOutHdr->dwBufferLength = i+1;
> >
> >             break;
> >
> >         }
> >
> >
> >     if (i == lpMidiOutHdr->dwBufferLength)
> >
> >         WARN("SysEx termination byte 0xF7 missing\n")
> >
> >
> >
> >     ret =  MMDRV_Message(wmld, MODM_LONGDATA, (DWORD_PTR)lpMidiOutHdr,
> > uSize);
> >
> >     /* restore the midi header to its original state. */
> >     lpMidiOutHdr->dwBufferLength = oldBufferLength;
> >
> >
> >     return ret;
>
> I see nothing wrong with that apart from the broken formatting (please
> don't use HTML mail). Did you test it?
>
>
It was not intended to be used as is. It's just to show what I had in mind.


> I don't care which version is used, I would just be very happy if
> *something* is included which makes my MIDI device work with Wine.
>

There is no reason your patch will not get in. Generally, it's just patches
need
to have the quality required to be committed. Sometime it can takes several
iterations.



>
> How does this generally work here, will there be feedback from a
> maintainer on whether the patch will be included, or is it usually just
> silently included?


> Alexandre Julliard (or whoever decides this): Could you comment please?
>
>
>
For a patch which is ok, it will be committed silently by Alexandre. You
may already
know the patches status page at http://source.winehq.org/patches.
Usually maintainers or skilled people of a specific area look at patches and
give some feedback if something seems wrong or not clear.



> And Christian, please, configure your mail client. The list mails I get
> from you are directed to me, not the list, and they are missing the
> List-Id field.
>
>
> When I use gmail web client, I don't have good results sometimes. Maybe
there is a configuration for that.
I'm full open to any hint.
Regarding emails addresses, I write to someone with wine-devel in cc but
I'm ok to use
only wine-devel with you.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20130110/b57256db/attachment-0001.html>