[SOLVED] Calling convention and procedural type definition / declaration

[d.ioannidis]

Hi,

  I think that Lazarus have a problem parsing a procedural type definition which is marked with calling convention.

  i.e. add to uses clause the fpc's libusb unit and try to  press alt-up ( Find declaration ) or alt-space ( code completion ). It always goes to libusb unit 1043 line :

Code: Pascal  [Select][+][-]

1. libusb_transfer_cb_fn = procedure (transfer:plibusb_transfer);LIBUSB_CALL;

Is it a bug or do I missed some setting ?

I'm using Lazarus trunk r62967 .

regards,

[PascalDragon]

You forgot an important point: how is LIBUSB_CALL declared? I assume it's a macro, right?

[Thaddy]

Indeed. The standard for 32 bit is cdecl, but for Windows it is WINAPI, which in itself is a macro depending on Windows platform (32/64/CE) and for 32 bit intel windows it is stdcall

Code: C  [Select][+][-]

1.   /* LIBUSB_CALL must be defined on both definition and declaration of libusb
2.   * functions. You'd think that declaration would be enough, but cygwin will
3.   * complain about conflicting types unless both are marked this way.
4.   * The placement of this macro is important too; it must appear after the
5.   * return type, before the function name. See internal documentation for
6.   * API_EXPORTED.
7.   */
8.  #if defined(_WIN32) || defined(__CYGWIN__) || defined(_WIN32_WCE)
9.  #define LIBUSB_CALL WINAPI
10.  #else
11.  #define LIBUSB_CALL
12.  #endif

As you can see, for 64 bit AMD/INTEL it is not even important because it is the same on all supported platforms. (API_EXPORTED hint explains all)
If necessary I can resolve this macro for you in FPC style but it is very easy.

[d.ioannidis]

Hi,

You forgot an important point: how is LIBUSB_CALL declared? I assume it's a macro, right?

in {fpcdir}\packages\libusb\src\libusb.pp at line 99, is declared like this :

Code: Pascal  [Select][+][-]

1. {$macro on}
2.  
3. {$ifdef MSWINDOWS}
4.  
5. const libusb1='libusb-1.0.dll';
6. {$define LIBUSB_CALL := WINAPI }
7. {$else}
8. const libusb1='libusb-1.0.so';
9. {$define LIBUSB_CALL := cdecl }
10. {$endif}

regards,

[d.ioannidis]

Hi,

< snip >
As you can see, for 64 bit AMD/INTEL it is not even important because it is the same on all supported platforms. (API_EXPORTED hint explains all)
If necessary I can resolve this macro for you in FPC style but it is very easy.

thank you but it's an fpc package. I assumed, that because my app compiles and run, the problem is in Lazarus parser / codetools "choking" at that line.

regards,

[Thaddy]

Code: Pascal  [Select][+][-]

1. {$macro on}
2.  
3. {$ifdef MSWINDOWS}
4.  
5. const libusb1='libusb-1.0.dll';
6. {$define LIBUSB_CALL := WINAPI }
7. {$else}
8. const libusb1='libusb-1.0.so';
9. {$define LIBUSB_CALL := cdecl }
10. {$endif}

regards,

That is only valid for cpu32, but it should work because stdcall is ignored for cpu64
Please read the code behind my hint. I am too lazy today. The reference is clear. Just look it up....

[d.ioannidis]

Hi,

< snip >
Please read the code behind my hint. I am too lazy today. The reference is clear. Just look it up....

as an non native English speaker, maybe I didn't make my self clear.

The code fragments that I posted, are from an existing fpc package, libusb. The compiler don't have any problem compiling it or any application that is using that package. The "problem" is when I used it in Lazarus.

You can easily reproduce the behavior I'm trying to explain, just by creating an empty project in Lazarus, add the libusb unit to the uses clause, go to a TForm keyword and press Alt-Up . Lazarus will show the line I've mentioned in my first post, with Codetools error message

Code: Pascal  [Select][+][-]

1. libusb.pp(1043,81) Error: expected =, but ; found

.

regards,

[trev]

See: https://bugs.freepascal.org/view.php?id=36752 (looks like the same Codetools and cblock problem to me).

[marcov]

(I filed a bug for the undocumented status of the winapi directive https://bugs.freepascal.org/view.php?id=36924)

[d.ioannidis]

Hi,

(I filed a bug for the undocumented status of the winapi directive https://bugs.freepascal.org/view.php?id=36924)

thank you. I'm monitoring it.

Just out of curiosity. It's an FPC's bug or Lazarus's ? From your bug description, I understand that it's FPC's .

regards,

[marcov]

Hi,

(I filed a bug for the undocumented status of the winapi directive https://bugs.freepascal.org/view.php?id=36924)

thank you. I'm monitoring it.

it is for a different issue

Just out of curiosity. It's an FPC's bug or Lazarus's ? From your bug description, I understand that it's FPC's .

regards,

That is a lazarus bug. Macros are localised to the unit/program where they are declared in, and are not imported by Uses. So lazarus should not find it, since it is not really in scope.

[PascalDragon]

Hi,

< snip >
As you can see, for 64 bit AMD/INTEL it is not even important because it is the same on all supported platforms. (API_EXPORTED hint explains all)
If necessary I can resolve this macro for you in FPC style but it is very easy.

thank you but it's an fpc package. I assumed, that because my app compiles and run, the problem is in Lazarus parser / codetools "choking" at that line.

Yes, that is indeed CodeTools “choking” on that line (you might want to report that as a bug; the missing WinAPI support maybe as well...).

As a workaround you can do the following:
- change the LIBUSB_CALL macro for Windows from WINAPI to stdcall (at least Lazarus 2.0.6 does not like WinAPI yet)
- comment the LIBUSB_CALL in the declaration of libusb_transfer_cb_fn

Don't worry about compilation, FPC will use the precompiled unit anyway, this is just about Lazarus' CodeTools.

[d.ioannidis]

Hi,

< snip >

Yes, that is indeed CodeTools “choking” on that line (you might want to report that as a bug; the missing WinAPI support maybe as well...).

Report https://bugs.freepascal.org/view.php?id=36927 created .

As a workaround you can do the following:
- change the LIBUSB_CALL macro for Windows from WINAPI to stdcall (at least Lazarus 2.0.6 does not like WinAPI yet)

< snip >

Don't worry about compilation, FPC will use the precompiled unit anyway, this is just about Lazarus' CodeTools.

Thank you very much. I'll use this until the issue is resolved.

regards,

[d.ioannidis]

Hi,

  the issue https://bugs.freepascal.org/view.php?id=36927 is resolved . Just tested and it's working .

Thank you very much !

regards,