gpg_err_code_from_errno usage

Marcus Brinkmann marcus.brinkmann at
Sat Mar 11 10:45:58 CET 2006

At Sat, 11 Mar 2006 06:54:54 +0100,
Nikos Mavrogiannopoulos wrote:
>  I've noticed quite big parts of libgcrypt use the following
> constructions:
>     array = gcry_calloc (strlen (elems) + 1, sizeof (*array));
>     if (! array)
>       err = gpg_err_code_from_errno (errno);
> But how can you be sure that calloc() (or in that case gcry_calloc)
> will set the errno? calloc is a library call which may or may not use
> a system call. Even if it works on some systems, this is a very
> non-portable construction, which will result in no error checking in
> systems that do not set errno.

It's not in ISO C, but in POSIX.  Single Unix v3 has:


      Upon successful completion with both nelem and elsize non-zero,
      calloc() shall return a pointer to the allocated space. If either
      nelem or elsize is 0, then either a null pointer or a unique
      pointer value that can be successfully passed to free() shall be
      returned. Otherwise, it shall return a null pointer [CX] [Option
      Start] and set errno to indicate the error. [Option End]

The CX Option is:

  [CX][Option Start] Extension to the ISO C standard [Option End]
  The functionality described is an extension to the ISO C
  standard. Application writers may make use of an extension as it is
  supported on all IEEE Std 1003.1-2001-conforming systems.

  With each function or header from the ISO C standard, a statement to
  the effect that ``any conflict is unintentional'' is included. That is
  intended to refer to a direct conflict. IEEE Std 1003.1-2001 acts in
  part as a profile of the ISO C standard, and it may choose to further
  constrain behaviors allowed to vary by the ISO C standard. Such
  limitations are not considered conflicts.

  Where additional semantics apply to a function or header, the material
  is identified by use of the CX margin legend.


More information about the Gcrypt-devel mailing list