473,887 Members | 2,309 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Memory allocation for an initialized character pointer;

Hi all,

If I have a piece of code something like this

void main(void)
{
char * p1="abcdefghijk lmn";
............... ............... ...............

}

For p1 and whatever it points to , where is the memory allocated. Is
it on heap or stack or
some other common global area. I am assuming it should be either on
stack or some global area. Unless
a user does a malloc storage space cannot be allocated on heap is my
assumption. Can someone
throw some light on how compilers do this.

What if the above piece of code is changed to something like

void main(void)
{
char *p1;
char a[20]="abcdefgh";

strcpy(p1,a);
}

Now where is the space allocated for p1 and whatever it points to
after strcpy.

Thanks in advance.

Regards,
Ar
Sep 30 '08
50 3542
On Oct 1, 1:05*am, Richard Heathfield <rj*@see.sig.in validwrote:
s0****@gmail.co m said:

<snip>
The quote I made from the standard mentions
three prototype forms for main: "int main(void)", "int main(int, char
**)" and "some other implementation-defined manner". Now, "void
main(void)" would fall under the third category; am I wrong? What do
you mean by saying that a strictly conforming program can't use "void
main(void)"?

Firstly, the Standard does not require any implementation to provide
support for *any* entry point other than int main(void), int main(int,
char **), and exact equivalents. (The rules for freestanding
implementations are even looser, but let's not go there just now.) There
is certainly no requirement to provide support for void main(void).

Therefore, even if a particular implementation defines a meaning for void
main(void), the behaviour of such a program on some *other* (arbitrary)
implementation is undefined.
So far, the bottom line remains the same: it *is* correct; it simply
isn't guaranteed to work on every compiler.
Secondly, a strictly conforming program is one that "shall use only those
features of the language and library specified in this International
Standard.2) It shall not produce output dependent on any unspecified,
undefined, or implementation-defined behavior, and shall not exceed any
minimum implementation limit."

Since void main(void) is not specified by the Standard, and also since it
can't be demonstrated that the very use of void main(void) does not
produce output dependent on any unspecified, undefined, or
implementation-defined behaviour, it cannot be used in a strictly
conforming program.
Now that's a shocker. Does that mean that, say, bit-fields in
structures can't be used in a strictly conforming program? (Whether
bit-fields are stored from right to left or from left to right is
implementation-defined.) In fact, does that mean that variables of
type int, long, or any type other than char, can't be used in a
strictly conforming program because their sizes are also
implementation-defined?
Of course, "in an implementation-defined manner" means it will be
different across implementations . Personally I prefer to define it to
return int, and to omit the return statement. But I think it isn't
very accurate to say that "void main(void)" is "incorrect" , only
because it will be rejected by some implementations .
I certainly wouldn't call it "correct".
If the standard says it is, why not?

The Standard doesn't say it's correct. It says that implementations are
allowed to define a meaning for it. But implementations are allowed to
define a meaning for anything they like - they can even give meaning to
Ook! programs if they want. But that doesn't make Ook! programs "correct"
in C terms.
But they'd be providing Ook! support as an extension (which would be
quite an useful extension, btw!). Accepting void main(void) isn't an
extension.

Sebastian

Oct 1 '08 #11
On Oct 1, 12:04 am, aruna...@gmail. com wrote:
Hi all,

If I have a piece of code something like this

void main(void)
{
char * p1="abcdefghijk lmn";
............... ............... ...............

}

For p1 and whatever it points to , where is the memory allocated. Is
it on heap or stack or
some other common global area. I am assuming it should be either on
stack or some global area. Unless
a user does a malloc storage space cannot be allocated on heap is my
assumption. Can someone
throw some light on how compilers do this.

What if the above piece of code is changed to something like

void main(void)
{
char *p1;
char a[20]="abcdefgh";

strcpy(p1,a);

}

Now where is the space allocated for p1 and whatever it points to
after strcpy.

Thanks in advance.

Regards,
Ar
in your first example
char *p1 will be allocated on stack not on heap but "abcdefghijklmn "
will be stored as global
now comming to your second example i am sorry to say your code is
wrong ....see

as you declare a pointer without initializing it so where is points
is dependent on your linker and OS it will generally point to 0 ( that
is a null pointer) ....
so you cannot copy bytes to it strcpy(p1, a) ; that is wrong

right way to do it is

