From 7f1b48e368443ae724e71cdc6fdd7c11d4ac1a08 Mon Sep 17 00:00:00 2001
From: Fredrik Thulin <fredrik@thulin.net>
Date: Tue, 8 Jan 2013 13:31:03 +0100
Subject: [PATCH] proto_read_attribute_array: When count is zero, make result a
NULL ptr.
I am a bit uncertain about this change, since both NULL and non-NULL
will make test cases fail within the SoftHSM test suite for example
(some SoftHSM C_ functions want the pointer to be NULL when there
are no attributes, and some allow (expect) it to be possible to pass a
non-NULL pointer with a zero count).
It seems that making it a NULL pointer when the count is 0 is the most
sensible thing though. How could the C_ function use the data pointed
to by the pointer, when the count says there is no data there? The
result would really be undefined.
---
gck-rpc-dispatch.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/gck-rpc-dispatch.c b/gck-rpc-dispatch.c
index a0152f3..5b7c461 100644
--- a/gck-rpc-dispatch.c
+++ b/gck-rpc-dispatch.c
@@ -460,6 +460,16 @@ proto_read_attribute_array(CallState * cs, CK_ATTRIBUTE_PTR * result,
(&msg->buffer, msg->parsed, &msg->parsed, &n_attrs))
return PARSE_ERROR;
+ if (! n_attrs) {
+ /* If there are no attributes, it makes most sense to make result
+ * a NULL pointer. What use could one have of a potentially dangling
+ * pointer anyways?
+ */
+ *result = NULL_PTR;
+ *n_result = n_attrs;
+ return CKR_OK;
+ }
+
/* Allocate memory for the attribute structures */
attrs = call_alloc(cs, n_attrs * sizeof(CK_ATTRIBUTE));
if (!attrs)
--
GitLab