>> On 19/08/2015, Rainer Weikusat <[email protected]> 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. _______________________________________________ Dng mailing list [email protected] https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
