Memory allocation for an initialized character pointer;

[s0suk3]

Not true. Or at least, not reliably true, and therefore not true within
the meaning of the act, yer'onner.




Only correct where _explicitly_ allowed. Not correct everywhere.
Therefore, not correct when used in a general context (which, evidence
to the contrary lacking, any c.l.c post must be assumed to be).

But this is not my main point. That's this:

Suppose the OP had not written void main(void), but

  union return_tuple main(struct env, char* __cmd_line__, bool intactv)

and Keith had responded to that with the same correction he wrote above,
would you even have considered bothering to respond? My money's on "no".
The contingent of M$-and-Ganoo-lovers who defend void main() almost
always are willing to defend _only_ void main(), and not any other
implementation-defined, non-standard form of main().
So why this discrimination? It can't be that you seriously believe that
void main() is correct, and other non-standard main()s are not. That
would be too dumb even for a Ganoohead.

Well, unlike some people here, I do usually take common sense into
account, so I would certainly have wondered about the purpose of
main() returning a union. But I think I would've pointed it out
anyway, because I don't say that void main(void) is correct because
MSVC allows it, but because the C99 standard allows it.

Sebastian

 

[Ben Bacarisse]

(e-mail address removed) said:

[...] it's not much of a fair comparison, and that's why I provided the
other example who's output is dependent on the bit-fields ordering,
but you didn't answer whether you consider it to be correct.

You did? Oh. I don't always read your stuff all the way to the bottom,
because you include so much irrelevant junk that it gets wearisome. No
doubt there are people around with more patience than me.

OK, this time I'm only including the code:

// 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);
}

The code is not strictly conforming. But is it correct? If yes, why
isn't void main(void) correct?

I've stayed out of this so far because I have no idea what you mean by
correct. I think it is best simply to avoid the term altogether.

Outside of the very narrow notion of a strictly conforming program[1]
(which has almost no practical value) C programs are simply more or
less portable. The code above may suite some purpose so the loss of
portability may be worth it.

The trouble with void main is that there is no up side. People use it
because they've seen it and don't know that int main is universal.
far better to help the world learn that there is portable alternative
that has no down side than to try to make a case for the alternative.

[1] I think this was forced on the committee by ISO rules -- they had
to define such a thing no matter how limited it turned out to be.

 

[Keith Thompson]

Whether the above code is correct or not, void main(void) is not correct
except in the following circumstances:

(a) as the entry point in a program written specifically for translation by
a freestanding implementation, where the implementation's conformance
documentation documents it as such;
(b) as the entry point in a program written specifically for translation by
a C99 implementation, where the implementation's conformance documentation
documents it as such.

(c) as an ordinary function in a program written specifically for
translation by a freestanding implementation, where the
implementation's conformance documentation documents that the entry
point is not called "main";

(d) as the entry point in a program written specifically for
translation by a C99 implementation, where the implementation's
conformance documentation documents it *as an extension*.

In all other situations - i.e. the vast and overwhelming majority of
situations - it is incorrect.

Agreed.

 

[s0suk3]

[...]

Whether the above code is correct or not, void main(void) is not correct
except in the following circumstances:

(a) as the entry point in a program written specifically for translation by
a freestanding implementation, where the implementation's conformance
documentation documents it as such;
(b) as the entry point in a program written specifically for translation by
a C99 implementation, where the implementation's conformance documentation
documents it as such.

(c) as an ordinary function in a program written specifically for
translation by a freestanding implementation, where the
implementation's conformance documentation documents that the entry
point is not called "main";

(d) as the entry point in a program written specifically for
translation by a C99 implementation, where the implementation's
conformance documentation documents it *as an extension*.

(e) as the entry point in *any* program, provided that we're talking
strictly in regard to the standard, and not to any particular
implementation.

Sebastian

 

[Keith Thompson]

(c) as an ordinary function in a program written specifically for
translation by a freestanding implementation, where the
implementation's conformance documentation documents that the entry
point is not called "main";

(d) as the entry point in a program written specifically for
translation by a C99 implementation, where the implementation's
conformance documentation documents it *as an extension*.

Whoops. In (d) I meant "by a *C90" implementation (since C90 doesn't
have the "or in some other implementation-defined manner" clause but
does allow extensions). Though I suppose it could apply to C99 as
well; a C99 implementation can support "void main(void)" as an
extension without citing 5.1.2.2.1.

 

[Ben Bacarisse]

[...]

Whether the above code is correct or not, void main(void) is not correct
except in the following circumstances:

(a) as the entry point in a program written specifically for translation by
a freestanding implementation, where the implementation's conformance
documentation documents it as such;
(b) as the entry point in a program written specifically for translation by
a C99 implementation, where the implementation's conformance documentation
documents it as such.

(c) as an ordinary function in a program written specifically for
translation by a freestanding implementation, where the
implementation's conformance documentation documents that the entry
point is not called "main";

(d) as the entry point in a program written specifically for
translation by a C99 implementation, where the implementation's
conformance documentation documents it *as an extension*.

(e) as the entry point in *any* program, provided that we're talking
strictly in regard to the standard, and not to any particular
implementation.