char *p1 = NULL;
p1 = a;
then no need for strcpy();

even in this example the pointer will still be allocated on the stack
not on heap;
Oct 1 '08 #12
On 1 okt, 09:27, s0s...@gmail.co m wrote:
On Oct 1, 1:05*am, Richard Heathfield <r...@see.sig.i nvalidwrote:
s0s...@gmail.co m said:
<snip>
The quote I made from the standard mentions
three prototype forms for main: "int main(void)", "int main(int, char
**)" and "some other implementation-defined manner". Now, "void
main(void)" would fall under the third category; am I wrong? What do
you mean by saying that a strictly conforming program can't use "void
main(void)"?
Firstly, the Standard does not require any implementation to provide
support for *any* entry point other than int main(void), int main(int,
char **), and exact equivalents. (The rules for freestanding
implementations are even looser, but let's not go there just now.) There
is certainly no requirement to provide support for void main(void).
Therefore, even if a particular implementation defines a meaning for void
main(void), the behaviour of such a program on some *other* (arbitrary)
implementation is undefined.

So far, the bottom line remains the same: it *is* correct; it simply
isn't guaranteed to work on every compiler.
No. The phrase "some other implementation-defined manner" means that
void main() is only correct if the implementation documents it as
being so.
If the implementation does not document void main() as a possible
entry point, then using void main() with that implementation results
in UB, which means that this use of void main() can not be correct.

So, you can"t say without qualification that void main() is correct.
You can at most say that it is correct for certain implementations .
>
Secondly, a strictly conforming program is one that "shall use only those
features of the language and library specified in this International
Standard.2) It shall not produce output dependent on any unspecified,
undefined, or implementation-defined behavior, and shall not exceed any
minimum implementation limit."
Since void main(void) is not specified by the Standard, and also since it
can't be demonstrated that the very use of void main(void) does not
produce output dependent on any unspecified, undefined, or
implementation-defined behaviour, it cannot be used in a strictly
conforming program.

Now that's a shocker. Does that mean that, say, bit-fields in
structures can't be used in a strictly conforming program? (Whether
bit-fields are stored from right to left or from left to right is
implementation-defined.) In fact, does that mean that variables of
type int, long, or any type other than char, can't be used in a
strictly conforming program because their sizes are also
implementation-defined?
No, because you can write programs that don't depend on the
implementation defined aspects of bitfields or the integer types.

For example, this is a strictly conforming program:
<cut>
#include <stdio.h>
struct bits {
int value:4;
};
int main(void)
{
struct bits result;
int lhs, rhs;

lhs = 4;
rhs = 3;
result.value = lhs + rhs;
printf("%d\n", result.value);
return 0;
}
<cut>

The program is strictly conforming, because the output does not depend
on the choices that an implementation may have made for the
unspecified or implementation-defined behaviours or values.
>
Sebastian
Bart v Ingen Schenau
Oct 1 '08 #13
Bart van Ingen Schenau said:
On 1 okt, 09:27, s0s...@gmail.co m wrote:
>On Oct 1, 1:05 am, Richard Heathfield <r...@see.sig.i nvalidwrote:
s0s...@gmail.co m said:
<snip>
The quote I made from the standard mentions
three prototype forms for main: "int main(void)", "int main(int,
char **)" and "some other implementation-defined manner". Now, "void
main(void)" would fall under the third category; am I wrong? What do
you mean by saying that a strictly conforming program can't use
"void main(void)"?
Firstly, the Standard does not require any implementation to provide
support for *any* entry point other than int main(void), int main(int,
char **), and exact equivalents. (The rules for freestanding
implementations are even looser, but let's not go there just now.)
There is certainly no requirement to provide support for void
main(void).
Therefore, even if a particular implementation defines a meaning for
void main(void), the behaviour of such a program on some *other*
(arbitrary) implementation is undefined.

So far, the bottom line remains the same: it *is* correct; it simply
isn't guaranteed to work on every compiler.

No. The phrase "some other implementation-defined manner" means that
void main() is only correct if the implementation documents it as
being so.
If the implementation does not document void main() as a possible
entry point, then using void main() with that implementation results
in UB, which means that this use of void main() can not be correct.

So, you can"t say without qualification that void main() is correct.
You can at most say that it is correct for certain implementations .
>>
Secondly, a strictly conforming program is one that "shall use only
those features of the language and library specified in this
International Standard.2) It shall not produce output dependent on any
unspecified, undefined, or implementation-defined behavior, and shall
not exceed any minimum implementation limit."
Since void main(void) is not specified by the Standard, and also since
it can't be demonstrated that the very use of void main(void) does not
produce output dependent on any unspecified, undefined, or
implementation-defined behaviour, it cannot be used in a strictly
conforming program.

