«

here is a program..
struct st
{
char ch[3];
int a;
}st_var={"ABC",68};

void main()
{

printf("%s",st_var.ch);

}

If there is continuous allocation then the output will be

ABCD

now...suppose tht the memory is not allocated continuously..
the first 3 bytes are allocated at 1 place and next 2 bytes are
allocated at other place
wht will be the output....???

jt wrote:

> here is a program..
> struct st
> {
> char ch[3];
> int a;
> }st_var={"ABC",68};

Undefined behaviour. You are writing past the bounds of an object, in
this case 'ch'.

> void main()

int main(void)

> {
>
> printf("%s",st_var.ch);

return 0;

>
> }
>
> If there is continuous allocation then the output will be
>
> ABCD

Only for the ASCII encoding.

> now...suppose tht the memory is not allocated continuously..
> the first 3 bytes are allocated at 1 place and next 2 bytes are
> allocated at other place
> wht will be the output....???

Why are you interested in pathological and broken code? If you want to
understand the machine at the byte level, maybe you should try assembly
language.

printf will print all character values starting at the address allocated
for st_var.ch and will do so until it encounters a null character. But
strictly according to the standard undefined behaviour is invoked by
your program so anything could be it's result.

Did you run it and see?

jt <> wrote:

> wht will be the output....???

You'd be better off not asking that question, and learning to write
programs that aren't broken instead. Any answer you do find will be
highly undependable, and likely to lead to crashes or worse further down
the line.

Richard

santosh wrote:
> jt wrote:
>
>> here is a program..
>> struct st
>> {
>> char ch[3];
>> int a;
>> }st_var={"ABC",68};
>
> Undefined behaviour. You are writing past the bounds of an object, in
> this case 'ch'.
>
>> void main()
>
> int main(void)
>
>> {
>>
>> printf("%s",st_var.ch);
>
> return 0;
>
>>
>> }
>>
>> If there is continuous allocation then the output will be
>>
>> ABCD
>
> Only for the ASCII encoding.
And only for little endian machines...

Bye, Jojo

jt wrote:
> here is a program..
> struct st
> {
> char ch[3];
> int a;
> }st_var={"ABC",68};
>
> void main()
^^^^ Bzzt! Error. main returns an int.
> {
>
> printf("%s",st_var.ch);
^^^^^^ Bzzt! Error. no prototype for the variadic function
printf in scope.
^^^^ Warning. Behavior is implementation-defined for
final output line missing '\n'
^^^^^^^^^^ Bzzt! Gross error. st_var.ch
is not a string.


>
> }
>
> If there is continuous allocation then the output will be
>
> ABCD

Who says so? How do you know a zero byte follows the "ABC\0104"?
This is endian-dependent at least.
And what makes you imagine the decimal 68 (\0104) is the encoding for
'D'. Not all the world is your implementation.

> now...suppose tht the memory is not allocated continuously..
> the first 3 bytes are allocated at 1 place and next 2 bytes are
> allocated at other place
> wht will be the output....???

Who cares? Your program is hopelessly broken, and your assumptions
about byte order and character encoding are rancid.

santosh wrote:
> jt wrote:
>
>> here is a program..
>> struct st
>> {
>> char ch[3];
>> int a;
>> }st_var={"ABC",68};
>
> Undefined behaviour. You are writing past the bounds of an object, in
> this case 'ch'.

Not true. The initializer "ABC" is perfectly fine for char ch[3]. It
just won't give you a string.

Joachim Schmitz wrote:
> santosh wrote:
>> jt wrote:
>>
>>> here is a program..
>>> struct st
>>> {
>>> char ch[3];
>>> int a;
>>> }st_var={"ABC",68};
>>
>> Undefined behaviour. You are writing past the bounds of an object, in
>> this case 'ch'.
>>
>>> void main()
>>
>> int main(void)
>>
>>> {
>>>
>>> printf("%s",st_var.ch);
>>
>> return 0;
>>
>>>
>>> }
>>>
>>> If there is continuous allocation then the output will be
>>>
>>> ABCD
>>
>> Only for the ASCII encoding.
> And only for little endian machines...
And sizeof(int) == 2

Bye, Jojo

santosh wrote:
>
> jt wrote:
>
> > here is a program..
> > struct st
> > {
> > char ch[3];
> > int a;
> > }st_var={"ABC",68};
>
> Undefined behaviour. You are writing past the bounds of an object, in
> this case 'ch'.

Are you sure? I thought this was perfectly valid:

char chr[3] = "ABC";

In this case, it's simply shorthand for:

char chr[3] = { 'A', 'B', 'C' };

[...]
> > printf("%s",st_var.ch);

This is where UB is invoked, as ch_var.ch is not a nul-terminated
string.

[...]
> > If there is continuous allocation then the output will be
> >
> > ABCD
>
> Only for the ASCII encoding.

And only on little-endian systems.

> > now...suppose tht the memory is not allocated continuously..
> > the first 3 bytes are allocated at 1 place and next 2 bytes are
> > allocated at other place
> > wht will be the output....???
>
> Why are you interested in pathological and broken code? If you want to
> understand the machine at the byte level, maybe you should try assembly
> language.
>
> printf will print all character values starting at the address allocated
> for st_var.ch and will do so until it encounters a null character. But
> strictly according to the standard undefined behaviour is invoked by
> your program so anything could be it's result.
>
> Did you run it and see?

I think a better, and non-UB-invoking form of the question he really
is asking would be:

Are padding bytes within a struct guaranteed to be initialized
to zero?

Of course, you're not actually allowed to use those bytes AFAIK,
so I'm not sure why one needs to be concerned about their value.

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <private.php?do=newpm&u=>

On Mon, 03 Mar 2008 14:48:00 -0000, Kenneth Brody <>
wrote:
>
> Are you sure? I thought this was perfectly valid:
>
> char chr[3] = "ABC";
>
> In this case, it's simply shorthand for:
>
> char chr[3] = { 'A', 'B', 'C' };
>
> [...]

According to K&R2 it is correct:

If the array has unknown size, the number of
characters in the string, including the
terminating null character, determines its
size; if its size is fixed, the number of
characters in the string, not counting the
terminating null character, must not exceed
the size of the array. -- Section A8.7

Presumably this is an accurate interpretation of the standard that was
later ratified and referred to informally as C89.

--
Martin

Martin said:

<snip>

> If the array has unknown size, the number of
> characters in the string, including the
> terminating null character, determines its
> size; if its size is fixed, the number of
> characters in the string, not counting the
> terminating null character, must not exceed
> the size of the array. -- Section A8.7
>
> Presumably this is an accurate interpretation of the standard that was
> later ratified and referred to informally as C89.

Yes, and this oddity survives in C99, in 6.7.8(14):

"An array of character type may be initialized by a character string
literal, optionally enclosed in braces. Successive characters of the
character string literal (including the terminating null character if
there is room or if the array is of unknown size) initialize the
elements of the array."

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999