Posts by UncleLeroy

The problem is not the malloc() statement, but in some other code which is corrupting the heap (= the space owned by malloc()). I would run the code in the debugger, but I can't because it isn't complete; do that if you can.
If that isn't feasible, you can strip out some possible causes of error, and use debug rechniques.
Instead of free'ing your malloc space, just clear the pointer. It will leak, who cares during debugging.
Look carefully at the code which is not shown here, which is modifying the trie,
and even more carefully for any other code which is using malloc/free.
Another approach is to write a function to test the trie contents for corruption, and call it at various points in the "other code".
Some compilers offer library options to check the heap on every malloc/free, enable that option if you have it. Also look for a library function that checks the heap, call that often if your compiler has one.
You can temporarily hard-code the array sizes of *hv and **children as hv[SIZE1] and *children[SIZE1] to eliminate their malloc's and free's as possible causes.
Is it right that both are the same SIZE1?
Is the "other code" (not posted) using the same #define?
How about setting all your SIZE* definitions to the same value (for debugging only)?
And change all of them to one (1) (for debug only).

Sorry I can't help more, …

sizeof() is not an issue if you use ->next as recommended above, however, here are some details:
1) sizeof() is returning the number of bytes you used (4 + 15 + 4 + 4) = 27,
but the compiler rounds up to a multiple of 3, 8, 16, or 32, depending on options.
You can expect the compiler (and malloc()) to reserve an arbitrary number of bytes (zero or more) than you requested.

2) You cannot assume that multiple calls to malloc() return equally-spaced pointers. You must treat each allocated block as if it was randomly located relative to the other blocks.

Try something like this:

x = low_number + (high_number - low_number) * (rand() / RAND_MAX) / 2.0;

If you need more help, follow the policy of this forum, by writing some code yourself, and do not continue to ask for help without showing any effort on your part.

memcpy seems to be doing exactly what it was asked to do, ie. copy exactly 3 characters, 'b' 'i' 't', on top of a buffer which already contains 5 characters, 'b' 'b' 'i' 't' '\0' (note the null terminator).
Only the first 3 characters are changed.
To include the terminator, copy 4 characters (suf_arr[j].len)
instead of 3 (suf_arr[j].len-1).

Posting the same question in multiple forums is a violation of web-site policy.
Please go back and read the rules.

Answer 1: The rules section needs "x = 0;" after the "you lose" line.
Answer 2: The "play" section should add "to return to main menu type %d", ... menu
Other comments:
The "for" statements are wrong, the logic inside looks like they should be if's.
All occurrences of x == -99, 0, 1, 2 should be replaced by the constants, e.g.
if (x != quit)
In the statements like (x != quit && x == menu), the (x != quit) is redundant, it is implied by (x == menu)
Single-letter variable names are a bad idea, use longer, self-explanatory names, such as "menu_selection" instead of "x".
The main menu does not need option 0: main menu, which goes back to itself.
The main menu is duplicated; delete the first copy and the code works the same.

One of the rules on this site is: Do not post homework problems expecting a quick answer without showing any effort yourself.

What do you have so far?

I just answered this question in another thread, the answer was, essentially, "go to a bookstore, and buy a good book". Look at the books in person (as opposed to online) and pick one that explains the topics in a way that you can understand.

Maybe that could be added to the web site guidelines?

scanf is a function, not a variable,
there should not be an = equal sign scanf=(something),
if should be scanf(something);

I think the equation I += I % 14 is wrong. For example if I == 15, the statement will add 1, which does not make it a multiple of 14.

Oops, it works when the array is part of a structure or union.

struct { 
  int elem[10][100]; 
} array1, array2;

main()
{
  array1.elem[0][0] = 1;
  array1.elem[9][99] = 9;
  array2 = array1;
  printf("%d %d\n", array2.elem[0][0], array2.elem[9][99]);
}

The assignment says to allocate in the function, and free() it in main.

void get_days_in_month(int **days, int year) {
 	int *array = malloc(sizeof(int) * 5) ;
	/* Set the output variable */
	*days = array ; 
	/* do not increment either pointer (days or array) */
	array[0] = 31 ;
	array[1] = 28 ;
	array[2] = 31 ;
	array[3] = 30 ;
	array[4] = 31 ; 
	/* Do not free() here, the caller will do it */
	/* No need to return the pointer more than once */
	return;	
}

Note days_In_Month[2] is alternate (more readable) syntax
which means the same as *(days_In_Month + 2)

int main(int argc, char **argv)
{
	int *days_In_Month;
	...
	get_days_in_month(&days_In_Month, year) ;

	for (month = 0; month <= 5; month++) {
	 	printf("days in month %d = %d\n",
			month, days_In_Month[month]);
	}

	free(days_In_Month); /* Free() after using */

   return EXIT_SUCCESS;
}

The "bzero" in the loop is redundant and can be deleted.
It is also overflowing the allocated buffer size of "ffull".