Now that's a shocker. Does that mean that, say, bit-fields in
structures can't be used in a strictly conforming program? (Whether
bit-fields are stored from right to left or from left to right is
implementati on-defined.) In fact, does that mean that variables of
type int, long, or any type other than char, can't be used in a
strictly conforming program because their sizes are also
implementati on-defined?

No, because you can write programs that don't depend on the
implementation defined aspects of bitfields or the integer types.

For example, this is a strictly conforming program:
<cut>
#include <stdio.h>
struct bits {
int value:4;
};
int main(void)
{
struct bits result;
int lhs, rhs;

lhs = 4;
rhs = 3;
result.value = lhs + rhs;
printf("%d\n", result.value);
return 0;
}
<cut>

The program is strictly conforming,
If you change the struct def to:

struct bits {
signed int value:4;
};

you don't have to worry about whether passing an unsigned int to printf as
a match for %d is an issue or not (and since I can never remember myself
whether it is, I find it easier to make things explicitly correct).

--
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
Oct 1 '08 #14
On 1 Oct, 09:44, raashid bhatt <raashidbh...@g mail.comwrote:
On Oct 1, 12:04 am, aruna...@gmail. com wrote:
If I have a piece of code something like this
void main(void)
{
* *char * p1="abcdefghijk lmn";
* * ............... ............... ...............
}
For p1 and *whatever it points to , where is the memory allocated. Is
it on heap or stack or
some other common global area. I am assuming it should be either on
stack or some global area. Unless
a user does a malloc storage space cannot be allocated on heap is my
assumption.
since The Standard doesn't mention heaps there is no restriction on an
implementaion using the heap (or stack) for whatever it pleases. The
static variables area could be stack or heap. (on old Macs the heap
was on the stack).

Can someone
throw some light on how compilers do this.
they have to allocate a block of memory before program startup.
How they do this is the implementors business. It is common
to just grab a lump of memory for statis data.

What if the above piece of code is changed to something like
void main(void)
{
* * char *p1;
* * char a[20]="abcdefgh";
* * strcpy(p1,a);
}
Now where is the space allocated for p1 and whatever it points to
after strcpy.

in your first example
char *p1 will be allocated on stack not on heap but "abcdefghijklmn "
will be stored as global
now comming to your second example i am sorry to say your code is
wrong ....see

as you declare a pointer without initializing *it so where is points
is dependent on your linker and OS it will generally point to 0 ( that
is a null pointer) ....
if by "generally" you mean "usually" I don't think this is so.
In my experience it contains whatever "random" crap has been
left on the stack. Many OSs *don't* clear the memory
before dishing it out to processes.
so you cannot copy bytes to it strcpy(p1, a) ; that is wrong

right way to do *it is

char *p1 = NULL;
initialising it to NULL is not necessary
p1 = a;
then no need for strcpy();
yes, but that may not be what the user wanted. he might
want to modify what p points to.

even in this example the pointer will still be allocated on the stack
not on heap

--
Nick Keighley
Oct 1 '08 #15
s0****@gmail.co m said:
On Oct 1, 8:20 pm, Richard Heathfield <rj*@see.sig.in validwrote:
>s0****@gmail.co m said:On Oct 1, 5:14 am, Richard Heathfield
<rj*@see.sig.i nvalidwrote:
>s0****@gmail.co m said:
On Oct 1, 1:05 am, Richard Heathfield <rj*@see.sig.in validwrote:

<snip>
>Therefore, even if a particular implementation defines a meaning
for void main(void), the behaviour of such a program on some
*other* (arbitrary) implementation is undefined.
So far, the bottom line remains the same: it *is* correct; it
simply isn't guaranteed to work on every compiler.
>It seems that we have a terminology disagreement again. I don't see
it as being "correct". I know it fails on at least two
implementation s that I use regularly.
But, speaking strictly in regard to the standard, we can say it is
correct, since it is explicitly mentioned there.

C&V, please. Where does the Standard explicitly say that void main(void)
is "correct"? Indeed, where does the Standard explicitly mention void
main(void) at all?

