My 'irrational' choice of C language for backend.

As a coder, I lack knowledge and experience. This is plain clear from
the code I can write, but I offered my very limited coding
capabilities to help, notwithstanding I knew, I would have been a
dwarf among giants.

I opted out of choosing Lazarus Pascal for the backend, for the fact,
that Lazarus Pascal is only used by a small niche of developers, and
hence, logically, one cannot expect the frequency of security patches
one finds in C. Nobody uses Lazarus to write a kernel or any important
part of the OS. This means, choosing Lazarus for the backend was and
still is a bad choice. Lazarus would have created a huge executable
(~6MB) with many hidden function calls included for the reason that it
is high level. This problem is not as critically experienced using C,
at least, in this dwarf's opinion.

People out there want interfaces files to be human readable. Well,
there is a workaround that which enables one to use simple files names
like '00001', '00002', '00003', and so on. One only needs to add
another file, wifis.names, to add a lookup table like:

00001 "my home wifi in Malta"
00002 "my wifi at work"
00003 "wifi at cafe"

This can be read by cat and still anyone wanting to manually connect
would be able to do so. Internally, backend would not accept an
interfaces file whose name is not according to the above. Parsing the
above should not be a performance penalty. It is however, a coding
challenge for someone like me with the presumption to code with
giants.


Edward




On 23/08/2015, Rainer Weikusat <rainerweikusat@???> wrote:
> "tilt!" <tilt@???> writes:
>> On 08/22/2015 04:40 PM, Rainer Weikusat wrote:
>>> Roger Leigh <rleigh@???> writes:
>>>> On 20/08/2015 11:27, Rainer Weikusat wrote:
>>>>> Roger Leigh <rleigh@???> writes:
>>>>>> On 19/08/2015 17:39, Rainer Weikusat 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);

>>>
>>> [...]
>>>
>>
>> I am fully aware of the C string problem.
>
> There is not such thing as a "C string problem": The C standard library
> supplies a set of string handling functions working in a certain
> way. This way has some advantages but also, some disadvantages.
>
> [...]
>
>> Believe me, I already rewrote specifically this section of
>> the code, so don't bother too much.
>
> Ah ... and why precisely are you telling me this? Some guy posted some
> code. I posted some comments and related code intended to be helpful in
> this context. Some discussion also resulted from that. You seem to be
> convinced that this wouldn't be worth the effort compared with the much
> larger effort of "rewriting the code" (you assert in a way which seems
> rather condescending to me). I could comment on this social procedure
> but I won't because I'm convinced that this "talking about people" never
> leads to anything good. But should Edward (or you) post more code, I
> will probably look through that, at least cursory, and post more
> comments (and probably more code because the comments alone are not
> useful) because this (code) happens to be something I'm interested in.
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>