Mailing List Archive

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:

http://www.opengroup.org/onlinepubs/009695399/functions/calloc.html

RETURN VALUE

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:
http://www.opengroup.org/onlinepubs/009695399/help/codes.html#CX

[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.

Thanks,
Marcus



_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

On Sat, Mar 11, 2006 at 06:54:54AM +0100, Nikos Mavrogiannopoulos wrote:
>
> 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.

gcrypt makes certain assumptions about the system on which in it is
running. One of these is ANSI C compliance (which guarantees that
calloc() will set errno). I wouldn't exactly call that "very
non-portable".

Cheers,

Phil

--
"In case de curse does not succeed, dis is my lucky stake. I have killed
many vampires wit it. I call it Mr. Pointy." "You named your stake?"
"Yes." "Remind me to get you a stuffed animal."
Kendra and Buffy: Becoming, Part 1

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

On Sat 11 Mar 2006 10:45, Marcus Brinkmann wrote:

> > 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:
> http://www.opengroup.org/onlinepubs/009695399/functions/calloc.html

Maybe but this doesn't change my argument. It is less portable than
the ISO/ANSI C behavior. Given that libgcrypt is already ported to
non-UNIX systems as well[0], I would consider this a bug.


[0]. Even older unix systems may not support that.

regards,
Nikos

--
Nikos Mavrogiannopoulos

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

At Sat, 11 Mar 2006 11:52:26 +0100,
Nikos Mavrogiannopoulos wrote:
>
> On Sat 11 Mar 2006 10:45, Marcus Brinkmann wrote:
>
> > > 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:
> > http://www.opengroup.org/onlinepubs/009695399/functions/calloc.html
>
> Maybe but this doesn't change my argument. It is less portable than
> the ISO/ANSI C behavior. Given that libgcrypt is already ported to
> non-UNIX systems as well[0], I would consider this a bug.

ISO/ANSI C alone is not a reasonable target platform to write
applications for. So, if you want to port libgcrypt to a specific
platform, please say which one and tell us what changes are required
to make it work on that specific platform. Only then we can consider
it.

Thanks,
Marcus


_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

On Sat, 11 Mar 2006 11:52:26 +0100, Nikos Mavrogiannopoulos said:

> On Sat 11 Mar 2006 10:45, Marcus Brinkmann wrote:
>> > 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:
>> http://www.opengroup.org/onlinepubs/009695399/functions/calloc.html

> Maybe but this doesn't change my argument. It is less portable than
> the ISO/ANSI C behavior. Given that libgcrypt is already ported to
> non-UNIX systems as well[0], I would consider this a bug.

To protect against ill behaving implementaions we even use some
failsafe code in the internal malloc code:

gcry_err_code_t
gcry_malloc (size_t n, unsigned int flags, void **mem)
{
[...]
/* Call standard malloc or user registered function. */
[...]
if (!m)
{
/* Make sure that ERRNO has been set in case a user supplied
memory handler didn't it correctly. */
if (!errno)
errno = ENOMEM;
err = gpg_err_code_from_errno (errno);
}
else
*mem = m;

return err;
}



Shalom-Salam,

Werner


_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

On 3/11/06, Werner Koch <wk@gnupg.org> wrote:

> > Maybe but this doesn't change my argument. It is less portable than
> > the ISO/ANSI C behavior. Given that libgcrypt is already ported to
> > non-UNIX systems as well[0], I would consider this a bug.
> To protect against ill behaving implementaions we even use some
> failsafe code in the internal malloc code:

Ok, thanks, then my concern of this behaviour not working is addressed. A
small bug in the code is that errno is not set to zero before
thus if a system does not set errno, and errno (most likely)
contains some previous value that value will be detected.

In any case I don't find any benefit into checking errno for memory
allocation. The value is not interesting at all, and it adds
complexity to the code.


Nikos

_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel

At Mon, 13 Mar 2006 13:54:48 +0100,
Nikos Mavrogiannopoulos wrote:
> In any case I don't find any benefit into checking errno for memory
> allocation. The value is not interesting at all, and it adds
> complexity to the code.

Normally, you don't check. You just return the value that's stored in
errno in case of allocation failure.

Your concern was that some systems may not set errno. This can only
be addressed by either coding behaviour specifically for these
systems, or by a generic check. The check is necessary so that if
errno is returned, it is not overwritten.

There is also the question to what errno should be set on bogus
systems. Can we rely on ENOMEM? By what justification? It is not
mandated by ISO C99 either.

I would really like to see a list of systems where malloc and friends
don't set errno.

As for complexity: You call for the complexity by asking to support
systems that don't support the respective standards.

Thanks,
Marcus


_______________________________________________
Gcrypt-devel mailing list
Gcrypt-devel@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gcrypt-devel