>> On 19/08/2015, Rainer Weikusat <rainerweikusat@???> wrote:

[...]

>> >     p_len = strlen(IFACES_PATH);
>> >     e_len = strlen(essid);
>> >     path = alloca(p_len + e_len + 2);

>> >     

>> >     strcpy(path, IFACES_PATH);
>> >     path[p_len] = '/';
>> >     strcpy(path + p_len + 1, essid);

[...]

> You might want to do some error checking here :-)
>> > path = alloca(p_len + e_len + 2);
>> >     strcpy(path + p_len + 1, essid);

Actually, no. 'alloca' instructs the compiler to generate code to
reserve a certain amount of space in the current stack frame and return
a pointer to it. This it will do by simple arithmetic and in case the
pro forma reserved space isn't really available yet, the stack is
supposed to be grown accordingly by the kernel (for a single-threaded
process). If this doesn't work, an attempt to use it will
segfault. There are some more interesting error scenarios for large
allocations, certain ways of using them and multi-threaded processes
(specifically, it's possible to skip over the guard page at the bottom
of the thread stack and write into the memory immediatley below that,
ie, overwrite the top of the stack of some other thread or something
totally unrelated).

Some people strongly dislike this interface because of these "be sensible
or BEWARE of the consequences" properties. But "being sensible" is easy
for simple cases (such as here) and 'stack allocation' is IMHO
preferably for relatively small things as it will be freed automatically
and won't cause unpredictable, global side effects on the malloc heap.