[DRMAA-WG] DRMAA C Binding Issue

[Roger Brobst]

Regarding issue-57, one solution is to modify the
drmaa2.h header as follows
Replace:
     typedef enum drmaa2_limit {
       DRMAA2_CORE_FILE_SIZE = 0,
         . . .
       DRMAA2_WALLCLOCK_TIME = 7
     } drmaa2_limit;

With:
     extern const char *const DRMAA2_CORE_FILE_SIZE;
      . . .
     extern const char *const DRMAA2_WALLCLOCK_TIME;

And stipulate that the implementation library must contain:
     const char *const DRMAA2_CORE_FILE_SIZE = "CORE_FILE_SIZE";
      . . .
     const char *const DRMAA2_WALLCLOCK_TIME = "WALLCLOCK_TIME";


How does the above solution compare to updating drmaa2.h with Macros:
     #define DRMAA2_CORE_FILE_SIZE   "CORE_FILE_SIZE"
       . . .
     #define DRMAA2_WALLCLOCK_TIME   "WALLCLOCK_TIME"

(1) The value of variables can be analyzed in a runtime debugger (to 
check that the variable name is consistent with its value?)

(2) Using variables may reduce the number of copies
of strings in the process (the client and the drmaa
implementation library may share).  This involves
marginal expense for additional symbol resolution.

(3) Using variables is likely to be more natural to
C++ programmers using the C-lang binding.


What are the ~other~ tradeoffs between
     extern const char *const DRMAA2_CORE_FILE_SIZE;
and
     #define DRMAA2_CORE_FILE_SIZE   "CORE_FILE_SIZE"

-Roger


-------- Original Message  --------
Subject: [DRMAA-WG] DRMAA C Binding Issue
From: Peter Tröger <peter at troeger.eu>
To: drmaa-wg at ogf.org <drmaa-wg at ogf.org>
Date: 01/28/2013 05:14 AM

Dear DRMAA friends,

first, a late happy 2013 for all of you. I hope that you make good 
progress in your DRMAAv2 implementation projects.

Daniel Gruber raised a critical issue for the published C binding spec:

https://redmine.ogf.org/issues/57

My proposal would be to follow Daniel's suggestion and fix the reference 
implementation header file:

https://github.com/troeger/drmaav2-mock/blob/master/drmaa2.h

We point the people to this code base anyway, so it is the easiest 
solution for making sure everybody uses the same work-around.
The issue tracker archives the modification until we have enough 
complete implementations for an errata document.

Any opinions ?

Best regards,
Peter.

P.S.: https://redmine.ogf.org/issues/59 might be also worthwhile a look.