9

The C standard prohibits a goto into a function scope where a VLA exists.

A VLA and the call to alloca function should have the same result on low level.

(I could be wrong, as I'm just a C, not a low level programmer, but in my imagin that appears to be witty)

So will the following snippet be also undefined behaivng?

int main()
{
    char *p;

    goto label1;

    {
        p = _alloca(1);
label1:
        p = NULL;
    }
}

Ofcourse I cant refference p, but whats about the behaviour?

dhein
  • 6,431
  • 4
  • 42
  • 74
  • Not up on acronyms - what is a VLA in this context? – cup May 23 '14 at 08:54
  • @cup It is in the C standard documentation the abbrev for "Variable Length Array" so, something like `char Array[variableLength];` – dhein May 23 '14 at 09:33

3 Answers3

5

Actually, the rule 6.8.6.1 states: 

  A goto statement is not allowed to jump past any declarations of objects 
  with variably modified types.

In your code, there does not exist an object with variably modified types. alloca does not declare an object (that the compiler has to care of). Thus, there is nothing like a scope for alloca, and no reason for undefined behavior in the sense of rule 6.8.6.1.

EDIT

To elaborate the answer a bit: the "undefinedness" of the behavior in case of VLA is due to the promise of a declaration that an object is "known" within its scope (at language level). In general, a declaration sets a context for code execution. There is no need that it is executed at runtime. However, this is not true in case of VLA: here this promise is implemented partly at runtime, breaking C's static declaration approach. To avoid further conflicts that would lead to a dynamic typing system, rule 6.8.6.1 avoids such conflicts.

In contrast, at language level alloca is simply a function; its call does not constitute any scope. It makes only a promise about its run-time behavior in case it is called. If it isn't called, we do not "expect" anything from a function. Thus, its pure existence does not raise any conflict: both cases (bypassing or non-bypassing) have a well defined semantic.

Matthias
  • 8,018
  • 2
  • 27
  • 53
  • 3
    `alloca` is nonstandard, so the standard wouldn't say anything about it in any case. – Potatoswatter May 23 '14 at 08:34
  • @Potatoswatter: even it is nonstandard, it simply does not *declares* anything. Thus, the problem with VLAs is not relevant here. – Matthias May 23 '14 at 08:37
  • I agree, but the concepts could be made a bit clearer. The current wording of the answer seems to be simply evaluating the `alloca` call in terms of 6.8.6.1. – Potatoswatter May 23 '14 at 08:46
  • @Potatoswatter but it could anyway cause undefined behavior, couldn't it? – dhein May 23 '14 at 09:35
  • 1
    @Zaibis `alloca` ideally behaves as your compiler's specific documentation says. It doesn't usually interact with control flow or scoping. So, you should be OK. – Potatoswatter May 23 '14 at 10:01
1

A VLA and the call to alloca function should have the same result on low level.

There are still a few differences. A VLA object is discarded when the scope where it is declared ends and the memory object allocated by alloca is discarded when the function returns.

This makes a difference because the requirement in c99, 6.8.6.1p1 ("A goto statement shall not jump from outside the scope of an identifier having a variably modified type to inside the scope of that identifier") is concerned by the runtime allocation / deallocation of objects with variably modified type. Here the alloca statement is not executed after goto is performed, so I would not think the goto call would invoke undefined behavior.

ouah
  • 142,963
  • 15
  • 272
  • 331
  • Ahhhh I didn't even thought of that difference. so even after leaving the scope where alloca is theoretical called, the memory would be refferencable until we reach the return, doesn't matter of we have left a block scope? And in other cases, would you think alloca could cause UB regarding to the goto rule in another way? – dhein May 23 '14 at 09:29
  • @Zaibis if the label is after the `alloca` statement like in your example, the `alloca` function is just not called. – ouah May 23 '14 at 09:32
1

The C Standard has nothing to say about the behavior of alloca(). Some compilers use the stack in a very predictable fashion, and access automatic variables using a largely-redundant frame pointer. On such compilers, it's possible to reserve space on the stack by simply subtracting a value from the stack pointer, without the compiler having to know or care about the reservation in question. Such code will break badly, however, if the compiler uses the stack in ways that the application wasn't expecting.

I don't think that something like:

  int *p = 0;
  if (!foo(1,2,3))
    goto skip_alloca;
  p=alloca(46);
skip_alloca:
  bar(4,5,6);
  ...

is apt to be any more dangerous than:

  int *p = 0;
  if (foo(1,2,3))
    p=alloca(46);
  bar(4,5,6);
  ...

If there is no residue on the stack from the function call at the time the alloca() is performed, either operation would likely be safe. If there is residue on the stack at the time of the alloca (e.g. because the compiler opts to defer cleanup of foo's arguments until after the call to bar) that would make alloca() misbehave badly. Using the goto version of the code might actually be safer than the version with if, because it would be harder for a compiler to identify that deferring the cleanup from foo might be advantageous.

supercat
  • 77,689
  • 9
  • 166
  • 211