bug-libunistring
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug-libunistring] Avoiding heap allocations in ‘u32_conv_from_encoding’


From: Ludovic Courtès
Subject: [bug-libunistring] Avoiding heap allocations in ‘u32_conv_from_encoding’
Date: Tue, 13 Jul 2010 11:48:44 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux)

Hello!

In the example below, conversion from UTF-8 to UCS-4 succeeds but
‘u32_conv_from_encoding’ allocates memory on the heap although the
supplied buffer appears to be large enough:

#include <stdlib.h>
#include <stdint.h>
#include <stdio.h>
#include <assert.h>

#include <uniconv.h>
#include <unistring/iconveh.h>

static const char utf8_lambda[] = { 0xce, 0xbb };

int
main (int argc, char *argv[])
{
  uint32_t result_buf[100], *result;
  size_t result_len;

  result_len = sizeof (result_buf) / sizeof (uint32_t);
  result = u32_conv_from_encoding ("UTF-8", iconveh_question_mark,
                                   utf8_lambda, sizeof (utf8_lambda),
                                   NULL, result_buf, &result_len);
  assert (result != NULL);

  printf ("result = %p, result_buf = %p\n", result, result_buf);
  assert (result == result_buf);  /* <- fails here */

  return EXIT_SUCCESS;
}
Am I missing something or is there a good reason for this?

I’m asking because Guile uses ‘u32_conv_from_encoding’ in its routine to
get or peek at one character from its I/O port and heap allocating in
this case is overkill.

BTW, it’s unclear to me from the manual whether RESULT_LEN above should
be the size in bytes or the size in uint32_t.

Thanks,
Ludo’.

Attachment: pgpSaeAnZmlDO.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]