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@troeger.eu> To: drmaa-wg@ogf.org <drmaa-wg@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.