hello! It is not clear for me when reading the specification (and it's even worse when looking at the DRMAA implementation or example source code) whether all the "length" parameters (e.g. error_diag_len, job_id_len) are considered as the total size of the buffer (thus including '\0') or only the maximum number of printable characters. For example, from the specification: job name A job name SHALL comprise alphanumeric and _ characters. The drmaa-implementation SHALL NOT provide the client with a job name longer than DRMAA_JOBNAME_BUFFER -1 (1023) characters. but The length of any output context-specific error string SHALL NOT exceed DRMAA_ERROR_STRING_BUFFER. The first implies that I could use: char job_name[DRMAA_JOBNAME_BUFFER]; but for the second I must use: char error_diag[DRMAA_ERROR_STRING_BUFFER + 1]; Please let me know what was your intentions, and for the future, it would be great if you could clarify this issue in the documents. I think you should use "buffer size" term, because "buffer length" is not that clear (sizeof vs strlen). I'm more convinced that the constants define the total buffer size, but some DRMAA example source codes got me confused, e.g. they define variables char foo[DRMAA_JOBNAME_BUFFER] but use DRMAA_JOBNAME_BUFFER - 1 as call arguments. -- Piotr Domagalski
It is not clear for me when reading the specification (and it's even worse when looking at the DRMAA implementation or example source code) whether all the "length" parameters (e.g. error_diag_len, job_id_len) are considered as the total size of the buffer (thus including '\0') or only the maximum number of printable characters.
The DRMAA specification is intended to be language independent, and hopefully talks always about the length of a string. A string is a collection of printable characters, therefore '\0' should not count. Could it be that you talk here about specifics of the C-binding ("error_diag_len", "job_id_len") ?
A job name SHALL comprise alphanumeric and _ characters. The drmaa-implementation SHALL NOT provide the client with a job name longer than DRMAA_JOBNAME_BUFFER -1 (1023) characters.
The length of any output context-specific error string SHALL NOT exceed DRMAA_ERROR_STRING_BUFFER.
The first implies that I could use:
char job_name[DRMAA_JOBNAME_BUFFER];
but for the second I must use:
char error_diag[DRMAA_ERROR_STRING_BUFFER + 1];
This is an ugly inconsistency, which is originated by the "C-thinking" during the original writing of the spec. The next (IDL-based) generation of the DRMAA spec will avoid such string length limitations in the language-independent part, and moves according restrictions to the language binding documents. Even if we fix this for the 1.0 spec, it is not sure if (or when) all implementations adopt this change. It might also break existing implementations. To group: Is this worthwhile for a tracker item ?
Please let me know what was your intentions, and for the future, it would be great if you could clarify this issue in the documents. I think you should use "buffer size" term, because "buffer length" is not that clear (sizeof vs strlen).
String length vs. buffer size would be optimal.
I'm more convinced that the constants define the total buffer size, but some DRMAA example source codes got me confused, e.g. they define variables char foo[DRMAA_JOBNAME_BUFFER] but use DRMAA_JOBNAME_BUFFER - 1 as call arguments.
I think it was intended to do it the first way. I propose that the DRMAA spec should say: "The length of any output context-specific error string SHALL NOT exceed DRMAA_ERROR_STRING_BUFFER - 1." Peter.
participants (2)
-
Peter Troeger -
Piotr Domagalski