Thread

1. Re: ecpg is broken in current

   Tatsuo Ishii <t-ishii@sra.co.jp> — 2000-09-27T01:44:01Z

   > On Fri, Sep 22, 2000 at 03:31:59PM +0900, Tatsuo Ishii wrote:
   > > pgc.o(.text+0x582): undefined reference to `pg_mbcliplen'
   > > pgc.o(.text+0x953): undefined reference to `pg_mbcliplen'
   > > ...
   > > pg_mbcliplen cannot be used in the frontend. Remove them, please.
   > 
   > Is there any way to use a similar functionality in ecpg? I don't like to run
   > truncate the text too early.
   
   To truncate a mulbyte characters properly, you need to know what
   encoding is used for a .pgc file that ecpg about to process. Currently
   there is no mechanism in ecpg (and all other frontend) to know what
   encoding is used for the .pgc files. This is a tough problem...
   --
   Tatsuo Ishii
   
   

2. Re: ecpg is broken in current

   Christof Petig <christof.petig@wtal.de> — 2000-09-29T17:04:06Z

   Tatsuo Ishii wrote:
   
   > > On Fri, Sep 22, 2000 at 03:31:59PM +0900, Tatsuo Ishii wrote:
   > > > pgc.o(.text+0x582): undefined reference to `pg_mbcliplen'
   > > > pgc.o(.text+0x953): undefined reference to `pg_mbcliplen'
   > > > ...
   > > > pg_mbcliplen cannot be used in the frontend. Remove them, please.
   > >
   > > Is there any way to use a similar functionality in ecpg? I don't like to run
   > > truncate the text too early.
   >
   > To truncate a mulbyte characters properly, you need to know what
   > encoding is used for a .pgc file that ecpg about to process. Currently
   > there is no mechanism in ecpg (and all other frontend) to know what
   > encoding is used for the .pgc files. This is a tough problem...
   > --
   > Tatsuo Ishii
   
   I would recommend a command line option overriding an environment variable
   (fallback). Isn't there some LC_* indicating the default encoding.
   But on the other hand, compiling would most likely take place in 'C'.
   
   Christof