Dear all,
        I do apologize for my inactivity but some health problem has
"distracted" me from the computer. Hopefully I should be able to come back
fully operative pretty soon.

First of all I would like to thank Gustav for his work.

Secondly, it seems to me there are two major activities going on at the
moment, I do not know how to call them:

1. call cleanup / consolidation  - I would call this "baseline"
2. discussion/work on new features    - I would call this "new developments"

Perhaps we should extend the baseline activity to all modules that could be
possibly needed by an OpenACS application, e.g. on top the standard ones
also modules like nsoracle, nsopenssl, nsldap and so on.... what do you
think? 

Wouldn't also make sense to work first on this consolidated and extended
baseline, before actually concentrating/working on new developments?

Thanks a lot,
Maurizio



-----Original Message-----
From: Gustaf Neumann [mailto:neum...@wu.ac.at] 
Sent: 26 October 2012 21:12
To: Navidevel
Subject: [naviserver-devel] code cleanup

Dear friends,

Over the last days i did some cleanup that i have just committed with one
changeset to bitbucket. With these changes, naviserver still compiles with
"clang -Wall -pedantic", and passes all regression tests. Furthermore, it
compiles but as well with Microsoft Visual Studio 11 without warning on most
files (still things to do, such as bind for udp sockets, pread emulation,
read-operations in the spooler, ...; just did nsd 
+ nsthread). Most likely the visual studio port needs more
still more work, i did not manage to link with whatever
tcl8.5.12 produces (it looks for a tcl84t.lib, which is not produced per
default from tcl, most likely, one needs more setup-magic from Maurizio). I
have used Maurizio's project files, and added essentially the flags
_CRT_SECURE_NO_WARNINGS and _CRT_NONSTDC_NO_DEPRECATE.

The huge number of casts from Maurizio's first attempt are not needed (e.g.
assigning void* to a typed pointer, such as the results of the *alloc*
functions. However, it complained about many of the size_t assignments,
which convinced me to proceed this way.

The changes are:

- use size_t, ssize_t, off_t wherever appropriate (sometimes dangerous, when
negative values are used for sizes, or  when e.g. Tcl_GetWideIntFromObj() is
used; i tried to be conservative in such cases)

- push casts to "int" as far as possible down the code (e.g. 
down to Tcl_* functions accepting sizes, but defined with "int", such as
Tcl_WriteChars, Tcl_NewStringObj,
Tcl_NewByteArrayObj)

- be more careful on redefining macros (MSC seems a moving
target)

- provide base definition for inttypes for MSC WIN32 and WIN64

- use NS_SOCKET instead of SOCKET (which is defined under Windows). We
should stick with macros in our own namespace whenever possible.

- added the project files and the solution file for visual studio (without
the SQL Server file containing the configuration state, which is 35MB)

As far i can tell, everything works fine under Linux and Mac OS X, but i
certainly can't exclude some sign mismatches on seldomly used paths.

-gustaf neumann


----------------------------------------------------------------------------
--
The Windows 8 Center
In partnership with Sourceforge
Your idea - your app - 30 days. Get started!
http://windows8center.sourceforge.net/
what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/
_______________________________________________
naviserver-devel mailing list
naviserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/naviserver-devel


------------------------------------------------------------------------------
WINDOWS 8 is here. 
Millions of people.  Your app in 30 days.
Visit The Windows 8 Center at Sourceforge for all your go to resources.
http://windows8center.sourceforge.net/
join-generation-app-and-make-money-coding-fast/
_______________________________________________
naviserver-devel mailing list
naviserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/naviserver-devel

Reply via email to