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

Larry Baker baker at usgs.gov
Wed Apr 23 15:11:26 CDT 2014


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>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mpich.org/pipermail/devel/attachments/20140423/6d3e4638/attachment.html>


More information about the devel mailing list