[freetds] tsql bug fixes that got lost between 0.64 and 0.65
ZIGLIO, Frediano, VF-IT
Frediano.Ziglio at vodafone.com
Fri Aug 25 02:28:01 EDT 2006
> On Aug 24, 3:14pm, entropy at freetds.org (entropy at freetds.org) wrote:
> -- Subject: Re: [freetds] tsql bug fixes that got lost
> between 0.64 and 0.65
> | Christos Zoulas wrote:
> | > Have you tried strace'ing/truss'ing tsql when it reads an
> input file?
> | > Using readline(3), it issues a read(2) per character, not
> counting the large
> | > number of failed ioctl(2)'s in the beginning.
> | Can't say that I have, but I'm not too surprised to hear
> that it could
> | be more efficient.
> | > We have the code in tsql to
> | > do the readline, why not just use it when we are not
> connected to the tty?
> | > This way, in the future, when readline(3) decides to do
> something else bogus
> | > with the input stream we are not going to be affected.
> | I don't think readline(3) just decided to do this.
> readline(3) has been
> | doing tab completion for as long as I can remember. I'm
> not aware of a
> | history of surprising behavior changes in readline(3). So,
> as for any
> | future unexpected behavior changes, I'm inclined to worry
> about it when
> | it happens instead of worrying about it now.
> Readline has been doing tab completion interactively for a long
> time. I don't know when it started doing this non-interactively.
> Anyway, I think that it is incredibly stupid for readline to work
> the way it does. What happens if I enter another editing character
> in a script, such as escape or control-p, or even meta-x? I don't
> know the answer, but my guess is that it will do the editing action.
> Also what happens when you enter text in a non ascii-c locale, and
> that character you enter happens to be bound to a readline function?
> Readline should recognize that it is not connected to a tty and
> turn character at a time input off and disable all the editing. It
> currently does not do that, so it is unsafe for processing input
> from files.
> | I personally don't like the idea of switching to a
> different readline(3)
> | implementation based on whether the terminal is a tty or
> not. It will
> | cause surprising and stupid behavior, like my SQL input
> | failing if it contains a line longer than 1024 characters.
> That is a problem with the current implementation of
> readline(3) in tsql,
> and can be easily fixed. On systems that have fgetln() use
> that instead,
> on systems that don't have it use:
Mmm.... why does fgetln.c do not nul terminate string. Your link point
to a BSD licensed file, not compatible with LGPL. Also we free string so
we would strdup the string.. I think I'll write a simpler realloc.
More information about the FreeTDS