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
On 25/08/2015, Edward Bartolo <edbarx@???> wrote:
> OOOps:
>
> type
> TDynamicRecord = record
> RecordTypeID: integer;
> ActualRecord: Pointer;
> end;
>
> should be:
>
> type
> TDynamicRecord = record
> RecordTypeID: TRecordTypeID;
> ActualRecord: Pointer;
> end;
>
> On 25/08/2015, Edward Bartolo <edbarx@???> wrote:
>> Quote: Rainer Wrote:
>> <<A C string of length 0 is just a "\000". A NULL pointer is not a
>> string.
>>
>>
>> A unallocated variable, be it anything from a simple basic variable
>> like an int*, to the most complex of struct variables, is simply a
>> placeholder for a memory address, or a pointer devoid of space, apart
>> from the space for a memory address.
>>
>> Pointers can be any type of data. I used to put their flexibility in
>> my Delphi Pascal projects. I also used null pointers as follows:
>>
>> type
>> TRecordTypeID = (message0, message1, message2, message3);
>>
>> var
>> aDynamicRecord: Pointer;
>>
>> type
>> TDynamicRecord = record
>> RecordTypeID: integer;
>> ActualRecord: Pointer;
>> end;
>>
>>
>> This is equivalent to:
>>
>>
>> enum TRecordTypeID = {message0, message1, message2, message3};
>>
>> void* aDynamicRecord;
>>
>> typedef struct TDynamicRecord {
>> TRecordTypeID RecordTypeID;
>> void* ActualRecord;
>> };
>>
>>
>> Lazarus and Delphi provide a class, TList, which is a list of untyped
>> pointers. This is like: C++'s
>> vector <void*> my_little_vector_that_can_hold_anything;
>>
>> OR, if my memory serves me right, C's:
>> void** weirdo_var;
>>
>> Therefore, to push variables onto the list, it requires type casting,
>> which is fully supported, and dynamic allocation functions to allocate
>> and FREE memory.
>>
>> On 25/08/2015, Irrwahn <irrwahn@???> wrote:
>>> On Tue, 25 Aug 2015 13:49:39 +0100, Rainer Weikusat wrote:
>>>> "tilt!" <tilt@???> writes:
>>>>> On 08/25/2015 02:09 PM, Rainer Weikusat wrote:
>>>>>> Considering that this enforces some kind of 'bastard URL-encoding'
>>>>>> (using + as prefix instead of %) for all other bytes, it's also going
>>>>>> make people who believe that UTF-8 would be a well supported way to
>>>>>> represent non-ASCII characters very unhappy.
>>>>>
>>>>> 1. This encoding is not about URLs but filenames.
>>>
>>> <snip>
>>>
>>>>> 2. It is not safe to assume that SSIDs contain UTF-8.
>>>>>
>>>>> The relevant IEEE standard is botched.
>>>>>
>>>>> https://en.wikipedia.org/wiki/Service_set_%28802.11_network%29
>>>>>
>>>>> "Note that the 2012 version of the 802.11 standard defines a
>>>>> primitive SSIDEncoding, an Enumeration of UNSPECIFIED and UTF-8,
>>>>> indicating how the array of octets can be interpreted."
>>>>>
>>>>> Imagining how many service sets still operate using the pre-2012
>>>>> standard (and/or are botched implementations themselves that fail
>>>>> to recognize the issue), i think it is safe to assume that the
>>>>> character encoding of an SSID is "UNSPECIFIED" in the general case.
>>>>>
>>>>> Therefore, it is handled encoding-agnostic on a byte-per-byte
>>>>> basis,
>>>>> and this is what the code accomplishes.
>>>>
>>>> The code replaces everything which is neither an ASCII letter nor a
>>>> digit nor - with a three byte escape sequence composed of + followed by
>>>> the hexadecimal representation of the byte value. This implies that it
>>>> will eliminate any use of non-ASCII letters both UTF-8 and otherwise.
>>>
>>> Since the encoding is solely used to construct names for configuration
>>> files (one per SSID), the only inconvenience I can think of is you might
>>> end up with completely unintelligible names for those files, and only in
>>> extreme cases. AIUI these files are not intended to be maintained by a
>>> user
>>> or administrator but rather only be created, manipulated or destroyed by
>>> the software.
>>>
>>> Unless you are manually debugging the software in an environment which
>>> is
>>> crowded with wireless stations "ééééé", "ééééá", "ééééç" and the like,
>>> you
>>> shouldn't worry too much about it. As a user, you shouldn't care at all
>>> -
>>> could as well use a sensible hashing algorithm, or some database, or
>>> black
>>> magic. Or just go with hex encoding from the get go, since an SSID is
>>> just
>>> a sequence of octets. "\x00\x00\x00\x00" (in C string literal notation)
>>> would make a perfectly fine SSID, composed of five (sic!) null bytes,
>>> but
>>> it is not a sensible code sequence in any character set I am aware of.
>>>
>>> It is totally sensible to break down the character set to something that
>>> is more or less guaranteed to be valid for building names in any file
>>> system currently in use on this planet. That having said, I'm not sure
>>> how
>>> the dash (minus) ended up in the allowed character set, as this would
>>> allow
>>> for names starting with '-', which is not something I would consider
>>> good
>>> style, but other's mileages may vary.
>>>
>>> As mentioned above: if there is any real issue with the code at all, it
>>> is
>>> the fact that null characters (zero bytes) are not handled correctly by
>>> the
>>> code. But that's a feat it has in common with many consumer WiFi
>>> appliance
>>> configuration utilities (and a pile of professional tools too, I
>>> suspect).
>>>
>>> --
>>> Irrwahn
>>>
>>>
>>> _______________________________________________
>>> Dng mailing list
>>> Dng@???
>>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
>>>
>>
>
::
Re: [DNG] netman GIT project
