develooper Front page | perl.perl5.porters | Postings from October 2021

Re: Any thoughts to a NetWare upgrade?

Thread Previous
Nicholas Clark
October 5, 2021 08:24
Re: Any thoughts to a NetWare upgrade?
Message ID:
(To paraphrase a meme, "It's an old thread, but it checks out")

On Sun, Jun 24, 2018 at 01:48:52PM +1000, NormW wrote:

> GM,
> And thanks Craig for your reply.
> It would be a wrong to interpret my intent as saying the NetWare Clib
> doesn't work. The Novell people brought out LibC because it was more
> standards compliant for the time. The first releases of Perl on NetWare were
> Clib-based and I would guess they worked without issue.
> The major question I think is 'Is anyone working on the Clib version'?
> If people are working on the CLib version (patches,etc) and can build it,
> there is, I think, little point in cluttering up your source code. To see
> what I mean, will add here the diff from 5.8.4 which was taken against the
> original 5.8.4 release and a zip of patches that I use on current releases.
> Because LibC does things differently to Clib, the zip defines NETWARE,
> NETWARE_LIBC & NETWARE_CLIB which is likely not kind to your source (The
> NETWARE define in my patches is common to both). The red bits in the 5.8.4
> diff is what Novell removed from your source to change it to LibC, and used
> the NETWARE define for its new library. The 0 bytes diffs exist as I use a
> .bat file to apply, and there's fewer complaints from the bat file.

So, we now know the answer to 'Is anyone working on the Clib version'

No! Confidently no.

The build of the NetWare port in the core will have been broken in Sept 2009
by commit b0e687f777617f7f - if it wasn't already broken.

See for explanation.

Hence it's been broken for (at least) 12 years and no-one has reported this.

As I stress in that e-mail

    The port in NetWare/ has been broken since 2009 and no-one has noticed.

I like your phrasing "not kind to your source". That port isn't. Removing it
looks like this:

 131 files changed, 139 insertions(+), 19798 deletions(-)

There is stuff in how that port that just seems strange. For example

#  ifdef NETWARE
#    define CopFILE_set(c,pv)   ((c)->cop_file = savepv(pv))
#    define CopFILE_setn(c,pv,l)  ((c)->cop_file = savepvn((pv),(l)))
#  else
#    define CopFILE_set(c,pv)   ((c)->cop_file = savesharedpv(pv))
#    define CopFILE_setn(c,pv,l)  ((c)->cop_file = savesharedpvn((pv),(l)))
#  endif

which seems to be fallout from this:

/* Shared memory macros */
#ifdef NETWARE

#define PerlMemShared_malloc(size)                          \
        (*PL_Mem->pMalloc)(PL_Mem, (size))
#define PerlMemShared_realloc(buf, size)                    \
        (*PL_Mem->pRealloc)(PL_Mem, (buf), (size))
#define PerlMemShared_free(buf)                             \
        (*PL_Mem->pFree)(PL_Mem, (buf))
#define PerlMemShared_calloc(num, size)                     \
        (*PL_Mem->pCalloc)(PL_Mem, (num), (size))
#define PerlMemShared_get_lock()                            \
#define PerlMemShared_free_lock()                           \
#define PerlMemShared_is_locked()                           \


#define PerlMemShared_malloc(size)                          \
        (*PL_MemShared->pMalloc)(PL_MemShared, (size))
#define PerlMemShared_realloc(buf, size)                    \
        (*PL_MemShared->pRealloc)(PL_MemShared, (buf), (size))
#define PerlMemShared_free(buf)                             \
        (*PL_MemShared->pFree)(PL_MemShared, (buf))
#define PerlMemShared_calloc(num, size)                     \
        (*PL_MemShared->pCalloc)(PL_MemShared, (num), (size))
#define PerlMemShared_get_lock()                            \
#define PerlMemShared_free_lock()                           \
#define PerlMemShared_is_locked()                           \


Why was it done that way? How come it couldn't be done more simply by having
PL_Mem and PL_MemShared point to the same thing on Netware?

Seems that not enough review happened when the port was first worked on, to
try to get the changes and conditional code down when possible.

So, we'd love to integrate your porting work into the core, if it can be
done cleanly. We don't have access to NetWare, so we can't test whether
things like the code above could be simplified. Hence, the best way to do
this seems to be

1) We remove all the existing NetWare port
2) You locally put back the parts that you need (with one #define for your
3) Send us patches and we'll try to merge them

I appreciate that this might well mean that you're putting back stuff that
we just took out, and that seems like a bunch of code churn and makework
[and you'll hate me for suggesting this plan :-)]

But my hunch is that your much cleaner port doesn't need a bunch of the
work around that the original port did, but that also it won't break *with*
many of them. So taking the "minimise churn" approach of trying to figure
out what can be removed won't get as much cleanup. Also, it's going to
take longer. The workflow for it is

10  "I don't think we need this. Let's try removing it..."
20  run the full testsuite
30  did something new break?
      yes - revert
      no -  retain
40  GOTO 10

whereas the more brutal approach of "demolish and build afresh is" doesn't
need to run all the tests each time - one can iterate quite quickly with
miniperl and minitest until it that passes, and only then does one fill in
the gaps found by the rest of the code.

Also, we're intending to up the build requirements to the subset of C99
that is supported by current MSVC and the VMS vendor compiler
(gcc, clang and all the Unix vendor compilers we tested are not constraints)

Most importantly, this gets us

1) mixed declarations and code
2) 64 bit integer types (ie long long)

as best I can tell, OpenWatcom already supports what we need:

so I don't think that this will be a problem

MSVC doesn't support variable length arrays, so we won't be using them.

Nicholas Clark

Thread Previous Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About