That is not a useful definition of correct. You are suggesting that
if any one implementation gives meaning to some construct (provided
that that meaning is a permitted extension) then it is correct by your
usage.

But that begs the question: does there even have to be an
implementation? It anything permitted by the standard part of a
correct program? If so (and I can't see why you'd say otherwise) then
almost anything is correct C. So

haskell {
fib = 1 : 1 : map (uncurry (+)) (zip fib (tail fib))
}

is correct C?

 

[Keith Thompson]

[...]
(e) as the entry point in *any* program, provided that we're talking
strictly in regard to the standard, and not to any particular
implementation.

You have it exactly backwards. "void main(void)" is correct *only*
for a particular implementation that supports it.

Talking "strictly in regard to the standard", the standard allows an
implementation to *reject* a program that uses "void main(void)" -- or
to accept it and then behave in any nonsensical manner it chooses.
Apparently this is "correct" by your definition.

 

[Nick Keighley]

Outside of the very narrow notion of a strictly conforming program[1]
(which has almost no practical value)

[1] I think this was forced on the committee by ISO rules -- they had
to define such a thing no matter how limited it turned out to be.

curious. I thought the original C89 standard which first defined
Stricttly
Conforming was done by ANSI. Or did ANSI have to corform with ISO
rules?

 

[Ben Bacarisse]

Outside of the very narrow notion of a strictly conforming program[1]
(which has almost no practical value)

[1] I think this was forced on the committee by ISO rules -- they had
to define such a thing no matter how limited it turned out to be.

curious. I thought the original C89 standard which first defined
Stricttly
Conforming was done by ANSI. Or did ANSI have to corform with ISO
rules?

Good point. I can't answer that. It could be the story is entirely
made up (by me or the person I though I heard it from!).

 

[Old Wolf]

P.S.  Suppose that on my implementation (which happens to be an embedded
system running an ATM), void main(void) causes cash to come out of the
machine ($700 billion dollars worth, ...), but int main(void) generates
no such benefit.  I'd say that's a "compensating advantage" to using
void main(void).  I believe the standard allows this behavior.

The rules for freestanding implementations are
much more relaxed than for hosted implementations.
In order to avoid saying "except for freestanding
implementations" on every second post, I think it
is a reasonable convention to assume that we are
talking about hosted implementations unless it is
explicitly mentioned. KT was certainly following
this convention on his post.

 

[Old Wolf]

Well, unlike some people here, I do usually take common sense into
account, so I would certainly have wondered about the purpose of
main() returning a union. But I think I would've pointed it out
anyway, because I don't say that void main(void) is correct because
MSVC allows it, but because the C99 standard allows it.

Well, the C99 standard allows "Ook!" as a
program too (by your definition of "allows").

Is is "common sense" to you that "Ook!" is a
correct C program? It isn't to me!

 

[Old Wolf]

String literals are treated differently when they initialize char*
pointers than they are when they initialize char arrays. In the first
case, static memory is allocated for the contents of the string
literal, and the pointer is initialized with a value that points to
the first character of the array. It is not safe to attempt to write
to that array.

In the second case, the contents of the string literal are used to
directly initialize the declared array; no separate storage is
allocated.

Are you sure? My understanding is that the
string literal is still allocated, regardless
of what it's subsequently used for.

(Of course there is no way of telling because
of the as-if rule, it's just a language lawyer
question..)

 

[James Kuyper]

Are you sure? My understanding is that the
string literal is still allocated, regardless
of what it's subsequently used for.

(Of course there is no way of telling because
of the as-if rule, it's just a language lawyer
question..)

I thought this was explicitly stated in the standard, but you're right;
the wording about string literals implies that they always result in the
creation of a separate static array during translation phase 7, even if
they are also used to initialize a user-defined array. However, you're
also right in that there's no way for a strictly conforming program to
verify whether or not this has actually occurred; therefore, in practice
this is covered by the as-if rule. If you can't tell whether or not it
exists, a conforming implementation isn't required to provide it.

 

[Kenny McCormack]

And then:


So now you're doing what "CLC regs do best".

Yes. It's called satire. Most of my posts here are just doing the same
sh*t that the regs do, but taking it a step or two beyond - *and* being
honest about what I am doing. The regs are never honest about what they
are doing.

Taking a ludicrous but
legal scenario as the basis for an argument.

Not really ludicrous. The idea is that an implementation could very
well do something special (and, presumably, beneficial) if given a
program that contains vmv.

In fact, Keith was taking
the very reasonable position that you might as well follow the
standard when there's no advantage to not doing so.

Of course. But the point is that there may be an advantage.
I've noticed that lately some of the "reg wannabees" (e.g., CBF, vippy)
have started to take things a little too far, in their attempt to appear
dogmatically correct. KT has been on the right side of this; an
implementation *is* allowed to have extensions.

Surely that is
just the pragmatism that we need more of in this group?

He stated that there was never any advantage to using vmv. I think, of
course, that he is right in any practical sense, but here in CLC, we
deal in ridiculous abstractions (DS9 and all that).