msvc branch

Hauke Heibel hauke.heibel at googlemail.com
Thu May 6 13:15:56 EDT 2010


On Thu, May 6, 2010 at 6:21 PM, Adam Goode <agoode at andrew.cmu.edu> wrote:
> I think I may have broken fill_input_buffer in the JPEG backend again,
> but I seem to remember that particular function changing its signature
> between libjpeg versions. I suspect the cast you had originally won't be
> correct in all cases, so it might need fancier macros to fix.

I see, specifying the calling convention was not a good idea. I needed
to reintroduce the case though this time I omitted the calling
convention. If that doesn't work, we have to use ifdefs.


> I haven't gone through all your changes yet, especially your goto scope
> stuff, but things are looking promising. I don't have much time right
> now, but hope to get things fully integrated eventually.

I introduced the scope stuff due to the 'goto' declarations. GCC
complains without it. I think it is because of the following scenario.
In the example below, foo goes out of scope at the end of the function
and thus the compiler must take care of proper destruction. The
problem is that the goto statement skips the initialization of the
object to be destroyed which may lead to problems, so GCC barfs.

void bar()
{
goto FAIL;
  int foo = 0;
FAIL:
  return false;
}

There are two options to resolve this. Either put the variable in its
own scope which should end before the label FAIL or move the
initialization to the top of the function. In the beginning I opted
for the scope but as soon as you have many goto statements it becomes
intractable - the only sane option is to move the initialization of
the variable to the top of the function (before the first goto call).
The scope thing which you saw is a left-over and could be replaced by
moving the variables. Anyways, it should not hurt.

- Hauke


More information about the openslide-users mailing list