[9fans] APE printf difference

[9fans] APE printf difference

[Fernan Bolando]

Hi

I am probably posting more noise, but shouldnt the code below print
the prompt first then ask for a char? It works fine under gcc.


#include <stdio.h>

int main()
{
	printf("\nprompt");
	getchar();
	return 0;
}

--
http://www.fernski.com

Re: [9fans] APE printf difference

[erik quanstrom]

> Hi
>
> I am probably posting more noise, but shouldnt the code below print
> the prompt first then ask for a char? It works fine under gcc.
>
>
> #include <stdio.h>
>
> int main()
> {
> 	printf("\nprompt");
> 	getchar();
> 	return 0;
> }

the output is buffered.  i don't see a requirment to flush
stdout or any other output stream in c99 or posix standard for
fgetc, though i may have missed something.  getchar is
defined in terms of fgetc.  i would think this code would
reliably do what you wish:

#include<stdio.h>
int
main(void)
{
	printf("\nprompt");
	fflush(stdout);
	getchar();
	return 0;
}

- erik

Re: [9fans] APE printf difference

[Charles Forsyth]

>i don't see a requirment to flush stdout or any other output stream in c99 ...

"As initially opened, the standard error stream is not fully buffered; the standard input and standard
output streams are fully buffered if and only if the stream can be determined not to refer
to an interactive device."

but "can be determined" is perhaps a weasel phrase. it's probably expected that the system can tell
the difference, but isatty() is a bit devious in the plan 9 world. more serious is that APE could face either way.
if it's trying to help portability in, it should have as many functions as possible, and those quite generous.
if it's trying to help portability out, it should be strict and emphasise all the little pockets of "undefined behaviour" or
"implementation-defined" behaviour, to get you to spell things out. if that's the case (and i think that's the design) you need the fflush.
if the former, you'd perhaps want _IOLBF if isatty(1) is true.

Re: [9fans] APE printf difference

[Pietro Gagliardi]

C89 does have such a requirement, in two places:

Section 5.1.2.3:
"...
- The input and output dynamics of interactive devices shall take
place as specified in 7.9.3. ... or line-buffered input appear as soon
as possible, to ensure that prompting messages actually appear prior
to a program waiting for input.
..."

Section 7.9.3:
"... Furthermore, characters are intended to be transmitted as a block
to the host environment when ... input is requested on an unbuffered
stream, or input is requested on a line buffered stream ..."

So there you go. I don't know about C99, but I do know POSIX/SUS are
designed to be aligned with standard C.

Pietro

Re: [9fans] APE printf difference

[erik quanstrom]

> So there you go. I don't know about C99, but I do know POSIX/SUS are
> designed to be aligned with standard C.

i think you're missing the bit where determining what
an interactive device is is not straightfoward, as forsyth
pointed out.  think of connecting to a shell on the other
end of a unix socket.  or #|.

if you really depend on the prompt being synchronous,
you'd better either use nonbuffered io or fflush before prompting.

this all is a good argument for plan 9's decoupling of the print
library from the buffered i/o library.

- erik

Re: [9fans] APE printf difference

[Charles Forsyth]

"... Furthermore, characters are intended to be transmitted as a block
to the host environment when ... input is requested on an unbuffered
stream, or input is requested on a line buffered stream ..."

that's true when a stream is established as _IONBF or _IOLBF,
so if you call setvbuf, that will be true.  the bit i quoted earlier dealt
with how the default i/o streams stdin/stdout/stderr were configured,
and that was not clear-cut, being conditional on whether the system
decided they were "interactive" or not, which seemed to be implementation-dependent
behaviour.  now, it might turn out to be straightforward to change APE to configure
the streams based on the guess made by isatty(), but that's why i asked
which way APE should face by default?  for import or export?
Trickey's short paper on APE touches on that, and i think an earlier
paper by Hume on Portability in the Research Unix environment was more
explicit.  in the past i relied on APE to check programs for good portability
when I developed on Plan 9 but supplied the programs to others to run on Unix, VMS and Windows.
perhaps now inward portability is more common, but should the older pedantry not be
available at all?

Re: [9fans] APE printf difference

[a]

This disparity comes up fairly often. As an example, some
folks have done a lot of good (in the sense of being useful)
work getting various GNU things working on Plan 9 as pre-
requisites for things they want. It'd be nice if these were
available as an "import package" for folks to use who just
want some random linux program.

The complete set of dependencies is obviously gigantic, ever-
growing, and infeasable, but getting some useful subset is
a different story. In fact, if you look through contrib (by
which I mean fgb's very nice packaging system), we already
have a nice subset.

Some folks doing this work - and more watching - have
argued that this should all be dumped into APE. I think this
would be bad. I've used APE for exprt as much as import
(although, honestly, I've gotten somewhat lazy recently and
have started making p9p a pre-requisite), and being able to
check code against a "least common denominator" is very
helpful. One might argue that APE's current denominator is
too low (some of the things we require defines for and treat
as extensions have since become incorporated into ANSI and
POSIX), but that's really an independent discussion. There
remains a real difference between ANSI/POSIX standards and
GNU (or whoever) random gunk.

APE's export filter is very useful, and would be missed, but
there's an equally valid import role that it isn't very good at
serving, in modern contexts. I'd rather see that broken out
into a distinct environment, say G(nu)APE.

Of course, back on the question which prompted all this,
there remains an interesting question: do we duplicate the
library, or have it behave differently depending on where
it's used? Adding stuff in for the import environment is
relatively easy (in terms of organization and conflicts), but
should our stdio library really need to know whether it's being
used for import or export?

Anthony

Re: [9fans] APE printf difference

[lucio]

> APE's export filter is very useful, and would be missed, but
> there's an equally valid import role that it isn't very good at
> serving, in modern contexts. I'd rather see that broken out
> into a distinct environment, say G(nu)APE.

Maybe a touch far-fetched, but could we not agree to use APE for
export and the GCC/G++ port for import?  Of course, mostly as a
principle and as focus, not as an obstacle.  If we accepted this as
the objective, more effort may go into making GCC/G++ viable.  I have
once again slipped back somewhat and I am not sure how easily I could
compute and submit the changes to the APE libraries and headers I
needed to apply to produce the GCC APE prerequisites.  It's on my TODO
list, but not a high priority.  Unfortunately, I need a clean
environment to reproduce the GCC port and that is pretty hard to
concoct for something that has few interested takers.

++L