It is implied by "or in some other implementation-defined manner" in
5.1.2.2.1.
No, the Standard does not imply by that text that void main(void) is
"correct", any more than the Standard implies by the same text that struct
{ double d; struct tm t; } main(double *d, long(*f)(void *, double) is
correct. The Standard grants permission for implementations to define
their own entry point signatures (which they can do anyway because it's a
perfectly valid extension), but it does not require every implementation
to support every other implementation' s entry point signatures. So if you
use an extension, you're on your own when it comes to portability.
Perhaps that's not as explicit as it would be if it clearly
stated something like "main shall be defined as void main(void)", but
at least it's more explicit than simply allowing it to be accepted as
an extension (or as a result of UB).
No, it's UB clear and simple, except on C99 implementations that support
it, on which it's implementation-defined.
Given that wording in 5.1.2.2.1, we can now think of it as "correct"
No, *you* can because *you* make up new meanings for words as you go along,
but people who know what they're talking about think of it as a crock.

<snip>
According to the horrifying truth I've just learned, this program
isn't conforming

Yes, it is. It isn't *strictly* conforming, but it is conforming.

And the only difference between that example and one that contains
void main(void) is that here we're providing a check so that we won't
overflow 'i'.
No, there's another difference, which is that in *this* program you got
main()'s signature right, so that isn't a cause of undefined behaviour.
There is no way to check if the compiler recognizes void
main(void),
Right, so don't rely on void main(void), use int main(void) instead.
but such is also the case for bit-fields ordering
Right, so don't rely on bit-fields ordering, but write your code in a way
that doesn't require that dependence instead. Getting the idea now?

and perhaps other features I can't think of right now.
In each case, if you can write the code without depending on such features,
you're onto a winner.
So do you agree now that void main(void) it *is* correct,
No, your constant repetition of this idiocy does not suddenly spring into
meaningful focus - it remains idiocy, no matter how many times you repeat
it.
and that
even though it can't be used in a "strictly conforming" program, it
can be used in a "conforming " one?
The category of "conforming program" is not a useful one, since it's so
broad. Fortran programs are conforming C programs as far as gcc is
concerned.

--
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
Oct 2 '08 #16
s0****@gmail.co m writes:
On Oct 1, 8:20*pm, Richard Heathfield <rj*@see.sig.in validwrote:
[...]
>C&V, please. Where does the Standard explicitly say that void main(void) is
"correct"? Indeed, where does the Standard explicitly mention void
main(void) at all?

It is implied by "or in some other implementation-defined manner" in
5.1.2.2.1. Perhaps that's not as explicit as it would be if it clearly
stated something like "main shall be defined as void main(void)", but
at least it's more explicit than simply allowing it to be accepted as
an extension (or as a result of UB).
You are wrong.

A statement like "main shall be defined as void main(void)" (which
doesn't occur in the standard) has a completely different meaning than
the "or in some other implementation-defined manner" that actually
does occur in the standard. It's not just more or less explicit, it's
a *different statement*.
Given that wording in 5.1.2.2.1, we can now think of it as "correct"
and not necessarily as UB, even though it will yield correct results
in some implementations and UB in others.
By the same reasoning, we can now thing if it as UB and not
necessarily as "correct", even though it will invoke UB in some
implementations and be "correct" in others.

[...]
And the only difference between that example and one that contains
void main(void) is that here we're providing a check so that we won't
overflow 'i'.
Um, there's also the fact that one uses "void main(void)" and the
other doesn't.
There is no way to check if the compiler recognizes void
main(void), but such is also the case for bit-fields ordering and
perhaps other features I can't think of right now.
C99 4p8:

An implementation shall be accompanied by a document that defines
all implementation-defined and locale-specific characteristics and
all extensions.

So you can check whether a compiler recognizes void main(void) by
reading its documentation.
So do you agree now that void main(void) it *is* correct, and that
even though it can't be used in a "strictly conforming" program, it
can be used in a "conforming " one?
You're right that it can't be used in a strictly conforming program
and that it can be used in a conforming one. If you'll look at the
standard, you'll understand that the meaning of a "conforming program"
is almost uselessly broad. And no, I absolutely do not agree that
void main(void) is "correct".

What point are you really trying to make here, anyway? This entire
debate seems to be about the meaning of the word "correct", not about
the C language. Are you arguing just for the sake of arguing, or is
there some point to all this? Is there any real disagreement about
what the standard says, or are just playing word games?

You do understand, don't you, that some implementations allow
"void main(void)" and others don't, but that all hosted
implementations allow "int main(void)"? I don't think you've
explicitly advocated using "void main(void)" in real code; do you
think it should be used? If so, why? If not, why are you so
interested in attempting to prove that it's "correct"?

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Oct 2 '08 #17
vi******@gmail. com said:
On Oct 2, 12:39 pm, gaze...@shell.x mission.com (Kenny McCormack)
wrote:
<snip>
>If my implementation documents the behavior of void main(void),
then it is required to behave as documented. I believe even KT would
agree on this point.

False, it's not required to.
Even a clock that runs backwards is correct occasionally - and how often
this happens depends only on how wrong it was to start with and how fast
it spins.

Let's focus on C99, since the whole "it's implementation-defined" business
was introduced therein. (In C90, the accuracy of documentation not
pertaining to the requirements of the Standard is a QoI issue.)

In C99, then, implementations are free to provide alternative signatures
for main "in an implementation-defined manner". Now, the Standard imposes
requirements on implementations for implementation-defined behaviour:
"each implementation documents how the choice is made". If you are right,
then implementations are free to document their choices with arbitrary
disregard for accuracy. For example, an implementation might claim in its
docs that INT_MAX is 65535 whereas it is actually 32767. So the question
is whether such an implementation is conforming (assuming it conforms in
all other ways).

Since the Standard doesn't define the verb "document", we have no
alternative but to read that word with its ordinary English meaning
(unless, of course, the word is defined in one of the normative
references, which is something I have no way of checking).

In Chambers, the verb "document" is defined as follows: "1. to record
something, especially in written form. 2. to provide written evidence to
support or prove something - from Latin /documentum/ lesson or proof."

Taking sense 1 first - if INT_MAX is 32767 but the implementation' s
paperwork says that it's 65535, then it hasn't recorded the value of
INT_MAX. It has *mis*-recorded it. Taking sense 2 - if INT_MAX is 32767
but the implementation' s paperwork says that it's 65535, then it is not
supporting INT_MAX's value, but undermining it. It is not proving it, but
lying about it. If X is Y but the lie is told that X is not-Y, the lie
neither proves that X is not-Y nor that X is Y. It's just a lie.

So it is not reasonable to suppose that documentation that the
implementation is required to provide for implementation-defined behaviour
is allowed to be incorrect.

<snip>

--
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
Oct 2 '08 #18
On Oct 2, 1:23*am, Richard Heathfield <rj*@see.sig.in validwrote:
s0****@gmail.co m said:
On Oct 1, 8:20 pm, Richard Heathfield <rj*@see.sig.in validwrote:
s0****@gmail.co m said:On Oct 1, 5:14 am, Richard Heathfield
<rj*@see.sig.in validwrote:
s0****@gmail.co m said:
On Oct 1, 1:05 am, Richard Heathfield <rj*@see.sig.in validwrote:
<snip>
Therefore, even if a particular implementation defines a meaning
for void main(void), the behaviour of such a program on some
*other* (arbitrary) implementation is undefined.
So far, the bottom line remains the same: it *is* correct; it
simply isn't guaranteed to work on every compiler.
It seems that we have a terminology disagreement again. I don't see
it as being "correct". I know it fails on at least two
implementations that I use regularly.
But, speaking strictly in regard to the standard, we can say it is
correct, since it is explicitly mentioned there.
C&V, please. Where does the Standard explicitly say that void main(void)
is "correct"? Indeed, where does the Standard explicitly mention void
main(void) at all?
It is implied by "or in some other implementation-defined manner" in
5.1.2.2.1.

No, the Standard does not imply by that text that void main(void) is
"correct", any more than the Standard implies by the same text that struct
{ double d; struct tm t; } main(double *d, long(*f)(void *, double) is
correct.
Neither does it imply that int main(void) is correct, because, as you
said before, the standard doesn't define "correct". But back to *our*
opinions: if you don't consider 'struct { double d; struct tm t; }
main(double *d, long (*f)(void *, double))' correct, why do you
consider the program where I assign 33000 to an int to be correct?
(You said that it looked fine to you.) The only difference between
that example and struct { double d; struct tm t; } main(double *d,
long (*f)(void *, double)) is that the example shown provides a check
so that it will never fail. But other than that, they're the same:
both rely on implementation-defined behavior, and are therefore non-
strictly-conforming.

<snip>
Given that wording in 5.1.2.2.1, we can now think of it as "correct"

No, *you* can because *you* make up new meanings for words as you go along,
but people who know what they're talking about think of it as a crock.
If defining a word that isn't defined by the standard to describe a C
feature is making up new meanings for words, then yes, I'm making up a
new meaning for "correct". But so are you, making up a new meaning for
"crock".

<snip>
There is no way to check if the compiler recognizes void
main(void),

Right, so don't rely on void main(void), use int main(void) instead.
I usually do, but the point is whether void main(void) is correct.
but such is also the case for bit-fields ordering

Right, so don't rely on bit-fields ordering, but write your code in a way
that doesn't require that dependence instead. Getting the idea now?
I do, too, but the point is whether a program that relies on bit-
fields ordering is correct. Here's an example:

// Assumes right to left bit-field ordering
//
struct IEEEFloat
{
unsigned int fraction : 23;
unsigned int exponent : 8;
unsigned int sign : 1;
}

union FloatMix
{
float native;
struct IEEEFloat ieee;
}

#include <stdio.h>

int main(void)
{
// will print -2.0 if 'float' is stored according
// to the IEEE floating point standard
printf("%f\n", (union FloatMix) {.ieee = {.sign = 1, .exponent =
128, .fraction = 0}}.native);
}

Do you consider this program "correct"? If yes, why do you not
consider void main(void) correct?
and perhaps other features I can't think of right now.

In each case, if you can write the code without depending on such features,
you're onto a winner.
So do you agree now that void main(void) it *is* correct,

No, your constant repetition of this idiocy does not suddenly spring into
meaningful focus - it remains idiocy, no matter how many times you repeat
it.
You haven't shown any valid arguments about why it isn't correct.

Sebastian

Oct 2 '08 #19
On Oct 2, 1:54*am, Keith Thompson <ks***@mib.orgw rote:
s0****@gmail.co m writes:
On Oct 1, 8:20*pm, Richard Heathfield <rj*@see.sig.in validwrote:
[...]
C&V, please. Where does the Standard explicitly say that void main(void) is
"correct"? Indeed, where does the Standard explicitly mention void
main(void) at all?
It is implied by "or in some other implementation-defined manner" in
5.1.2.2.1. Perhaps that's not as explicit as it would be if it clearly
stated something like "main shall be defined as void main(void)", but
at least it's more explicit than simply allowing it to be accepted as
an extension (or as a result of UB).

You are wrong.

A statement like "main shall be defined as void main(void)" (which
doesn't occur in the standard) has a completely different meaning than
the "or in some other implementation-defined manner" that actually
does occur in the standard. *It's not just more or less explicit, it's
a *different statement*.
It's different in the sense that one is a mandate, the other is a
permission. But they're both referring to the same subject. Moreover,
in C99, it is an *explicit* permission.
Given that wording in 5.1.2.2.1, we can now think of it as "correct"
and not necessarily as UB, even though it will yield correct results
in some implementations and UB in others.

By the same reasoning, we can now thing if it as UB and not
necessarily as "correct", even though it will invoke UB in some
implementations and be "correct" in others.
In a sense, yes, but I know a lot of people that think of C99 as
"allowing void main(void)" and of C89 as "*not* allowing void
main(void)". Now, I know this is just common sense, and it doesn't
really apply in CLC Pedants Club(tm), but I think it's worth taking it
in into account.

<snip>
* * * * * * * There is no way to check if the compiler recognizes void
main(void), but such is also the case for bit-fields ordering and
perhaps other features I can't think of right now.

C99 4p8:

* * An implementation shall be accompanied by a document that defines
* * all implementation-defined and locale-specific characteristics and
* * all extensions.

So you can check whether a compiler recognizes void main(void) by
reading its documentation.
Yes, but I was referring to providing a check in the code, as I did
with the #if directive.
So do you agree now that void main(void) it *is* correct, and that
even though it can't be used in a "strictly conforming" program, it
can be used in a "conforming " one?

You're right that it can't be used in a strictly conforming program
and that it can be used in a conforming one. *If you'll look at the
standard, you'll understand that the meaning of a "conforming program"
is almost uselessly broad. *And no, I absolutely do not agree that
void main(void) is "correct".

What point are you really trying to make here, anyway? *This entire
debate seems to be about the meaning of the word "correct", not about
the C language. *Are you arguing just for the sake of arguing, or is
there some point to all this? *Is there any real disagreement about
what the standard says, or are just playing word games?
At this point it *is* pretty much about the meaning of the word
"correct". Is it word games? Well, in a post at the beginning of this
thread you yourself said "And no, I'm not playing word games; it
really does depend on what you mean by "correct"." :-)
You do understand, don't you, that some implementations allow
"void main(void)" and others don't, but that all hosted
implementations allow "int main(void)"? *I don't think you've
explicitly advocated using "void main(void)" in real code; do you
think it should be used? *If so, why? *If not, why are you so
interested in attempting to prove that it's "correct"?
I don't think void main(void) is better than int main(void), of
course, but, aside from the issue of portability, I don't think
there's any reason not to use it (provided that you're using a
compiler that supports it). And I'm puzzled about the fact that you
don't consider it to be correct, even in C99.

Sebastian

Oct 2 '08 #20

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

11
8706
by: Michael B. Allen | last post by:
Coming from C and Java on *nix I'm a little out of my element messing around with CList and MSVC++ but I think my issues are largely syntactic. I have an ADT that I use called a 'varray' that can return a pointer to an arbirary sized element in an array given an index and it will allocate the memory to back it if necessary: struct varray *tests = varray_new(sizeof(struct test)); struct test *t = (struct test *)varray_get(tests, 50));
4
2096
by: kk | last post by:
Hi all, i didn't get output in the following code while compiling and executing with g++ version 3.2.3 it doesn't allocate memory to pointer varaible (x) in class B. and it gives correct output while executing in .Net and visual slick editor. why it didn't allocate memory? if anybody knows plz give reply. thanks in advance kk
25
9222
by: MC | last post by:
Hi I have the following piece of code. int *p; p = malloc(10); int *j; j = p; free(p); Is this legal ? will j still point to the same
5
2978
by: fatted | last post by:
I'm trying to write a function which splits a string (possibly multiple times) on a particular character and returns the strings which has been split. What I have below is kind of (oh dear!) printing the results I expect, which I guess means my dynamic memory allocation is a mess. Also, I was advised previously that I should really free memory in the same place I declare it, but I'm not sure how I would go about doing this in my code...
13
5724
by: Rob Corwin | last post by:
Hi, a c# app of mine that parses 30,000 xml files writes large amounts of data to file (> 2GB) using a streamwriter object (sw). everything works fine except that the memory used by the app grows linearly during execution and eventually crashes the computer. without going into too much detail of my code, i made the following observations: - if you comment out the sw.Write(x) statement (which is inside the loop that parses the xml...
3
3479
by: toton | last post by:
Operator overloading has a sort syntax rather than member function call for stack based memory allocation. like complex<int> c1,c2,c3; c3= c1+c2; How the same can be applied to heap based memory allocation? like complex<int> * c1,*c2,*c3; i still want to do something like c3 = c1+c2 ; rether than *c3 = *c1+*c2;
7
4697
by: toton | last post by:
Hi, I have a STL vector of of characters and the character class has a Boost array of points. The things are vector<Characterchars; and class Character{ private: array<Point,Npoints; }; Now are the memory layout is contiguous? i.e all the character resides side by side just like array, and all Points side by side insede the
94
4830
by: smnoff | last post by:
I have searched the internet for malloc and dynamic malloc; however, I still don't know or readily see what is general way to allocate memory to char * variable that I want to assign the substring that I found inside of a string. Any ideas?
1
7984
by: Peterwkc | last post by:
Hello all expert, i have two program which make me desperate bu after i have noticed the forum, my future is become brightness back. By the way, my problem is like this i the first program was compiled and run without any erros but the second program has a run time error when the function return from allocate and the ptr become NULL. How to fixed this? Second Program: /* Best Method to allocate memory for 2D Array because it's ...
0
9957
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look ! Part I. Meaning of...
0
10771
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth. The Art of Business Website Design Your website is...
1
10877
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
0
9593
agi2029
by: agi2029 | last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own.... Now, this would greatly impact the work of software developers. The idea...
0
7143
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert into image. Globals.ThisAddIn.Application.ActiveDocument.Select();...
0
6011
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
1
4633
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
2
4239
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.
3
3245
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.