Skip to Content.
Sympa Menu

h5part - [H5part] Re: error handling in H5hut

h5part AT lists.psi.ch

Subject: H5Part development and discussion

List archive

[H5part] Re: error handling in H5hut


Chronological Thread 
  • From: Achim Gsell <achim AT cybercity.ch>
  • To: Mark Howison <MHowison AT lbl.gov>
  • Cc: h5part AT lists.psi.ch
  • Subject: [H5part] Re: error handling in H5hut
  • Date: Thu, 1 Jul 2010 22:37:37 +0200
  • List-archive: <https://lists.web.psi.ch/pipermail/h5part/>
  • List-id: H5Part development and discussion <h5part.lists.psi.ch>

Hi Mark,

On Jul 1, 2010, at 10:20 PM, Mark Howison wrote:

> I was wondering why there is so much casting in the TRY construct:
>
> #define TRY( func ) \
> if ((int64_t)(ptrdiff_t)(func) <= (int64_t)H5_ERR) \
> return H5_ERR;
>
> What if we had a convention where every function must return a signed
> int, either h5_ssize_t for any function that returns a number of
> something, or h5_err_t if the function is only returning an
> error/success code. Then we could compare directly to H5_ERR.

Actually I already thought about this several times. But we have functions
returning a pointer, like h5_open_file() or the memory (re-)allocation
functions. On error these functions return a pointer value H5_ERR. H5_ERR is
defined as -1, which isn't a valid pointer value on all systems I know.

Achim




Archive powered by MHonArc 2.6.19.

Top of Page