Re: FreeTDS port to VMS V9.x on x86?

On 7/3/2025 4:07 PM, Dan Cross wrote:

In article <1046hc5$62th$2@dont-email.me>,
Arne Vajhøj  <arne@vajhoej.dk> wrote:

On 7/3/2025 1:40 PM, Dan Cross wrote:

As the main logic is the same in each case (find out the buffer
size, allocate, and then assign and return), and the only real
difference is in finding out the buffer length, your code would
be more readable with some helper functions that you delegated
to.

>
As states in the comments then it was a design goal to have
simple code blocks - no nested if's, no functions - for a given
context just 1-10 lines of code.

 That's a bad design goal.
 This sort of organization leads to lots of duplication and tends
to produce code that is overly verbose and fragile, where one
section may be updated and the others skipped or missed.  A
little bit of duplication for the sake of comprehensibility is
ok, but this is excessive.

It is very easy to read this way.
Just scan sequentially down until one find the relevant
#if context and then read 1-10 lines sequentially.
No jumping up and down.

You refer to `_PATH_DEVNULL` but do not `#include <paths.h>`, as
required by POSIX.

>
This must support non *nix systems (as an example
VMS !!) - config.h is expected to provide that with the rest.

 If copyright dates are anything to judge by, `<paths.h>` has
been a thing since 1989, but I was wrong in that it is not
actually in POSIX: it is a BSD extension, though common.

This code should also work on non-*nix. It does not matter
if all or most *nix has had it since 1989.

In general, it is good practice and good hygiene in C programs
to `#include` the header files that are documented to define the
symbols and types that you use in your program, instead of
relying on transitive includes to populate things ambiantly via
e.g. `config.h`.
 Regardless, in that case, you shouldn't use `_PATH_DEVNULL`.
Note the leading `_`: that signifies a reserved identifier,
which is not something you should be defining yourself.  If you
want to punt this to e.g. config.h, better would be to define a
new name (say, `TDS_PATH_DEVNULL`) and use that.

This has to fit into an existing project that has its
way to setup things.
I also think that its way makes sense. It would not be good
to start putting OS specific includes/defines into lots
of C files. That is what the configure process is supposed to
handle.
Arne