[mpich-devel] Issue with MPI_Error_string() for user-defined codes/clases

[Jeff Hammond]

https://lists.mpich.org/mailman/listinfo/devel

This should probably be added to the email footer, btw.

Best,

Jeff

On Wed, Apr 23, 2014 at 3:49 PM, Marco <marcodpc at gmail.com> wrote:
> how I unsubscribe to this mailing list ?
>
> Thanks
>
>
> 2014-04-23 22:11 GMT+02:00 Larry Baker <baker at usgs.gov>:
>
>> Lisandro,
>>
>> As a matter of personal taste, I prefer that empty strings be used as
>> initializers for C strings.  One of the things I dislike extremely about C
>> (and, one of the reasons I think it is so easy in C to write bad code) is
>> its mixing of integers and pointers and integers and chars.  Even though { 0
>> } is identical to { "" } when initializing C strings, I find the latter more
>> informative.  I know the C standard specifies that strings are terminated by
>> the null character, which is elsewhere specified to be a byte with all bits
>> equal to zero.  However, "" is the literal empty string, whereas 0 (or '\0')
>> is the underlying implementation of the empty string.  This is also why I
>> prefer to use the C99 NULL macro constant to initialize pointers with the
>> nil pointer as opposed to 0 (which gets implicitly cast to a nil pointer of
>> the correct size), the implementation of the nil pointer.  As I said,
>> though, this is all just a matter of taste -- there is no difference in the
>> correctness of the code.
>>
>> Larry Baker
>> US Geological Survey
>> 650-329-5608
>> baker at usgs.gov
>>
>>
>>
>> On 23 Apr 2014, at 3:20 AM, Lisandro Dalcin wrote:
>>
>> On 23 April 2014 00:55, Rob Latham <robl at mcs.anl.gov> wrote:
>>
>>
>>
>> On 04/22/2014 04:04 AM, Lisandro Dalcin wrote:
>>
>>
>> The following simple tests segfaults. A quick fix would be to return
>>
>> an empty string in MPIR_Err_get_dynerr_string() (file dynerrutil.c),
>>
>>
>>
>> I don't muck around in this code very often, so after thinking about it
>> for
>>
>> a bit, and coming up with another way to do it, I opened a ticket so i
>> could
>>
>> get a second (third, I guess) opinion:
>>
>>
>> https://trac.mpich.org/projects/mpich/ticket/2067
>>
>>
>>
>> IMHO your patch complicates things too much, I'm still in support of
>> this slightly refined version that removes the usage of empty string
>> constants (Rob, could you upload this patch to the ticket?):
>>
>> $ git diff
>> diff --git a/src/mpi/errhan/dynerrutil.c b/src/mpi/errhan/dynerrutil.c
>> index 943e8c3..2e3bb27 100644
>> --- a/src/mpi/errhan/dynerrutil.c
>> +++ b/src/mpi/errhan/dynerrutil.c
>> @@ -48,6 +48,7 @@ static const char
>> *(user_class_msgs[ERROR_MAX_NCLASS]) = { 0 };
>> static const char *(user_code_msgs[ERROR_MAX_NCODE]) = { 0 };
>> static int  first_free_class = 0;
>> static int  first_free_code  = 1;  /* code 0 is reserved */
>> +static const char empty_error_string[1] = { 0 };
>>
>> /* Forward reference */
>> const char *MPIR_Err_get_dynerr_string( int code );
>> @@ -297,11 +298,13 @@ const char *MPIR_Err_get_dynerr_string( int code )
>>     if (errcode) {
>>  if (errcode < first_free_code) {
>>     errstr = user_code_msgs[errcode];
>> +    if (!errstr) errstr = empty_error_string;
>>  }
>>     }
>>     else {
>>  if (errclass < first_free_class) {
>>     errstr = user_class_msgs[errclass];
>> +    if (!errstr) errstr = empty_error_string;
>>  }
>>     }
>>
>>
>>
>> --
>> Lisandro Dalcin
>> ---------------
>> CIMEC (UNL/CONICET)
>> Predio CONICET-Santa Fe
>> Colectora RN 168 Km 472, Paraje El Pozo
>> 3000 Santa Fe, Argentina
>> Tel: +54-342-4511594 (ext 1016)
>> Tel/Fax: +54-342-4511169
>> <error-string.diff>
>>
>>
>



-- 
Jeff Hammond
jeff.science at gmail.com