7

In this post, the OP contains code where there is a lot wrong with, but 1 line made me especially curios, since I wasn't able to look anything up, disallowing it. This is the specific line:

int n = 100000, arr[n];

Is the order of declaration and initialization beeing ensured?

So here I would assume it might even happen that n wasn't initialized when arr gets declared, what obvisiously would not be good.

But I wasn't able to find any statement regarding this in the iso/iec 9899 draft at hand neither stating it undefined nor defining it.

So is this as I assume not defined behavior? Or is it?

And either way, what is the rule beeing applyed for that result?5

Edit:

Is that valid for C99, too?

autistic
  • 1
  • 3
  • 35
  • 80
dhein
  • 6,431
  • 4
  • 42
  • 74
  • There is no _comma operator_ in that line. A declaration is no statement! – too honest for this site Jul 12 '16 at 11:40
  • @Olaf: Ah you are right, I was allready taught that here the comma is doing a different job. But does that change the outcome? does the seperatation for commatares in a declaration ensure the order? – dhein Jul 12 '16 at 11:41
  • Rolled back the edit. Please don't edit a question after you got an answer such that the answer looses context. – too honest for this site Jul 12 '16 at 12:03
  • 2
    @Olaf: First of all, I edited it before you palced even your answer. Secondly the C tag is about the language and not a specific version. so adding a version I'm specifically refering to is not changing the context but just adding information. And third: notifying me about a wrong asumption just to insist it had to stay in the OP is ridiciolous if not even offensive. Keep taht in mind.... – dhein Jul 12 '16 at 12:07
  • You edited the text, agreed and I leave you that. But you added the C99 tag after you got the answer. And the C tag is about the C standard. Which is C11 **only**. Read the foreword of C11 (and C99), both are very clear that the respective previous version is **withdrawn** with the new version. Regarding correcting false assumptions: You are not allowed to change the context of an answer. If you have to add a correction, **add** it to the question with some explanatory text! – too honest for this site Jul 12 '16 at 12:12
  • Added a text to your question which should suite. – too honest for this site Jul 12 '16 at 12:26
  • 1
    @Olaf: Are you suggesting that it should be impossible to know that the meaning of any piece of C code should be considered subject to change at the whim of the Standards Committee? Other languages have for decades recognized the concurrent existence of standards for different versions, so an HTML4 document means the same today as it did before HTML5 was invented, even if the text would have a different meaning if interpreted as HTML5. – supercat Sep 02 '16 at 15:42
  • @Olaf: Out of curiosity, what terminology would you use to describe the popular family of dialects for machines whose execution model differed from the PDP-11 only in terms of data representations, alignment requirements, and stack layout, and whose semantics included thopse of the PDP-11 language except for the aforementioned differences? – supercat Sep 02 '16 at 15:44

1 Answers1

2

In short: Your code is correct. It is your premise which is wrong. The two declarations are not "in the same sequence point". (As a sidenote: there cannot be anything in a point, but only between two points, points are dimensionless).

The details:

6.8.2 of the standard shows the grammar of a compound statement which is the basis of every function body:

compound-statement:
    { block-item-listopt }
block-item-list:
    block-item
    block-item-list block-item
block-item:
    declaration
    statement

Relevant here is the block-item. As shown, it can be a statement or a declaration. This implies that a declaration is not a statement. You show a declaration, so the , is not an operator here, but seperates the init-declarators (a declarator optionally with an initialiser, see 6.7 for the grammar). And there is a sequence point right after the declarator (and before the optional initialiser, btw.).

6.7.6p3: A full declarator is a declarator that is not part of another declarator. The end of a full declarator is a sequence point. If, in the nested sequence of declarators in a full declarator, there is a declarator specifying a variable length array type, the type specified by the full declarator is said to be variably modified. Furthermore, any type derived by declarator type derivation from a variably modified type is itself variably modified.

Regarding the "execution order": That is actually left to the implementation. But the standard requires to follow the abstract machine. Sequence points are the fundamental ordering concept.


The question is actually not directly related to VLAs, but declarators in general. Without citing the sections of all previous versions, the behaviour is identical in all version, because otherwise something like int i = 3, k = i; would also not work (it does).

too honest for this site
  • 12,050
  • 4
  • 30
  • 52
  • 2
    What you make it up from that there is? I looked also up the material you refer to before posting but I still nto see where it says that. – dhein Jul 12 '16 at 11:52
  • @Zaibis: Sorry, I caught the wrong paragraph. See the edit. – too honest for this site Jul 12 '16 at 11:55
  • @Olaf: interesting. What version of the document you are refering to? When I made a full search through my document by looking for "variable length array" I didn't find that paragraph. – dhein Jul 12 '16 at 11:57
  • @Zaibis: You might have missed the link. I refer to the only C standard and the only valid version, which is C11. (The link is to the final draft, but that is identical in all relevant aspects with the final version). – too honest for this site Jul 12 '16 at 12:00
  • @Olaf: My fault. I used the wrong tag. I'm asking about c99 as our IDE/compiler just supports c99. While this is probably the same for c99 as for c11, I'm still curious how I could have found it in my version of C – dhein Jul 12 '16 at 12:02
  • I can assure you it **is** the same in C99. Just don't change the game once you have an answer! If you have the C99 final draft, there is very certainly a similar phrase, just search for the grammar snippet I gave you. – too honest for this site Jul 12 '16 at 12:04
  • 5
    @Olaf: I jsut clarified what I was refering to. I didn't change the scope. If you asume I was refering to c11 thats with all respect not my fault. the C tag in use here doesn't imply any version. so even if you might be right, it doesn't imply refering to c11. Also I looked for exactly that phrasing and didn't find it. maybe due to some `-` wording seperation. But also my edit didn't invalidate your answer at all. – dhein Jul 12 '16 at 12:11
  • @Zaibis: The C tag is about the C language which is defined by the C standard. Which is C11. Not C99, not K&R-C! It is your own fault if you did not state which version you are working with. Anyway, it is not clear what your problem is, as the answer is identical for C99, just the references are different to changed numbering. If you are too lazy to look up them in your version it is not my fault! – too honest for this site Jul 12 '16 at 12:19
  • Leading with a direct yes/no answer to the title question would add clarity. – chux - Reinstate Monica Jul 12 '16 at 13:43
  • 1
    @chux: I just thought padding the answer with references from the standard would be more clear and help with older versions. – too honest for this site Jul 12 '16 at 13:45
  • An unpopular answer... I don't know why, because it's technically correct, and from my eyes it's just information... I guess facts hurt sometimes? I think we all get that... but the popularity of this question doesn't justify the unpopularity of this answer. Can we turn this situation around? I want to edit it, but factually, it's a good answer, and I don't know what I can do to quench whatever negativity other people have associated. If you read this and you don't like this answer, please, tell us what's wrong so we can fix it... – autistic Aug 05 '18 at 18:28
  • @autistic Thanks for the feedback, I take it as a "heads up". It's a bit old already and each time I get a downvote, I re-read it how I can improve it. And I had quite some edits to get it into shape, to no avail, though. I agree it's correct (ok, I'm biased). I'd like to get a comment if I'm wrong, but none so far. I'm afraid we have to live with the fact people don't like answers they don't want, correct or not. That#s the problem with SO, high-voted posts get sympathy up-votes, expecailly for problems neding detailed knowledge, no matter they are correct, as long as presented plausibly. – too honest for this site Aug 05 '18 at 19:02