Re: Array assignment via struct
On Sat, 06 Aug 2005 08:45:05 -0400, Joe Wright wrote:[color=blue]
> Netocrat wrote:[color=green]
>> On Fri, 05 Aug 2005 21:52:07 -0700, Krishanu Debnath wrote:[color=darkred]
>>>Jack Klein wrote:
>>><snip>
>>>
>>>>>/* Assign array via struct */
>>>>>
>>>>>#include <stdio.h>
>>>>>#include <string.h>
>>>>>#include <stdlib.h>
>>>>>
>>>>>#define LEN 20
>>>>>
>>>>>typedef struct {
>>>>> char a[LEN];
>>>>>} S;
>>>>>
>>>>>int main(void) {
>>>>> S sa;
>>>>> char A[LEN];
>>>>>
>>>>> S *ps = malloc(LEN);[/color]
>>
>>
>> It's possible, but unlikely, that sizeof(S) > LEN due to padding. Better
>> to use sizeof(S) than LEN.
>>[/color]
> What padding could there be? S is essentially a char array.[/color]
Yeah, that's why I called it a pedantic point later in the post. Probably
the DS9000 is the only implementation to include padding. Anyhow you lose
nothing by using sizeof(S) instead of LEN and you are assured of
compliance.
[color=blue][color=green][color=darkred]
>>>>> char *pa = malloc(LEN);
>>>>>
>>>>> strcpy(sa.a, "Joe Wright Rocks");
>>>>> puts(sa.a...);
>>>>>
>>>>> *(S*)A = sa;[/color]
>>
>>
>> Here you are potentially copying and assigning more than the allocated
>> (to src and dest) LEN bytes. A compiler might do this for performance
>> reasons. It's probably unlikely and a little pedantic but the point is
>> that what you're doing isn't guaranteed safe by the standard.
>>[/color]
> You're assuming sizeof sa might be greater than LEN. Why?[/color]
As above - padding. I wrote that it might be added for performance
reasons. I don't know if such reasons legitimately exist on a real-world
implementation (I can contrive a far-fetched hypothetical implementation
where they do), but you never know what code an optimising compiler is
going to generate.
<snip rest>
On Sat, 06 Aug 2005 08:45:05 -0400, Joe Wright wrote:[color=blue]
> Netocrat wrote:[color=green]
>> On Fri, 05 Aug 2005 21:52:07 -0700, Krishanu Debnath wrote:[color=darkred]
>>>Jack Klein wrote:
>>><snip>
>>>
>>>>>/* Assign array via struct */
>>>>>
>>>>>#include <stdio.h>
>>>>>#include <string.h>
>>>>>#include <stdlib.h>
>>>>>
>>>>>#define LEN 20
>>>>>
>>>>>typedef struct {
>>>>> char a[LEN];
>>>>>} S;
>>>>>
>>>>>int main(void) {
>>>>> S sa;
>>>>> char A[LEN];
>>>>>
>>>>> S *ps = malloc(LEN);[/color]
>>
>>
>> It's possible, but unlikely, that sizeof(S) > LEN due to padding. Better
>> to use sizeof(S) than LEN.
>>[/color]
> What padding could there be? S is essentially a char array.[/color]
Yeah, that's why I called it a pedantic point later in the post. Probably
the DS9000 is the only implementation to include padding. Anyhow you lose
nothing by using sizeof(S) instead of LEN and you are assured of
compliance.
[color=blue][color=green][color=darkred]
>>>>> char *pa = malloc(LEN);
>>>>>
>>>>> strcpy(sa.a, "Joe Wright Rocks");
>>>>> puts(sa.a...);
>>>>>
>>>>> *(S*)A = sa;[/color]
>>
>>
>> Here you are potentially copying and assigning more than the allocated
>> (to src and dest) LEN bytes. A compiler might do this for performance
>> reasons. It's probably unlikely and a little pedantic but the point is
>> that what you're doing isn't guaranteed safe by the standard.
>>[/color]
> You're assuming sizeof sa might be greater than LEN. Why?[/color]
As above - padding. I wrote that it might be added for performance
reasons. I don't know if such reasons legitimately exist on a real-world
implementation (I can contrive a far-fetched hypothetical implementation
where they do), but you never know what code an optimising compiler is
going to generate.
<snip rest>
Comment