Path: csiph.com!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: Issues with setting variables to true or false: how does the compiler understands it Date: Tue, 27 Oct 2015 12:27:16 -0700 Organization: None to speak of Lines: 56 Message-ID: References: <75tp2bt23h0o4e81r8j4pvf0aqpafc5kis@4ax.com> <87si4wifhk.fsf@bsb.me.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="945944de09706c9b4e29b53c9d2efdc2"; logging-data="12720"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/n6lmcSHgytkoaSHYx/Or2" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:DdGF8xcBfdbrymXNALIwqSkoJwM= sha1:/pJfiYuAmGLrOABz23pLeAtFfRk= Xref: csiph.com comp.lang.c:73998 supercat@casperkitty.com writes: [...] > I really wish someone would standardize a line input function which would > return either the number of characters received or a one-past pointer for > the received data. On many platforms, fgets() is faster than anything that > can be synthesized using fgetc(), but having to search for and eliminate > the newline character is a major nuisance; fgets() also has no way of > handling inputs which contain embedded zero bytes. Someone has. POSIX defines a getline function: http://pubs.opengroup.org/onlinepubs/9699919799/functions/getdelim.html I haven't used it myself, but it returns the number of characters copied into the buffer. Even if that's not available, I'd call it a minor nuisance, not a major one. fgets(line, sizeof line, stdin); char *nl = strchr(line, '\n'); if (nl != NULL) *nl = '\0'; (Yes, it's more code to write. Yes, re-scanning the string is wasteful -- but likely to be some orders of magnitude faster than reading the line in the first place.) And you don't always *want* to clobber the newline: fgets(line, sizeof line, stdin); /* ... */ fputs(line, stdout); Finally, I'm skeptical that fgets() is typically going to be much faster than a similar user function that calls fgetc(). The fgetc() function itself is typically quite fast when it's able to read input that's already been buffered, which is the typical case. > Incidentally, I am also somewhat puzzled at the refusal of the Committee to > recognize any standard means of requesting raw keyboard input. I know that > some platforms cannot support raw interactive I/O, but it is a sufficiently > common feature that there should be a standardized means of requesting it > on platforms that can support it (and having those that cannot support it > report that fact). The word "refusal" implies that somebody has requested it and they've turned it down. That may well be the case, but I haven't heard of such a proposal. [...] -- Keith Thompson (The_Other_Keith) kst-u@mib.org Working, but not speaking, for JetHead Development, Inc. "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"