Irrwahn <irrw...@freenet.de> writes:
> On Tue, 25 Aug 2015 17:02:55 +0200, Tilt! wrote:
>> Am 25. August 2015 16:52:41 MESZ, schrieb Edward Bartolo <edb...@gmail.com>:
>>> 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).
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
