Compiling on Tru64Unix 4.0f

[pjot]

Maybe it has to do with those pointer sizes again? I see that a 'allocMemory' returns a void pointer (8 bytes), but in the 'p_array' function (nl-list.c) the allocMemory is casted to UINT, which is 4 bytes.



Still that does not illuminate why 1-dimensional arrays with a large size can be created. Also many other newLisp functions should crash, which is not happening. Indeed it must be something else then.



This works:

Code Select Expand


(set 'a (array 3))


This crashes:

Code Select Expand


(set 'a (array 4))


Also I found the Compaq C Programmers Guide online:



http://h30097.www3.hp.com/dtk/Compaq_C_Compiler/doc/lrm/DOCU0040.HTM">http://h30097.www3.hp.com/dtk/Compaq_C_ ... CU0040.HTM">http://h30097.www3.hp.com/dtk/Compaq_C_Compiler/doc/lrm/DOCU0040.HTM



Peter

[Lutz]

May be memory is segmented, how is it wiht larger strings?



(dup "A" 1000000)



or



(read-file "biggerfile.txt")



That would also force a bigger contiguos memory area to be taken.



Lutz

[newdep]

Yoooo Pjot, some addons...



(dup "a" 10000)

does not show anything..



where (dup "a" 2047) is the maximum that works..



(read-file "core")  does work though i did not test it upto the

complete size of 45948928 bytes over telnet ;-)



Norman.

[Lutz]

May be the memory is segmented in 2k increments somehow? I will have a look into the Compaq tru64 docs this weekend.



Lutz

[newdep]

Lets check that...

Pjot what does the /etc/sysconfigtab show up with?

and drop a vmstat output..



Norman.

[pjot]

VMstat:

Virtual Memory Statistics: (pagesize = 8192)

  procs    memory         pages                          intr        cpu

  r  w  u  act  free wire fault cow zero react pin pout  in  sy  cs  us  sy  id

  3 348 32   46K 6641  10K   7M   1M   3M 8812   1M 6152   1  7K  2K   0   1  99

The sysconfigtab shows, next to the possible hardware drivers, many tuning options which I cannot paste here; it's just too much info.



Instead, I will try find out the memory entry's first and paste it later.

[pjot]

It's the variable MAX_STRING in 'newlisp.h' which is bothering us. This variable was put to 2048.



The arrays work now. The newLisp binary survives all tests in 'qa_dot'.



Peter

[Lutz]

That doesn't make sense to me at all :)



MAX_STRING is not used in any array code. If that would be a limitation than big arrays or big dup's wouldn't work on Linux/UNIX/Win32. But again it is not used in any array or dup code. Do a grep MAX_STRING and you will see.



Lutz

[pjot]

If MAX_STRING is higher than 2048 then newlisp.c calls 'vasprintf' with variadic args. However, if 'vsnprintf' fails then it returns a '-1' in Tru64. This situation is only defined in your code for MinGW.



Just uploaded the last changes, see the PM.



Peter

[Lutz]

Yes, the return value for vsnprintf() has to be checked on any port and even between different GCC's there me be a difference. Now I remember, that it gave me a lot of headache too when moving to MinGW. Returning -1 instead of the used size is the 'older' style of vsprintf(), but still used by MinGW and as you found out in true64.



Lutz

[Lutz]

Looks like we have a working true64 port passing all tests! Thanks to Peter for all the hours he has put into this.



Lutz

[newdep]

Yups! many thanks for a running Tru64 Newlisp.. Greeeat enhancement!



Norman.

[pjot]

Some more testing on Tru64Unix 5.1B (so not 5.1A) revealed a couple of minor issues.



1) The following warning during compiletime:

cc: Warning: nl-sock.c, line 655: In this statement, the referenced type of the pointer value "&remote_sin_len" is "unsigned int", which is not compatible with "unsigned long". (ptrmismatch)

        (struct sockaddr *)&remote_sin, &remote_sin_len);

----------------------------------------^

The variable 'remote_sin_len' should be a 'long' instead of an 'int'. I am not sure how serious this is, but it can easily be solved with a macro. It is strange that Tru64Unix 4.0 never complained about this.



So what do you think, change this?



2) Other not-serious compilewarnings:

cc: Warning: nl-web.c, line 360: In this statement, the referenced type of the pointer value "(char ...)0" is "short pointer to char", which is not compatible with "long pointer to char". (ptrmismatch)

        while((size = strtoul(buff, (char**)0, 16)) > 0)

------------------------------------^

There are a couple of these, regarding the (char **)0. But if small or long pointer, since it is a reference to a '0', it looks unimportant to me.





3) The tests (test-exec) and (test-process) fail because the part for Win32 is executed, which assumes that a file is found in the current directory. On my account on the other machines the current path is in my $PATH, but this is not common to Unix. So these tests must be changed for (opsys=9):

Code Select Expand


(if (and (> opsys 5)(< opsys 9)) (exec "newlisp exectest") (exec "./newlisp exectest"))

...and also...

(if (and (> opsys 5)(< opsys 9)) (process "newlisp processtest") (process "./newlisp processtest"))




Furthermore I will start hosting precompiled Tru64Unix binary's at my newLisp site - that's convenient for me, too. ;-)



Peter

[Lutz]

(struct sockaddr *)&remote_sin, &remote_sin_len);



remote_sin_len isn't used afterward so you can just declare it as 'unsigned long' previously in the function, which will not hurt the other compilers.



 while((size = strtoul(buff, (char**)0, 16)) > 0)

------------------------------------^



can be changed to:



 while((size = strtoul(buff, NULL, 16))



Lutz

[pjot]

Thanks Lutz!



By the way: I tested some obscure functions on Tru64 like '(get-url)' and the UDP multicast, and these ran fine. Good news!



Peter