How to lowercase an entire array of strings? - arrays

Question

In the function below I must return a list of all duplicate strings in an hash table, ignoring cases if the parameter's value is equal to 1.
upo_strings_list_t upo_find_idup(const char **strs, size_t n, int ignore_case)
{
upo_strings_list_t list = NULL;
if(ignore_case) //Must lowercase each string of strs
{
size_t i;
size_t j;
size_t size = sizeof(char);
size_t len = 0;
char *aux = malloc(sizeof(char*)); //For each string of strs to lowercase
char **aux_strs = malloc(n * sizeof(char*)); //For store lowercase strings
assert( aux != NULL );
assert( aux_strs != NULL );
for(i = 0; i < n; ++i)
{
len = strlen(strs[i]) + 1;
aux_strs[i] = malloc(len * size);
strcpy(aux, strs[i]);
for(j = 0; aux[j] != '\0'; ++j)
{
aux[j] = tolower(aux[j]);
}
strcpy(aux_strs[i], aux);
}
list = upo_find_dup((const char**)aux_strs, n);
}
else
{
list = upo_find_dup(strs, n);
}
return list;
}
So, ignore case means that each string of strs must become lowercase. I tried to do that by a dynamic array of strings. When all strings are lowercase, the function calls another function (upo_find_dup) that returns a list of duplicate strings (for don't rewrite the same code).
upo_strings_list_t upo_find_dup(const char **strs, size_t n)
{
size_t i;
int val = 1;
upo_strings_list_t list = NULL;
upo_ht_linprob_t ht = upo_ht_linprob_create(UPO_HT_LINPROB_DEFAULT_CAPACITY,
upo_ht_hash_str_kr2e, upo_str_cmp);
assert( ht != NULL );
for(i = 0; i < n; ++i)
{
if(upo_ht_linprob_contains(ht, &strs[i]))
{
upo_strings_list_node_t *ln = malloc(sizeof(upo_strings_list_node_t));
if(ln == NULL)
{
perror("Unable to allocate memory for a new node");
abort();
}
ln->str = (char*)strs[i];
ln->next = list;
list = ln;
}
else
{
upo_ht_linprob_put(ht, &strs[i], &val);
}
}
return list;
}
And it seems work, because if I print every string saved in the list, they are exactly what they must be:
void test_find_idup()
{
const char *ary[] = {"One", "two", "four", "two", "one"};
size_t n = sizeof(ary) / sizeof(ary[0]);
//const char *res[] = {"one","two"};
upo_strings_list_t list;
list = upo_find_idup(ary, n, 1);
assert( list != NULL );
//size_t i = 0;
while(list != NULL)
{
printf("%s\n", list->str);
//assert( list->str == res[i] );
list = list->next;
//++i;
}
/* PRINT: one two :OK*/
}
But, when I try to assert if the string saved in the node of the list is equal to the result string (res[0] = "one" and res[1] = "two"), the assertion fail and a core dumped error appears:
test_hashtable_linprob: test_hashtable_linprob.c:1332: test_find_idup: Assertion `list->str == res[i]' failed.
==13842==
==13842== Process terminating with default action of signal 6 (SIGABRT)
==13842== at 0x4DEC18B: raise (raise.c:51)
==13842== by 0x4DCB858: abort (abort.c:79)
==13842== by 0x4DCB728: __assert_fail_base.cold (assert.c:92)
==13842== by 0x4DDCF35: __assert_fail (assert.c:101)
==13842== by 0x10E7E8: test_find_idup (test_hashtable_linprob.c:1332)
==13842== by 0x10EAF7: main (test_hashtable_linprob.c:1403)
==13842==
==13842== HEAP SUMMARY:
==13842== in use at exit: 901 bytes in 11 blocks
==13842== total heap usage: 234 allocs, 223 frees, 169,605 bytes allocated
==13842==
==13842== 13 bytes in 3 blocks are definitely lost in loss record 2 of 7
==13842== at 0x4A37ECB: malloc (vg_replace_malloc.c:307)
==13842== by 0x11029D: upo_find_idup (hashtable.c:593)
==13842== by 0x10E771: test_find_idup (test_hashtable_linprob.c:1324)
==13842== by 0x10EAF7: main (test_hashtable_linprob.c:1403)
==13842==
==13842== 424 (40 direct, 384 indirect) bytes in 1 blocks are definitely lost in loss record 6 of 7
==13842== at 0x4A37ECB: malloc (vg_replace_malloc.c:307)
==13842== by 0x10F482: upo_ht_linprob_create (hashtable.c:313)
==13842== by 0x110093: upo_find_dup (hashtable.c:546)
==13842== by 0x10E66D: test_find_dup (test_hashtable_linprob.c:1310)
==13842== by 0x10EAC1: main (test_hashtable_linprob.c:1398)
==13842==
==13842== 424 (40 direct, 384 indirect) bytes in 1 blocks are definitely lost in loss record 7 of 7
==13842== at 0x4A37ECB: malloc (vg_replace_malloc.c:307)
==13842== by 0x10F482: upo_ht_linprob_create (hashtable.c:313)
==13842== by 0x110093: upo_find_dup (hashtable.c:546)
==13842== by 0x11035A: upo_find_idup (hashtable.c:602)
==13842== by 0x10E771: test_find_idup (test_hashtable_linprob.c:1324)
==13842== by 0x10EAF7: main (test_hashtable_linprob.c:1403)
==13842==
==13842== LEAK SUMMARY:
==13842== definitely lost: 93 bytes in 5 blocks
==13842== indirectly lost: 768 bytes in 2 blocks
==13842== possibly lost: 0 bytes in 0 blocks
==13842== still reachable: 40 bytes in 4 blocks
==13842== suppressed: 0 bytes in 0 blocks
==13842== Reachable blocks (those to which a pointer was found) are not shown.
==13842== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==13842==
==13842== For lists of detected and suppressed errors, rerun with: -s
==13842== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 0 from 0)
Aborted (core dumped)
This is also the data structure:
/** \brief The type for nodes of list of strings. */
struct upo_strings_list_node_s {
char *str;
struct upo_strings_list_node_s *next;
};
/** \brief Alias for the type for nodes of list of strings. */
typedef struct upo_strings_list_node_s upo_strings_list_node_t;
/** \brief The type for list of strings. */
typedef upo_strings_list_node_t *upo_strings_list_t;

Answer 1

when I try to assert if the string saved in the node of the list is
equal to the result string (res[0] = "one" and res1 = "two"), the
assertion fail and a core dumped error appears
The fact that a core dump was produced is relevant only if you are inclined to load the dump into a debugger to examine the state of the program's memory when it aborted. Few people do that, and it is not uncommon for systems to be configured so that core dumps are not produced at all. I'll pay no further attention to it in this answer.
Many of your uses of assert() are inappropriate. Assertions are for run-time tests of the correctness of your code. They are useful for testing and documenting assumptions that your code makes about how other parts of your code will use it, or about characteristics the code relies upon the compiler to produce. Assertions must never contain code that you require to run on every execution of the program, such as tests for successful memory allocation, because they may be omitted from the executable completely depending on compile options. If one of your assertions fails, it always means that your code is buggy (possibly the assertion itself).
Write your own abort_unless() function or macro if you want a similar functionality for behavior that depends on input, runtime environment, or other behavior that may vary from run to run of the program.
Next, it looks like you're actually talking about this assertion, which is commented out in the code actually posted:
//assert( list->str == res[i] );
The test in that assertion has important differences from the one in your text, but I will focus on the one in the code. Possibly that particular use of assert is an appropriate one, so if it fails, then how is the code buggy? It is buggy because the == operator is comparing two char pointers themselves, not the data to which they point, and there is no reason for certainty that the two would be equal. You appear to want to employ strcmp(), instead:
assert(strcmp(list->str, res[i]) == 0);
Additionally, this code in upo_find_idup() ...
char *aux = malloc(sizeof(char*)); //For each string of strs to lowercase
... allocates enough space for a pointer itself, probably not more than 8 bytes. If you just wanted to store a pointer then there would be no need for the dynamic allocation or extra layer of indirection, but you're actually storing string contents. This will overrun the bounds of the allocated space if any of your strings are longer than a pointer.
Worse, your use of aux introduces unneeded extra work and code. It would be possible to allocate a long enough string for each case, but you're already doing that in the form of each aux_strs[i]. Just manipulate those directly.
Furthermore, the memory allocated for aux_strs itself is leaked, and so is the memory allocated for any of its members that are not carried through to the generated linked list. But this is also a bit of a logistical problem for you, because you must take care to avoid freeing the members that are carried through to the linked list. Furthermore, upo_find_dup() does not have enough information to do the freeing, because sometimes you call it with strings that it must not free in any case. A refactoring is probably needed here to enable you to manage memory correctly.

Answer 2

Try adding 32 to the ASCII value of each character, loops are the friends here.
Or you can use the built-in "toLower()" function.