FreeTDS Development Group

["Lowden, James K" <LowdenJK AT bernstein.com>]

> From: Frediano Ziglio [mailto:freddyz77 AT tin.it]
> Sent: August 5, 2003 2:01 AM
> Il mar, 2003-08-05 alle 06:31, Craig A. Berry ha scritto:
> > At 11:57 PM -0400 8/4/03, James K. Lowden wrote:
>
> > > On some multithreaded platforms, errno is
> > > actually a macro to a function call (which prevents 
> > > assignment, but allows typical use). 
> > 
> > C99 requires errno to be a "modifiable lvalue," but it also 
> > says in a
> > footnote, "The macro errno need not be the identifier of an object.
> > It might expand to a modifiable lvalue resulting from a 
> > function call (for example, *errno())."
> > 
> > So I think everything about your statement is correct except
> > "prevents assignment"; a decent implementation is going to call a
> > function that implements an assignable errno on a per-thread basis.
> 
> IMHO if errno is not thread-safe iconv is not too...
> I think our tds_iconv should return error instead of leave 
> caller check errno.  

tds_iconv() mimics iconv(3).  I think that's a good design choice.  The code
that uses it is easy to understand and has very little wasted motion.  

errno is widely used by system calls, and appears pretty often in our code:

$ grep errno src/*/*.c |wc -l
      48

The folks who designed the iconv interface decided that it returns "number
of irreversible conversions performed" and sets errno.  I think they knew
what they were doing.  Meanwhile, all tds_iconv() is doing is acting on and
reflecting what it hears from iconv().  It's pointless to change how
tds_iconv() handles errno unless you have a plan for the other 47 cases.  

> Another issue about iconv. I'm going to change iconv stuff using an
> abstract interface... 

You mean something along the lines of funopen(3), with I/O function pointers
instead of buffers?  That might be OK.  I looked at it, but I didn't see
much leverage.  Everything ultimately comes down to translating buffers, and
not all the data are subject to conversion.  Something has to interpret the
data stream and separate the character data from nonchar data, so there's no
notion of plugging iconv() into a socket.  

Could you give me a clearer idea of what you have in mind?

--jkl
-----------------------------------------
The information contained in this transmission may contain privileged and 
confidential information and is intended only for the use of the person(s) 
named above. If you are not the intended recipient, or an employee or agent 
responsible for delivering this message to the intended recipient, any 
review, dissemination, distribution or duplication of this communication is 
strictly prohibited. If you are not the intended recipient, please contact 
the sender immediately by reply e-mail and destroy all copies of the original 
message. Please note that we do not accept account orders and/or instructions 
by e-mail, and therefore will not be responsible for carrying out such orders 
and/or instructions.