Re: [sicsh-develop] sic: redir module

[Gary V. V. <ga...@or...>]

On Wed, Apr 05, 2000 at 11:20:41AM -0400, Ezra Peisach wrote:
> 
> I've started working on file redirection. (module redir.la)

Excellent!  Thankyou =)O|

You should add yourself to the AUTHORS file too methinks.

> Two issues:
> 
> All output is currently hodgepodge - individual modules use printf right now,
> errors are through the sic_result_... handler.

Indeed.  This does need some work, but I didn't think it through at
the time =(O|

> I will need to control the output...
> a) Should the modules be using sic_result_set/append for normal messages?
> b) If not, I need to provide a FILE * for these builtins to use for sending
> output. Should it be a global or a sicstate?
> 
> I prefer (a) - because then the I/O can happen at the top.
> But then there is the issue of stdout vs. stderr. Consider the unknown
> handler. What if we want the stdout to go one place and stderr another? This
> would imply (b) would be easier.

I nearly went for (a), but the problem here would be that perfectly
valid output might be generated deep within the call stack, and an
error (say at the end of a loop) that forces the stack to unwind (so
that the error is caught and displayed) would obliterate it.

After a bit more thought, I think the best solution is to add a stream
to the Sic structure and use that.  Ultimately, I plan to integrate my
snprintfv package (on my homepage) which would do the following:

    i)  add generalised streams so that we're not limited to FILE*
    ii) gives access to dynamically self allocating strings which are
        8-bit clean.
    iii) has all the frills of glibc printf and pals, plus a few more --
        (asprintf, vsprintf, dsprintf, %1$s format parsing) all of
        which can be used with impunity without worrying about providing
        fallback implementations for non-glibc targets.
       
You have three options at this point:

    i)  go ahead and add a FILE* stream for now so that you can keep
        going, and we'll worry about snprintfv later.
    ii) take a look at snprintfv and install it on your development box,
        and reference it as an external library for now.
    iii) take the bull by the horns and add snprintfv in a subdirectory,
       and make libsic dependent on it.

>       Ezra

Cheers,
	Gary.
-- 
  ___              _   ___   __              _ mailto:ga...@or...
 / __|__ _ _ ___ _| | / / | / /_ _ _  _ __ _| |_  __ _ ___       ga...@gn... 
| (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \      
 \___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/
home page:  /___/                      /___/                  gpg public key:
http://www.oranda.demon.co.uk           http://www.oranda.demon.co.uk/key.asc