Skip to Content.
Sympa Menu

freetds - Re: [freetds] [PATCH] VMS build update

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Frediano Ziglio <freddy77 AT gmail.com>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] [PATCH] VMS build update
  • Date: Tue, 15 Oct 2013 21:07:15 +0100

2013/10/15 Craig A. Berry <craigberry AT mac.com>:
>
> On Oct 14, 2013, at 12:57 AM, Frediano Ziglio <freddy77 AT gmail.com> wrote:
>
>> 2013/10/13 Craig A. Berry <craigberry AT mac.com>:
>>> Make the VMS-specific configuration and build procedures handle threads,
>>> plus admit to having some other things that we do have but weren't
>>> configuring for, such as clock_gettime(), socketpair(), getaddrinfo(),
>>> and stdio locking.
>>>
>>> The attached patch was created with git format-patch and should be
>>> applicable with git am. Or GNU patch -p1 for traditionalists.
>>>
>>
>> What can I say. Pushed!
>
> Many thanks.
>
>>> 6e3afa4d (Frediano Ziglio 2013-06-05 12:47:50 +0100 1127) i
>>> = fgetc(hostfile);
>>> 6e3afa4d (Frediano Ziglio 2013-06-05 12:47:50 +0100 1128)
>>> if (i == EOF)
>>> 6e3afa4d (Frediano Ziglio 2013-06-05 12:47:50 +0100 1129)
>>> return _bcp_check_eof(dbproc, hostfile, 0);
>>> 6e3afa4d (Frediano Ziglio 2013-06-05 12:47:50 +0100 1130)
>>> ungetc(i, hostfile);
>>>
>>
>> Well... this patch use some stdio extension to make read faster... but
>> fails on standard C calls ?? What a crazy world! It just try to detect
>> if we are at end of the file without removing a character!
>
>
> What you're doing is completely reasonable, but appears to trigger a pretty
> nasty bug in the C run-time where calling fgetc/ungetc corrupts the return
> value of a subsequent fread. Since FreeTDS always checks the return value
> of fread in _bcp_read_hostfile, it knows something is bonkers and bails out.
>
> I've documented what goes wrong with a simple reproducer at
> <https://sourceforge.net/p/vms-ports/tickets/72/>. Not sure what to do yet
> as a workaround. I guess we could skip the above if it's purely an
> optimization. Or I could try to implement my own ungetc by fiddling with
> the pointers in the stdio struct.
>

412737? Where this value came from?

Can you try the attached patch? It worked for me (or at least it
didn't break anything).

Frediano

Attachment: 0001-Detect-end-of-file-not-using-ungetc.patch
Description: Binary data




Archive powered by MHonArc 2.6.24.

Top of Page