Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: "Craig A. Berry" <craigberry@nospam.mac.com>
Newsgroups: comp.os.vms
Subject: Re: FreeTDS port to VMS V9.x on x86?
Date: Fri, 6 Jun 2025 10:14:37 -0500
Organization: A noiseless patient Spider
Lines: 85
Message-ID: <101v0kt$2at4q$1@dont-email.me>
References: <101n7gq$4m9b$1@dont-email.me>
 <683f3086$0$693$14726298@news.sunsite.dk> <101ncau$57on$1@dont-email.me>
 <101nqij$9edo$1@dont-email.me> <101sb4a$1ioac$1@dont-email.me>
 <101shm9$1l3ag$1@dont-email.me> <101skdr$1lvhe$1@dont-email.me>
 <101t1fh$1op7a$1@dont-email.me> <101tglm$1s66m$1@dont-email.me>
 <101uodt$28rq1$1@dont-email.me> <101uuno$29494$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 06 Jun 2025 17:14:38 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="a074d8b5f374e6cf9b58b2be8b4a8635";
	logging-data="2454682"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/UBoJjqRZ/SUb99F+uaa0loG6N6gc7AAs="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:UaPnpXX9GPwiVqa/Jj4Xbeh2HGQ=
Content-Language: en-US
In-Reply-To: <101uuno$29494$1@dont-email.me>
Bytes: 4214


On 6/6/25 9:42 AM, Arne Vajhøj wrote:
> On 6/6/2025 8:54 AM, Craig A. Berry wrote:
>  > On 6/5/25 8:35 PM, Arne Vajhøj wrote:
>  >> On 6/5/2025 5:16 PM, Craig A. Berry wrote:
>  >>> On 6/5/25 12:33 PM, Simon Clubley wrote:
>  >>>> On 2025-06-05, Arne Vajhøj <arne@vajhoej.dk> wrote:
>  >>>>> And DBLIB.C contains:
>  >>>>>
>  >>>>> RETCODE
>  >>>>> dbfcmd(DBPROCESS * dbproc, const char *fmt, ...)
>  >>>>> {
> 
>  >>>>>       va_start(ap, fmt);
>  >>>>>       len = vasprintf(&s, fmt, ap);
>  >>>>>       va_end(ap);
> 
>  >> It is vasprintf that return -1.
>  >>
>  >> It happens with both normal build and /DEB/NOOPT.
>  >> I created a standalone example doing the same just without any FreeTDS.
>  >>
>  >> It works fine.
>  >> I must be missing something.
>  >
>  > Check for the line in your generated descrip.mms that starts with:
>  >
>  > VASPRINTFOBJ =
>  >
>  > If the right-hand side is empty, you are using the system-supplied
>  > vasprintf, which is what should happen.  If it's not empty, you are
>  > getting a replacement vasprintf() from FreeTDS, which in turn means the
>  > detection code in configure.com is not working right (unless you are on
>  > a version of VMS before vasprintf() was added to the CRTL).  Either
>  > should work in principle, but it could be one difference between your
>  > standalone test and your FreeTDS test.
> 
> Bingo.
> 
> $ diff descrip.mms
> ************
> File DKA0:[arne.freetds.freetds-1_5_2]descrip.mms;2
>    149   VASPRINTFOBJ =
>    150   STRTOK_ROBJ =
> ******
> File DKA0:[arne.freetds.freetds-1_5_2]descrip.mms;1
>    149   VASPRINTFOBJ = [.src.replacements]vasprintf$(OBJ),
>    150   STRTOK_ROBJ =
> ************
> 
> $ diff [.include]config.h
> ************
> File DKA0:[arne.freetds.freetds-1_5_2.include]config.h;2
>    234   #define HAVE_VASPRINTF 1
>    235
> ******
> File DKA0:[arne.freetds.freetds-1_5_2.include]config.h;1
>    234   #define HAVE_VASPRINTF 0
>    235
> ************
> 
> And now dbfcmd works.
> 
> Of course it does not explain why the replacement doesn't work.

Nor why the detection code doesn't correctly identify that vasprintf is
present.  That detection code has been there unchanged for 23 years:

https://github.com/FreeTDS/freetds/blob/a381342bbfccafc0aa9ed2376e38470907d53225/vms/configure.com#L267

#include <stdarg.h>
#include <stdio.h>
#include <stdlib.h>
int main()
{
char *ptr;
vasprintf(&ptr,"%d,%d",1,2);
exit(0);
}

But it isn't using va_start/va_end, which it surely should. My guess is
this worked by accident on pre-x86 but something tightened up on x86
that makes the vasprintf call fail and causes FreeTDS to use its
fallback implementation.  I'm without access at the moment so can't test
this theory out myself.