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
