🚀 go-pugleaf

Well, got into a discussion with the posting program, and lost both proper
title and concluding remarks from previous message.

Anyway, we know how to fix this particular problem.

My other comment was on unix gruish-type responses, of which I am
probably somewhat guilty myself.

In this case, the problem didn't turn out to be the char-int confusion 
the putc-getc twins have for many newcomers, and it's true actually
that it shouldn't have.

Nontheless, I think it's very important that this usage and the reasons 
be well understood, not glossed over with the 'most C compilers promote
passed char arguments to ints anyway'.  VERY bad practice to depend on
anything of the sort; it's the sort of foolishness that makes people
hate C and its programmers.  And it's completely un-necessary.  
Makes a lot more sense just to do things right.

When you get to C++, the world changes again, and though some
promotions remain, and others are added, there is a real mire pit
waiting if you try to make things work by such 'inner' details.
Trust me on this one.

Declare and use data types consistently, is an easy and enjoyable way.


The other possibility in this case was that fflush () might have been
needed on stdout to get the output.  I missed this.  It turns out not
to be necessary in LightSpeed C, since both stdout and stderr are
initially declared with non-buffered output (though one may easily
change this).  In most Unix environments, stdout at least is buffered,
though paradoxically printf may call fflush and mask this, and it would 
be necessary, with fputc, to call fflush.

See the moral of the story?   If Lightspeed followed one Unix version
in a perfect way (maybe it does), we still wouldn't 'know' the
answers.  I was at fault to react with too much assurance, myself.


Clive Steward