Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorrect error semantics in fluid_midi.c #93

Closed
derselbst opened this issue Nov 16, 2010 · 5 comments
Closed

Incorrect error semantics in fluid_midi.c #93

derselbst opened this issue Nov 16, 2010 · 5 comments
Assignees
Milestone

Comments

@derselbst
Copy link
Member

Sorry to bring this up again -- it's a minor nit-pick, but I am trying to rewrite the implementation of several functions in fluid_midi.c without changing the interface, and the current interface is a bit weird. I'm putting two issues into the one bug report since they're related and minor.

Both of these problems came up in r392, when plcl closed ticket #92. It's very hard to tell from the diff (http://fluidsynth.svn.sourceforge.net/viewvc/fluidsynth/trunk/fluidsynth/src/midi/fluid_midi.c?r1=392&r2=391&pathrev=392) because a lot changed in one commit.

The first issue is in fluid_midi_file_getc, in response to my patch on ticket #92. On line 104, the line "return FLUID_FAILED" was added. However, in my patch I had "return -1". Now FLUID_FAILED just happens to be defined as -1 (so it still works), but this is the wrong constant. Most functions return FLUID_FAILED and the calls check "if (result != FLUID_OK)", but this is not the case with fluid_midi_file_getc (which is emulating fgetc).

All of the calls to fluid_midi_file_getc check for the EOF condition with "if (result < 0)". Therefore, it is correct to return -1 to match these checks. If FLUID_FAILED were changed to a different constant, this code would break. It should be changed to "return -1" (or "return EOF" if you want to use a constant with the same semantics as fgetc).

The second issue is in fluid_midi_file_read. I am not sure what the intention behind this was, but note that on line 128, the check "if (num == len)" was added, preventing mf->trackpos from being incremented if fewer than len bytes were read. Now again, this doesn't matter too much, since it will subsequently return FLUID_FAILED and this will pretty much terminate the loading of the file. But in principle, a bug has been introduced here: the FILE*'s internal read pointer has been advanced by some number of bytes (less than len but possibly greater than 0), but the trackpos has not been incremented, so the state of mf is inconsistent. I would recommend that this be reverted such that mf->trackpos is always incremented regardless of the success or failure of the function.

I have attached a small patch for each of these issues.

Reported by: mattgiuca

Original Ticket: fluidsynth/tickets/94

@derselbst
Copy link
Member Author

Patch for fluid_midi_file_getc

Original comment by: mattgiuca

@derselbst
Copy link
Member Author

Patch for fluid_midi_file_read

Original comment by: mattgiuca

@derselbst
Copy link
Member Author

  • cc jerseychewi added

Original comment by: jerseychewi

@derselbst
Copy link
Member Author

All of the calls to fluid_midi_file_getc check for the EOF condition with "if (result < 0)". Therefore, it is correct to return -1 to match these checks.

You are probably right. However this change exists now for 7 years. And as it was documented properly, I'm not willing to change it back again.

I agree with the second issue and will apply the change.

@derselbst derselbst assigned derselbst and unassigned elementgreen Jul 18, 2017
@derselbst
Copy link
Member Author

Though I agree with the second issue it now contains a note:

Read bytes, even if there aren't enough, but only increment trackpos if successful (emulates old behaviour of fluid_midi_file_read)

For now I'm not willing to change this. Postponed until next major release.

@derselbst derselbst modified the milestones: 1.2, 1.1.7 Jul 29, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants