Doubt In Bytes Allocated

[ranjeet.gupta]

Dear All

I am not able o understand the exact number of bytes allocation done
by the two fucntion given below, It is said that the fuction
Condition_String1 allocates the 240 bytes while
Condition_String2 allocates the 72 bytes,

I am not able to get the Artimatic Numbers to staisfy the above
Number of bytes allocated,

What I think Is that The First fuction Condition_String1 allocates
(4 bytes (Case is the Int)) * (15 Cases) * 2 (bytes char)) = 120
but how it is 240 ??

For Fuction Condition_String2 = 45 bytes

Please let me know where I am wrong

FUNCTION 1:

char * Condition_String1(int condition) {
switch(condition) {
case 0: return "EQ";
case 1: return "NE";
case 2: return "CS";
case 3: return "CC";
case 4: return "MI";
case 5: return "PL";
case 6: return "VS";
case 7: return "VC";
case 8: return "HI";
case 9: return "LS";
case 10: return "GE";
case 11: return "LT";
case 12: return "GT";
case 13: return "LE";
case 14: return "";
default: return 0;
}
}

FUNCTION 2:

char * Condition_String2(int condition) {

if ((unsigned) condition >= 15) return 0;
return
"EQ\0NE\0CS\0CC\0MI\0PL\0VS\0VC\0HI\0LS\0GE\0LT\0GT\0LE\0\0"
+
3 * condition;
}

Thanks In advance
Ranjeet

 

[Walter Roberson]

I am not able o understand the exact number of bytes allocation done
by the two fucntion given below, It is said that the fuction
Condition_String1 allocates the 240 bytes while
Condition_String2 allocates the 72 bytes,

-What- says that? If you are talking about some compiler saying
that, then that's an implementation matter beyond the scope of
C. If you are saying that sizeof() the function is some particular
value, then you are using sizeof() in undefined ways.

What I think Is that The First fuction Condition_String1 allocates
(4 bytes (Case is the Int)) * (15 Cases) * 2 (bytes char)) = 120
but how it is 240 ??

Quoted strings have a NUL terminator, so "EQ" requires -three-
memory locations, not two. And the compiler is free to align
string constants any way it sees fit, including aligning them on
four-byte boundaries, or aligning them on even boundaries.
3 bytes plus padding to get to an even boundary is 4 bytes.

Don't make the mistake, though, of saying, "Ah hah! 4 bytes
instead of 2, that changes the calculation to get exactly the
expected 240 bytes!". Your formulae is wrong, because you
are multiplying integer cases by string storage, instead of
adding the two. But then there's the factor that the numeric
comparisons could be done in code instead of in an allocated
table, so there isn't necessarily any storage allocated for
the case values. And an optimizing compiler could easily
transform your code into something equivilent to

char *Cases[] = { "EQ", "NE", "CS", .... "LE", "" };
if ( condition < 0 || condition > 14 } return NULL;
return Cases[condition];

Notice that in this reformulation only needs two integer
values, 0 and 14, with the others being implicit in the
structure of the Cases array.

This should, I hope, illustrate that your fomrulae is
invalid. If your compiler is telling you that 240 bytes
were allocated, that probably includes the machine code.

 

[ranjeet.gupta]

-What- says that? If you are talking about some compiler saying
that, then that's an implementation matter beyond the scope of
C. If you are saying that sizeof() the function is some particular
value, then you are using sizeof() in undefined ways.



Quoted strings have a NUL terminator, so "EQ" requires -three-
memory locations, not two. And the compiler is free to align
string constants any way it sees fit, including aligning them on
four-byte boundaries, or aligning them on even boundaries.
3 bytes plus padding to get to an even boundary is 4 bytes.

Don't make the mistake, though, of saying, "Ah hah! 4 bytes
instead of 2, that changes the calculation to get exactly the
expected 240 bytes!". Your formulae is wrong, because you
are multiplying integer cases by string storage, instead of
adding the two.

Ok I accept what you said is correct, Means that my formula
and approach is wrong (Due to not so much awareness),

Anyway what i understood from above lines is that

case = interger = 4 bytes,
char = 2 bytes + 1 bytes (null terminator) + 1 bytes (allignment)
i.e total = 4 bytes,

so for one case it is 4 + 4 bytes = 8 bytes,
now there are 15 cases,

so the total number of bytes = 15 * 8 = 120 bytes,
So do you mean that the 120 bytes is allocated not 240 ?
overe here If i assume that we are not talking of the
implementation issue.

or still some thing is unclear to me. ?

But then there's the factor that the numeric
comparisons could be done in code instead of in an allocated
table, so there isn't necessarily any storage allocated for
the case values. And an optimizing compiler could easily
transform your code into something equivilent to

char *Cases[] = { "EQ", "NE", "CS", .... "LE", "" };
if ( condition < 0 || condition > 14 } return NULL;
return Cases[condition];

Notice that in this reformulation only needs two integer
values, 0 and 14, with the others being implicit in the
structure of the Cases array.

This should, I hope, illustrate that your fomrulae is
invalid. If your compiler is telling you that 240 bytes
were allocated, that probably includes the machine code.

Sorry I am getting about your above lines, May be my answer is
hidden in above lines, but not able to understand exactly what
you said,

 

[JimS]

"EQ\0NE\0CS\0CC\0MI\0PL\0VS\0VC\0HI\0LS\0GE\0LT\0GT\0LE\0\0"

Be careful here ^^^

Jim

 

[Lawrence Kirby]

On Sat, 18 Jun 2005 01:52:38 -0700, ranjeet.gupta wrote:

....

Ok I accept what you said is correct, Means that my formula
and approach is wrong (Due to not so much awareness),

Anyway what i understood from above lines is that

case = interger = 4 bytes,

That may be true in your case but it isn't in general. Many
implementations would put this in a register so it may not be allocated
any memory at all.

char = 2 bytes + 1 bytes (null terminator) + 1 bytes (allignment)
i.e total = 4 bytes,

The thing you know is that a string literal like "AB" will take up 3 bytes
in memory, 2 for the data in the string, one for the null character at the
end. sizeof "AB" evaluates to 3. Your compiler MAY align data such that
there is one byte padding between strings, or it may do something
completely different.

so for one case it is 4 + 4 bytes = 8 bytes,
now there are 15 cases,

There is only one condition variable, it is the same one for all cases. It
isn't even used in the cases.

so the total number of bytes = 15 * 8 = 120 bytes,
So do you mean that the 120 bytes is allocated not 240 ?

It is not possible to tell how many bytes will be allocated. We know that
there will be 14*3+1 bytes used to hold string data, although the compiler
could merge the nulkl character used for the last string with another.
Beyond that it is up to the compiler what memory it allocates, you have to
know the internal workings of the compiler to predict that.

Lawrence

 

[ranjeet.gupta]

Be careful here ^^^

Thanks to all who particpated in the thread to clear my doubts, Well
Jim you are warning me, what you are trying to make me clear and to
be cautions about the above.

 

[Walter Roberson]

Jim you are warning me, what you are trying to make me clear and to
be cautions about the above.

I -suspect- Jim is trying to warn you that the escape sequence
is not necessarily going to end at the \0 if there are characters
following that can validly form part of a number. I -suspect- he is
trying to warn you that \0C could be interpreted as a hex constant.
But if that -is- what he is trying to warn about, it would not be
correct, as hex constants must start with \x and if you have
\ followed by a digit, then there must be one to 3 -octal- digits.

But I may be missing something, and Jim might have been cautioning
about something else.

 

[Walter Roberson]

Sorry I am getting about your above lines, May be my answer is
hidden in above lines, but not able to understand exactly what
you said,

What evidence are you going on that 240 bytes were allocated, or
72 bytes? I -suspect- you were going on the output of some
compiler or other, and I -supect- that the size being listed is
a combination of code and data, not of data alone. The amount
of storage that a compiler generates for code is essentially not
predictable without knowing that particular compiler version
*extremely* well.

 

[Keith Thompson]

What evidence are you going on that 240 bytes were allocated, or
72 bytes? I -suspect- you were going on the output of some
compiler or other, and I -supect- that the size being listed is
a combination of code and data, not of data alone. The amount
of storage that a compiler generates for code is essentially not
predictable without knowing that particular compiler version
*extremely* well.

And there's rarely any reason to care.