Adding Harwell-Boeing support in PETSc?

[Victor Eijkhout]

At 9:40 AM -0500 4/7/05, Hong Zhang wrote:
>It seems the bug is on when to raise error flag?

Yes.

Here's my email exchange with Roldan Pozo:

At 4:03 PM -0400 5/7/03, pozo at nist.gov wrote:
>Actually, the ANSI standard says it returns the number of characters
>"transmitted" (Sec. 4.9.6.1), which may or may not be the same as the
>number of characters printed.   In any case, you are right: the code
>as it appears will return a pessimistic error code.  I guess I was
>thinking of fscanf, which returns the number of items succesfully
>assigned. (So much for symmetry in function interface design...)
>
>The offending line should be replaced with "if (ret_code < 0 )".
>Thanks for pointing this out, Victor.
>
>Regards,
>Roldan
>
>----------------------------------------------------------------
>Quoting Victor Eijkhout <eijkhout at cs.utk.edu>:
>
>>
>>  I don't see how this could ever work:
>>
>>  int mm_write_banner(FILE *f, MM_typecode matcode)
>>  {
>>       char *str = mm_typecode_to_str(matcode);
>>       int ret_code;
>>
>>       ret_code = fprintf(f, "%s %s\n", MatrixMarketBanner, str);
>>       free(str);
>>       if (ret_code !=2 )
>>           return MM_COULD_NOT_WRITE_FILE;
>>       else
>>           return 0;
>>  }
>>
>>
>>  According to my copy of the C standard (ok, the reviled
>>  Schildt-annotated edition) fprintf returns the number of characters
>  > written. How can that be 2?


and later


At 11:26 PM -0400 5/7/03, pozo at nist.gov wrote:
>  > >The offending line should be replaced with "if (ret_code < 0 )".
>>
>>  And the same goes for other write functions. I had to replace this in
>>  at least one other location.
>
>Right.  (I mean, "write.")
>
>I'll update the files on the web site.


I don't know if Roldan ever updated that.
-- 
Victor Eijkhout <eijkhout at cs.utk.edu>, 329 Claxton, Comp Sci, UT, 
Knoxville TN 37996.
tel: 865 974 9308 (W), 865 673 6998 (H), 865 974 8296 (F)
http://www.cs.utk.edu/~eijkhout/