Irrwahn <irrwahn@???> writes:
> On Tue, 25 Aug 2015 17:02:55 +0200, Tilt! wrote:
>> Am 25. August 2015 16:52:41 MESZ, schrieb Edward Bartolo <edbarx@???>:
>>> We can easily avoid having to encode ESSIDs by creating a file
>>> containing a texual lookup table as the following, but since the
>>> project is already functional, it looks like rebuilding a house that
>>> is already habitable.
>>>

>>> essid1    "my little wifi at home"
>>> essid2    "oops, wifi at my partner's!"
>>> essid3    "wifi at work, without my boss' knowing"
>>> essid4    "wifi at library"

>>>
>>> Ok, you get it. No need of encoding anything and the user can describe
>>> his wifi with whatever he deems justified.
>>>
>>> Edward
>>
>> IMHO:
>>
>> If we use a mapfile, we have the encoding problem *there* instead of the wifi directory filenames ... It will only move the problem, not solve it :D
>>
>> i wonder if we ever get to see such SSIDs from iwlist anyway - how is it supposed to print SSIDs that contain the zerobyte ...
>
> If we can drop the requirement to cope with '\0's, as the frontend
> uses iwlist and grep(!) to acquire the SSID, this would leave us with
> just the '/' to encode. The most "evil" thing we'd had to expect
> would be "////////////////////////////////".
>
> Thinking about it, one can even do away with all the allocation stuff
> and just use a single fixed size buffer of 32 * 3 + 1 bytes to hold
> the filesystem friendly encoded version, since there are no thread
> safety contraints imposed on the backend.

A suggestion for that: Create something like

struct encoded_essid {
    uint8_t d[32 * 3 + 1];
};

and make the caller pass a pointer to that to the encoding routines. It
can then be allocated on the stack by the caller (if the caller so
desires).