[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 
> mysteriously 
> | 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:
> 
>     http://cvsweb.netbsd.org/bsdweb.cgi/src/tools/compat/fgetln.c
> 
> christos

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.

freddy77




More information about the FreeTDS mailing list