Roger Leigh <rleigh@???> writes:
> On 19/08/2015 17:39, Rainer Weikusat wrote:

[...]

>> static void saveFile(char* essid, char* pw) //argv[1], argv[2]
>> {
>>     char *path;
>>     FILE *fp;
>>     unsigned p_len, e_len;

>>

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

>>     

>>     fp = fopen(path, "ab+");
>>     fprintf(fp, IFACE_TMPL, essid, pw);
>>     fclose(fp);
>> }

>>

>> int main(int argc, char **argv)
>> {
>>     saveFile(argv[1], argv[2]);
>>     return 0;
>> }

>
> I'm not picking on this post in particular out of the rest of today's
> thread, but I did think this was a good example. While I don't want
> to act like a rabid C++ zealot, stuff like this really makes me
> shudder due to the fragility and unnecessary complexity for something
> which is really trivial.
>
> While the relative safety and security of C string handling can be
> debated, I do think the question needs asking: Why not use a language
> with proper safe string handling and avoid the issue entirely?
> It's only "safe" until it's refactored to break the existing
> assumptions and make it accidentally unsafe. The constants such as 2,
> 1 plus the strlen() calls are prime candidates for future bugs. It's
> not like this /needs/ to be done in C.

The 'constant 2' follows from the fact that the length of the result
string is the length of the path plus the length of the essid string
plus two more bytes/ characters, namely, the '/' and the terminating
zero.

The 'constant 1', in turn, follows from the fact that the essid has to
be appended after the string made up of the path and the added '/'.

That's how string processing in C happens to look like because of how
the language (library, actually) defines a string and because of the
operation supposed to be performed here (combine three different parts,
one with constant length).

Could you perhaps elaborate on what you were writing about? Minus trying
to start a language war, that is. The original author chose C. Because
of this, I wrote and posted a simple example how to do string processing
in C without relying on 'large enough' fixed size buffers.