* [9fans] APE printf difference @ 2008-07-06 22:03 Fernan Bolando 2008-07-06 22:14 ` erik quanstrom 0 siblings, 1 reply; 8+ messages in thread From: Fernan Bolando @ 2008-07-06 22:03 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [9fans] APE printf difference 2008-07-06 22:03 [9fans] APE printf difference Fernan Bolando @ 2008-07-06 22:14 ` erik quanstrom 2008-07-06 23:04 ` Charles Forsyth 0 siblings, 1 reply; 8+ messages in thread From: erik quanstrom @ 2008-07-06 22:14 UTC (permalink / raw) To: fernanbolando, 9fans > 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [9fans] APE printf difference 2008-07-06 22:14 ` erik quanstrom @ 2008-07-06 23:04 ` Charles Forsyth 2008-07-07 21:01 ` Pietro Gagliardi 0 siblings, 1 reply; 8+ messages in thread From: Charles Forsyth @ 2008-07-06 23:04 UTC (permalink / raw) To: 9fans >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. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [9fans] APE printf difference 2008-07-06 23:04 ` Charles Forsyth @ 2008-07-07 21:01 ` Pietro Gagliardi 2008-07-07 21:21 ` erik quanstrom 2008-07-07 23:02 ` Charles Forsyth 0 siblings, 2 replies; 8+ messages in thread From: Pietro Gagliardi @ 2008-07-07 21:01 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [9fans] APE printf difference 2008-07-07 21:01 ` Pietro Gagliardi @ 2008-07-07 21:21 ` erik quanstrom 2008-07-07 23:02 ` Charles Forsyth 1 sibling, 0 replies; 8+ messages in thread From: erik quanstrom @ 2008-07-07 21:21 UTC (permalink / raw) To: 9fans > 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [9fans] APE printf difference 2008-07-07 21:01 ` Pietro Gagliardi 2008-07-07 21:21 ` erik quanstrom @ 2008-07-07 23:02 ` Charles Forsyth 2008-07-08 0:07 ` a 1 sibling, 1 reply; 8+ messages in thread From: Charles Forsyth @ 2008-07-07 23:02 UTC (permalink / raw) To: 9fans "... 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? ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [9fans] APE printf difference 2008-07-07 23:02 ` Charles Forsyth @ 2008-07-08 0:07 ` a 2008-07-09 11:12 ` lucio 0 siblings, 1 reply; 8+ messages in thread From: a @ 2008-07-08 0:07 UTC (permalink / raw) To: 9fans 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [9fans] APE printf difference 2008-07-08 0:07 ` a @ 2008-07-09 11:12 ` lucio 0 siblings, 0 replies; 8+ messages in thread From: lucio @ 2008-07-09 11:12 UTC (permalink / raw) To: 9fans > 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2008-07-09 11:12 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2008-07-06 22:03 [9fans] APE printf difference Fernan Bolando 2008-07-06 22:14 ` erik quanstrom 2008-07-06 23:04 ` Charles Forsyth 2008-07-07 21:01 ` Pietro Gagliardi 2008-07-07 21:21 ` erik quanstrom 2008-07-07 23:02 ` Charles Forsyth 2008-07-08 0:07 ` a 2008-07-09 11:12 ` lucio
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).