malloc, once again

I have a struct like
typedef struct { char* dildo; int etc } anus;.
Later on I want to make an anus array, with dildo being a string entered by the user.
Now how do I reserve the memory for dildo in my anus array?

So far I have:

typedef struct { char* dildo; int etc } anus;
...
char* small_dildo = fancy_input_routine();
anus* anii = (anus*) malloc(array_size * sizeof(anus));
With that I can't memcpy any small_dildo into my anii obviously, however I'm not quite sure how to do it.

Nevermind, I forgot that I could just anii[i].dildo = malloc(dildo_len * sizeof(small_dildo)); and then memcpy.
_{Writing a post really helps getting your shit together.}

are you sure the plural of "anus" is "anii"?

Annus per annus

>>2
Did you mean: malloc(strlen(small_dildo) + 1)?

It helps not being four years old.

>>5
char's are not necessarily one byte.

typedef struct
{
  int etc;
  char under_18_acceptable_name[0];
} GNU_ENTERPRISE;


char *str = "hi there";
GNU_ENTERPRISE *p = malloc(sizeof(*p) + strlen(str) + 1);
if(!p)
  die("you suck");

strcpy(p->under_18_acceptable_name, str);
p->etc = 3;

etc

>>7
let's not get into this again

>>5
If you're interested, I don't actually use chars to store a text string but to store bytes (including 0x00), so using string operations on that would be kind of stupid.
>>8
I've thought about that, but it's ugly.

>>7
U MENA bytes are not necessarily 8 bit.

>>7
Yes. And strlen returns the length of the string in chars. And the NUL character fits in a char. And sizeof (char) equals 1 by definition. And malloc(strlen(s) + 1) does exactly what you expect, always. And IHBT.

>>10
char is for storing text. If you want to store pure bytes, you should use unsigned char. That's what it's for.

1. Bytes are not necessarily 8 bit.
2. Characters are not necessarily bytes.
3. C/C++ char is a bullshit data type which more closely related to bytes than to characters.

>>14
For example, if I were to design a computer from scratch, I'd go with 18 bit bytes, mapping one character to one byte, and creating UTF-18 for it (fixed size, just a remap of UTF-32).

>>14
Well, then don't regard character as a glyph, but as the building block of a word, in the sense of processor word, double word, quadruple word and paragraph.

>>14
char is by definition one byte.

>>17
I think you meant to say octet.

>>17
I think you meant to say octet.

>>17
I think he meant "character" as in a written language symbol.

Unfortunately char has become somewhat of an odd type. unsigned char is the proper type to use for raw bytes, and C1X has Unicode character constants and string literals. It seems char is left only as a convenience when one needs only the characters listed in C99 5.2.1p3. In retrospect it was probably a mistake to bind it to being one byte.

>>15
Pig disgusting non-power-of-two.

>>18,19
No, there is no guarantee that a char is eight bits.  The size of one char in bits is implementation-defined; see CODE_BIT in limits.h.

3.6 1    byte
addressable unit of data storage large enough to hold any member of the basic character set of the execution environment
NOTE 1    It is possible to express the address of each individual byte of an object uniquely.
NOTE 2    A byte is composed of a contiguous sequence of bits, the number of which is implementation- defined. The least significant bit is called the low-order bit; the most significant bit is called the high-order bit .

3.7.1     character
single-byte character 〈C〉 bit representation that fits in a byte

from 5.2.4.2.1 Sizes of integer types <limits.h>
— number of bits for smallest object that is not a bit-field (byte)
CHAR_BIT 8

>>13
I actually typedefed it, so my byte structure is an unsigned char. It was just for illustrating my question, I didn't think it would stir up that much.
The program works now anyway.

>>11-23,25-
>>9 here, YHABT

/prog/ will be spammed continuously until further notice. we apologize for any inconvenience this may cause.