[sane-devel] DLL backend doesn't work on 680x0 machines

Henning Meier-Geinitz henning@meier-geinitz.de
Sat, 12 Apr 2003 12:42:11 +0200


Hi,

On Fri, Apr 11, 2003 at 06:33:13PM -0500, Dave Huang wrote:
> I've been using an old (68k) Mac running NetBSD as my scanning machine,
> and ever since upgrading it to NetBSD 1.6, SANE quit working--it says
> that it can't find any scanners.

Is this 68k-specific? I'm surprised that nobody else has reported this
problem.

> I just got around to trying to figure out what was wrong, and it turns
> out the trigger was that NetBSD on 68k machines switched from a.out to
> ELF.

Oh, a.out. That was before I started using Unix. I didn't know that
NetBSD used it. What about the other BSDs?

> SANE's DLL backend doesn't work under that scheme, because "op" in
> struct backend is declared as "void *(*op[NUM_OPS]) ()". I.e., a
> function that returns a pointer. However, in the various backends, the
> actual functions generally return SANE_Status, a non-pointer.

I see.

> There are a couple of solutions... keep "op" in struct backend as a 
> function that returns a pointer, and change all the non-void backend 
> operations to actually return a pointer; change "op" in struct backend 
> to a function that returns an integer (such as intptr_t), and change 
> the non-void backend ops to return integers (which they all do already, 
> except for get_option_descriptor);

Changing the SANE API? Well, maybe after the hell has frozen over :-)

> or change the places where the ops 
> are called and cast the function pointer to match the particular op 
> being called, rather than casting the result of the call. E.g., for the 
> above call to init:
> 
>   status = (*(SANE_Status(*)())be->op[OP_INIT]) (&version, auth_callback);

It works (at least on Linux/i386). But I'm getting a warning for all
the lines you changed:

dll.c: In function init':
dll.c:484: warning: function declaration isn't a prototype

Is the warning ok or should I just ignore it? Any way to shut gcc up?

> Since the latter option touches the least amount of code, here's a
> patch:

Thanks.

I'll do some more testing and if that doesn't reveal any problems I'll
apply the patch.

Bye,
  Henning