Query abt union

[Shao Miller]

In comparing
union MyUnion ux = {"C Language"};
to separate declaration and initialization of ux, I see
efficiency as of far less importance than correctness, clarity,
and brevity, on which counts the combined statement excels.
Agreed.

Of course the combined statement *is* far more efficient, probably
saving over 10ns of runtime per program execution relative to
initialization by strcpy(), and probably over 50ns relative to
strncpy(), and saving easily a handful of bytes in program size.

I'm not sure that I understand why, for the case of 'strncpy'. Is it
because of the overhead of calling a function?

6.7.8p19 includes "... all subobjects that are not initialized
explicitly shall be initialized implicitly the same as objects that have
static storage duration."

Does that mean that the remaining elements of the 'ux' array are set to
null character values, just the same as 'strncpy' does?

I've seen a Microsoft compiler complain about:

void func(void) {
char foo[100] = {0};
return;
}

if the module providing 'memset' was not linked-with. It seems to me
that for this implementation, initializing with a string literal might
possibly employ 'strncpy' for the same reason as it employs 'memset' for
the initialization shown just above.

 

[Shao Miller]

char mystring[10];
void mystrcpy(const char *arg) {
strncpy(mystring, arg, sizeof(mystring) - 1);
mystring[sizeof(mystring) - 1] = '\0';
}

What is wrong with this?

Here's a note which is unrelated to "right" or "wrong"

The parentheses around 'mystring' are redundant.

char mystring[10];
void mystrcpy(const char * arg) {
strncpy(mystring, arg, sizeof mystring - 1);
mystring[sizeof mystring - 1] = '\0';
}

 

[Shao Miller]

char mystring[10];
void mystrcpy(const char *arg) {
strncpy(mystring, arg, sizeof(mystring) - 1);
mystring[sizeof(mystring) - 1] = '\0';
}

A quibble with this particular implementation: Your wrapper function uses
sizeof to get the size of the destination buffer, which a general-purpose
function wouldn't be able to do.

If it was a general-purpose function, it also wouldn't know where to
copy it to without another parameter. So maybe:

#define MAX_STRING_SIZE (10)

enum cv {
cv_max_string_size = MAX_STRING_SIZE,
cv_zero = 0
}

typedef char a_my_string_buf[cv_max_string_size];

void my_strcpy(a_my_string_buf * const dest, const char * const src) {
strncpy(*dest, src, sizeof *dest - 1);
(*dest)[sizeof *dest - 1] = 0;
return;
}

 

[James Waldby]

I'm not sure that I understand why, for the case of 'strncpy'. Is it
because of the overhead of calling a function?

The time savings I mentioned arise if ux has static storage duration
and its initial value is loaded along with the program (before
execution begins). There might not be many other eligible scenarios.

6.7.8p19 includes "... all subobjects that are not initialized
explicitly shall be initialized implicitly the same as objects that have
static storage duration."

Does that mean that the remaining elements of the 'ux' array are set to
null character values, just the same as 'strncpy' does?

I think 6.7.8p21 (in the N1256 draft) is slightly more applicable. It
says, in part: "If there are ... fewer characters in a string literal
used to initialize an array of known size than there are elements in the
array, the remainder of the aggregate shall be initialized implicitly
the same as objects that have static storage duration."

I've seen a Microsoft compiler complain about:

void func(void) {
char foo[100] = {0};
return;
}

if the module providing 'memset' was not linked-with. It seems to me
that for this implementation, initializing with a string literal might
possibly employ 'strncpy' for the same reason as it employs 'memset' for
the initialization shown just above.