copy an array in c

I have a function, it accepts a char**, what is the quickest and most efficient way of making a local copy of the array in the function scope?

That is, i have , for example:

void funk(char **x){

char **b;

/*How do i make a separate copy of x to b?*/
}

Take pity on me internets, I'm a noob :) Thanks.

>>29
No, cock sucker, you're wrong. Null-terminated strings are braindamaged.

- Non-binary safe.
- O(n) length.
- Twice as expensive concatenation.
- Hinders possible word transfer optimizations for O(n) operations.
- More easily exploitable (e.g. Windows registry entries with null characters in their names, possible in Win32 but hidden from regedit.exe from being written in C).

>>31
Ok, cock sucker, that was me you were referring to. I love you smug bastards who think you know better than tried, tested and true technologies.

First of all you seem to be comparing a language that was designed as a "high level assembly" of sorts with a modern language with bounds checking and other such niceties. Stop.

Secondly, as >>32 said:
>only an idiot would store anything other than ascii or utf-8 text in a string.

Also if we're talking in terms of the O(n) length of a string a null-delimited string is much more memory efficient than the second-best alternative, that being storing an integer specifying how many characters long a string is (what is that, one byte vs. four bytes on most platforms?). The other advantage of a null-delimited string over having an integer specifying how long the string is is that the latter has a maximum length while the former has no such limit.

If you disagree with my last statement I challenge you to design a string structure more memory efficient than c-style strings. Because, y'know, memory/time efficiency is kind of what C is all about and I'm sure somebody smarter than you or I would have figured out something better, if it existed, long ago.

>>32
Because that's when they become useful. Oh, and efficient strings need to be UTF-16 or UTF-32.

if you're working with strings so long you even notice those you're doing something wrong.
That's retarded.

i can write shitty code in python/ruby/haskell/whatever language you think is superior, too.
But when a language provides you with null-terminated strings, you have to go out of your way and do it yourself in order to NOT write shitty code.

>>33
First of all you seem to be comparing a language that was designed as a "high level assembly" of sorts with a modern language with bounds checking and other such niceties. Stop.
If you say C isn't capable of decent strings, then you're bashing C, not me.

The other advantage of a null-delimited string over having an integer specifying how long the string is is that the latter has a maximum length while the former has no such limit.
Be real. How often would you want to use null bytes in strings or to have O(1) length, faster concatenation, better optimizations, etc., versus having strings larger than fucking 4 GB?

Because, y'know, memory/time efficiency is kind of what C is all about
If you're so CFLAGS JUST KICKED IN, YO!-oriented, you'd want O(1) length and faster string operations. Plus -O3 -mword-strings -malign-double would provide you with awesome word-by-word string optimizations! OMG recompile your kernel!

>>32-33
Seriously, why's that? Why are you being such a fag? Are you a C fanboy? This is kind of lame. What advantages would null-terminated strings have? Length and storage space marked strings are much, much better any day for any purpose. The only advantages of null-terminated strings, to save space on tiny strings, and to get past 4 GB length is nothing compared to its huge disadvantages.