issue-#78 fixing type of WinNet.hostent.h_addr_list

[Josef Templ]

Discussion for this issue has already been started in http://forum.blackboxframework.org/view ... f=33&t=294.
Now the facts are pretty clear.

For the issue see http://redmine.blackboxframework.org/issues/78.
For the changes see http://redmine.blackboxframework.org/pr ... 8e79cdae64.

The changes are very much like the ones proposed in CPC 1.7 rc5 except:
- not using WinApi.PtrSTR for the element type because this is not a zero terminated string;
- using a type cast in CommTCP for explicitly expressing the specialization to in_addr.

- Josef

[luowy]

How about?

h_addr_list*: POINTER TO (*?*) ARRAY [untagged] OF POINTER TO in_addr;
or
h_addr_list*: POINTER TO (*?*) ARRAY [untagged] OF Ptrin_addr;

then old code

inaddr := hostentry.h_addr_list^[0]^[0]
inaddr := SYSTEM.VAL(WinNet.in_addr, hostentry.h_addr_list^[0]^)

can be:

inaddr := hostentry.h_addr_list[0]

[Josef Templ]

an internet address (in_addr) is a specialization of the abstract notion of an address.
According to msdn, the h_addr_list is not aware of internet addresses but deals with abstract addresses only.
An abstract address is a byte block represented by a pointer to the first byte (or char as it is defined in msdn).
The field h_addrtype defines the particular address family being used.
In practice we only use IPv4 internet addresses, of course, because IPv4 is so dominating now.
In the future there may also be IPv6 being used. In principle also NETBIOS addresses
could be used in h_addr_list.

To summarize it:
Any reference to in_addr in the declaration of h_addr_list is an inappropriate specialization.

- Josef

[luowy]

yes,we know it's origin form: char**, must cast when use it in C;
the BB author should noticed this situation,and selected the flexible form,
but it seems need a little correction.

Josef, your correction is right,but like turning a circle, return to it's origin:
must cast it with SYSTEM.VAL when using it in IVP4 code.
it's error-prone, in my opinion.

I did a test use this form:
h_addr_list*: POINTER TO(*?*) ARRAY [untagged] OF Ptrin_addr;

Code: Select all

MODULE ObxTest;
	IMPORT WinNet, Log := StdLog;
	
	(*
		WinNet.hostent* = RECORD [untagged]
			h_name*: WinApi.PtrSTR;
			h_aliases*: POINTER TO (*?*) ARRAY [untagged] OF WinApi.PtrSTR;
			h_addrtype*: SHORTINT;
			h_length*: SHORTINT;
			h_addr_list*: POINTER TO(*?*)  ARRAY [untagged] OF Ptrin_addr; (* <===  *)
		END;
	*)

	PROCEDURE Do* ();
		VAR 
			hostentry: WinNet.Ptrhostent; 
			inaddr: WinNet.in_addr; 
			shortPName: ARRAY 64 OF SHORTCHAR;
			ok: BOOLEAN; i: INTEGER;
	BEGIN
		shortPName := "www.163.com";
		hostentry := WinNet.gethostbyname(shortPName);
		ok := hostentry # NIL;
		IF ok THEN
			i := 0;
			WHILE hostentry.h_aliases[i] # NIL DO
				Log.String(hostentry.h_aliases[i]$); Log.Ln;
				INC(i);
			END;
			Log.Ln;
				
			i := 0;
			WHILE hostentry.h_addr_list[i] # NIL DO 
				(*inaddr := hostentry.h_addr_list[i]^;*) 
				inaddr := hostentry.h_addr_list[i]; (* lost'^' is correct also! *)
				Log.Int(ORD(inaddr.S_un.S_un_b.s_b1)); Log.Char('.');
				Log.Int(ORD(inaddr.S_un.S_un_b.s_b2)); Log.Char('.');
				Log.Int(ORD(inaddr.S_un.S_un_b.s_b3)); Log.Char('.');
				Log.Int(ORD(inaddr.S_un.S_un_b.s_b4)); Log.Ln;
				INC(i);
			END;
		ELSE
			Log.String("Error: gethostbyname() : "); Log.Int(WinNet.WSAGetLastError())
		END
	END Do;
	
	PROCEDURE Init* ();
		VAR 
			data: WinNet.WSADATA;
			res: INTEGER;
	BEGIN
		res := WinNet.WSAStartup(0202H, data);
		IF res = 0 THEN
			Log.String("Fail at WSAStartup"); Log.Ln;
		END;
	END Init;
	

END ObxTest.

It's IVP4 code,of course，the user must use cast in IVP6 .

luowy

[Josef Templ]

luowy, I strongly disagree.
It doesn't give sense to cast an IPv4 address to IPv6.
It only gives sense to cast an 'unknown' (=abstract) address to a specific address type
such as IPv4 or IPv6. The current form follows this rule and is the correct form.
It also conforms to the spec in msdn. The required SYSTEM.VAL or any other form of
assumption on the address format in CommTCP is unavoidable. However, it is inside of CommTCP,
so the normal user does not see it.

- Josef