Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #73676 > unrolled thread
| Started by | Alla _ <modelling.data@gmail.com> |
|---|---|
| First post | 2015-10-24 02:17 -0700 |
| Last post | 2015-10-27 13:18 -0700 |
| Articles | 6 on this page of 86 — 18 participants |
Back to article view | Back to comp.lang.c
Issues with setting variables to true or false: how does the compiler understands it Alla _ <modelling.data@gmail.com> - 2015-10-24 02:17 -0700
Issues with setting variables to true or false: how does the compiler understands it asetofsymbols@gmail.com - 2015-10-24 03:29 -0700
Re: Issues with setting variables to true or false: how does the compiler understands it Alla _ <modelling.data@gmail.com> - 2015-10-24 03:38 -0700
Re: Issues with setting variables to true or false: how does the compiler understands it Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-24 04:30 -0700
Re: Issues with setting variables to true or false: how does the compiler understands it gazelle@shell.xmission.com (Kenny McCormack) - 2015-10-24 12:04 +0000
Issues with setting variables to true or false: how does the compiler understands it asetofsymbols@gmail.com - 2015-10-24 04:59 -0700
Re: Issues with setting variables to true or false: how does the compiler understands it Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-24 14:28 +0100
Re: Issues with setting variables to true or false: how does the compiler understands it asetofsymbols@gmail.com - 2015-10-24 07:26 -0700
Re: Issues with setting variables to true or false: how does the compiler understands it Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-24 17:06 +0100
Re: Issues with setting variables to true or false: how does the compiler understands it James Kuyper <jameskuyper@verizon.net> - 2015-10-24 11:56 -0400
Re: Issues with setting variables to true or false: how does the compiler understands it Keith Thompson <kst-u@mib.org> - 2015-10-24 12:02 -0700
Re: Issues with setting variables to true or false: how does the compiler understands it supercat@casperkitty.com - 2015-10-24 15:45 -0700
Re: Issues with setting variables to true or false: how does the compiler understands it Keith Thompson <kst-u@mib.org> - 2015-10-24 16:28 -0700
Re: Issues with setting variables to true or false: how does the compiler understands it Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-24 16:44 -0700
Re: Issues with setting variables to true or false: how does the compiler understands it supercat@casperkitty.com - 2015-10-24 19:34 -0700
Re: Issues with setting variables to true or false: how does the compiler understands it supercat@casperkitty.com - 2015-10-24 19:30 -0700
Re: Issues with setting variables to true or false: how does the compiler understands it Keith Thompson <kst-u@mib.org> - 2015-10-24 20:33 -0700
Re: Issues with setting variables to true or false: how does the compiler understands it Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-28 11:16 -0700
Re: Issues with setting variables to true or false: how does the compiler understands it Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-10-28 15:12 -0400
Re: Issues with setting variables to true or false: how does the compiler understands it Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-29 12:18 +0000
Re: Issues with setting variables to true or false: how does the compiler understands it raltbos@xs4all.nl (Richard Bos) - 2015-10-29 21:51 +0000
Re: Issues with setting variables to true or false: how does the compiler understands it Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-30 08:38 -0700
Re: Issues with setting variables to true or false: how does the compiler understands it Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-30 05:34 -0700
Re: Issues with setting variables to true or false: how does the compiler understands it Keith Thompson <kst-u@mib.org> - 2015-10-28 14:08 -0700
Re: Issues with setting variables to true or false: how does the compiler understands it Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-30 06:14 -0700
Re: Issues with setting variables to true or false: how does the compiler understands it glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-28 21:50 +0000
Re: Issues with setting variables to true or false: how does the compiler understands it supercat@casperkitty.com - 2015-10-28 15:08 -0700
Re: Issues with setting variables to true or false: how does the compiler understands it glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-28 22:47 +0000
Re: Issues with setting variables to true or false: how does the compiler understands it Robert Wessel <robertwessel2@yahoo.com> - 2015-10-28 18:35 -0500
Re: Issues with setting variables to true or false: how does the compiler understands it supercat@casperkitty.com - 2015-10-28 18:12 -0700
Re: Issues with setting variables to true or false: how does the compiler understands it glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-29 01:35 +0000
Re: Issues with setting variables to true or false: how does the compiler understands it Robert Wessel <robertwessel2@yahoo.com> - 2015-10-28 21:12 -0500
Re: Issues with setting variables to true or false: how does the compiler understands it supercat@casperkitty.com - 2015-10-28 19:52 -0700
Re: Issues with setting variables to true or false: how does the compiler understands it supercat@casperkitty.com - 2015-10-28 18:01 -0700
Re: Issues with setting variables to true or false: how does the compiler understands it Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-30 03:47 -0700
Re: Issues with setting variables to true or false: how does the compiler understands it Barry Schwarz <schwarzb@dqel.com> - 2015-10-24 09:54 -0700
Re: Issues with setting variables to true or false: how does the compiler understands it Keith Thompson <kst-u@mib.org> - 2015-10-24 12:13 -0700
Re: Issues with setting variables to true or false: how does the compiler understands it Richard Heathfield <rjh@cpax.org.uk> - 2015-10-24 21:50 +0100
Re: Issues with setting variables to true or false: how does the compiler understands it Alla _ <modelling.data@gmail.com> - 2015-10-25 04:04 -0700
Re: Issues with setting variables to true or false: how does the compiler understands it Barry Schwarz <schwarzb@dqel.com> - 2015-10-25 08:32 -0700
Re: Issues with setting variables to true or false: how does the compiler understands it Richard Heathfield <rjh@cpax.org.uk> - 2015-10-25 18:19 +0000
Re: Issues with setting variables to true or false: how does the compiler understands it Alla _ <modelling.data@gmail.com> - 2015-10-25 11:30 -0700
Re: Issues with setting variables to true or false: how does the compiler understands it Richard Heathfield <rjh@cpax.org.uk> - 2015-10-25 18:56 +0000
Re: Issues with setting variables to true or false: how does the compiler understands it Alla _ <modelling.data@gmail.com> - 2015-10-25 20:59 -0700
Re: Issues with setting variables to true or false: how does the compiler understands it Anand Hariharan <mailto.anand.hariharan@gmail.com> - 2015-10-25 21:49 -0700
Re: Issues with setting variables to true or false: how does the compiler understands it Richard Heathfield <rjh@cpax.org.uk> - 2015-10-26 08:10 +0000
Re: Issues with setting variables to true or false: how does the compiler understands it Anand Hariharan <mailto.anand.hariharan@gmail.com> - 2015-10-26 16:05 -0700
Re: Issues with setting variables to true or false: how does the compiler understands it Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-27 00:34 +0000
Re: Issues with setting variables to true or false: how does the compiler understands it Keith Thompson <kst-u@mib.org> - 2015-10-27 09:04 -0700
Re: Issues with setting variables to true or false: how does the compiler understands it Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-27 21:24 +0000
Re: Issues with setting variables to true or false: how does the compiler understands it Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-10-26 18:16 -0700
Re: Issues with setting variables to true or false: how does the compiler understands it Richard Heathfield <rjh@cpax.org.uk> - 2015-10-27 02:33 +0000
Re: Issues with setting variables to true or false: how does the compiler understands it Keith Thompson <kst-u@mib.org> - 2015-10-27 09:08 -0700
Re: Issues with setting variables to true or false: how does the compiler understands it Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-26 11:22 +0000
Re: Issues with setting variables to true or false: how does the compiler understands it Richard Heathfield <rjh@cpax.org.uk> - 2015-10-26 11:35 +0000
Re: Issues with setting variables to true or false: how does the compiler understands it Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-26 17:00 +0000
Re: Issues with setting variables to true or false: how does the compiler understands it Richard Heathfield <rjh@cpax.org.uk> - 2015-10-26 17:59 +0000
Re: Issues with setting variables to true or false: how does the compiler understands it Keith Thompson <kst-u@mib.org> - 2015-10-26 07:55 -0700
Re: Issues with setting variables to true or false: how does the compiler understands it Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-26 17:06 +0000
Re: Issues with setting variables to true or false: how does the compiler understands it supercat@casperkitty.com - 2015-10-26 10:56 -0700
Re: Issues with setting variables to true or false: how does the compiler understands it glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-26 20:14 +0000
Re: Issues with setting variables to true or false: how does the compiler understands it Keith Thompson <kst-u@mib.org> - 2015-10-26 17:09 -0700
Re: Issues with setting variables to true or false: how does the compiler understands it Bartc <bc@freeuk.com> - 2015-10-26 23:39 +0000
Re: Issues with setting variables to true or false: how does the compiler understands it Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-27 12:31 +0000
Re: Issues with setting variables to true or false: how does the compiler understands it Richard Heathfield <rjh@cpax.org.uk> - 2015-10-27 12:45 +0000
Re: Issues with setting variables to true or false: how does the compiler understands it Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-27 13:24 +0000
Re: Issues with setting variables to true or false: how does the compiler understands it Richard Heathfield <rjh@cpax.org.uk> - 2015-10-27 13:41 +0000
Re: Issues with setting variables to true or false: how does the compiler understands it Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-27 19:43 +0000
Re: Issues with setting variables to true or false: how does the compiler understands it Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-27 19:47 +0000
Re: Issues with setting variables to true or false: how does the compiler understands it Bartc <bc@freeuk.com> - 2015-10-27 13:20 +0000
Re: Issues with setting variables to true or false: how does the compiler understands it Richard Heathfield <rjh@cpax.org.uk> - 2015-10-27 13:28 +0000
Re: Issues with setting variables to true or false: how does the compiler understands it Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-10-27 13:54 +0000
Re: Issues with setting variables to true or false: how does the compiler understands it supercat@casperkitty.com - 2015-10-27 07:51 -0700
Re: Issues with setting variables to true or false: how does the compiler understands it Bartc <bc@freeuk.com> - 2015-10-27 16:46 +0000
Re: Issues with setting variables to true or false: how does the compiler understands it supercat@casperkitty.com - 2015-10-27 10:52 -0700
Re: Issues with setting variables to true or false: how does the compiler understands it Bartc <bc@freeuk.com> - 2015-10-27 18:51 +0000
Re: Issues with setting variables to true or false: how does the compiler understands it supercat@casperkitty.com - 2015-10-27 12:17 -0700
Re: Issues with setting variables to true or false: how does the compiler understands it Bartc <bc@freeuk.com> - 2015-10-27 19:34 +0000
Re: Issues with setting variables to true or false: how does the compiler understands it supercat@casperkitty.com - 2015-10-27 13:10 -0700
Re: Issues with setting variables to true or false: how does the compiler understands it Keith Thompson <kst-u@mib.org> - 2015-10-27 13:41 -0700
Re: Issues with setting variables to true or false: how does the compiler understands it Bartc <bc@freeuk.com> - 2015-10-27 23:11 +0000
Re: Issues with setting variables to true or false: how does the compiler understands it Keith Thompson <kst-u@mib.org> - 2015-10-27 19:02 -0700
Re: Issues with setting variables to true or false: how does the compiler understands it gazelle@shell.xmission.com (Kenny McCormack) - 2015-10-28 07:09 +0000
Re: Issues with setting variables to true or false: how does the compiler understands it Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-10-28 11:27 +0000
Re: Issues with setting variables to true or false: how does the compiler understands it Keith Thompson <kst-u@mib.org> - 2015-10-27 12:27 -0700
Re: Issues with setting variables to true or false: how does the compiler understands it supercat@casperkitty.com - 2015-10-27 13:18 -0700
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-10-27 23:11 +0000 |
| Message-ID | <n0p065$4de$1@dont-email.me> |
| In reply to | #74005 |
On 27/10/2015 20:10, supercat@casperkitty.com wrote: > On Tuesday, October 27, 2015 at 2:34:24 PM UTC-5, Bart wrote: >> Then it would be a binary file IMO. You have to draw the line somewhere. > > What exactly constitutes a "text" file, and what is the basis for limiting > things to that? What exactly is a "binary" file then, if a text can file can contain pretty much anything? It would be odd to define a text file as a file of binary data of any bytes from 0 to 255 - except 13, 10 or 13 and 10 used to provide arbitrary partitioning into 'lines'. What exactly would you do anyway with a file containing lines that are just different length sequences of zero bytes? How would you represent each line of 'text' in a C program? It becomes nonsensical. I expect a text file to consist of bytes representing printable characters from 32 to 127 (above that, you need to start thinking about character sets more carefully). Plus control characters such as cr, lf and tab. Anything else, especially nulls, are likely to screw things up. > At least in the MS-DOS world it was hardly uncommon to have files which > contain mostly printable characters separated by newlines but also contain > a few printer-setup codes, word-processor formatting codes, etc. There's > no particular reason something like a "grep" utility shouldn't be usable > with such files. Because we've moved on. The word processor should decide whether it wants to use a human readable text format, in which case any special data should be printable, or switch to binary format, not something which is neither one nor the other. > A lot of programs keep track of string lengths and then use memcpy/memmove > rather than str* functions, and thus would have no reason to care about > any zero bytes that might appear within lines. fgets() puts a trailing nul at the end of the buffer; what's the purpose of that? >> (And a file that might have null characters as data, is liable to want >> to use codes 13, 10 and 26 as data too!) > > If a "grep" utility sees a line break where there isn't really supposed to > be one, that's often less of a problem than having it be blind to anything > on a line that follows a NUL. Code 1A is a bit of a nuisance, but I've > seen more printer setup strings that use NUL than that use 1A. Then that's binary data and not text. It would be difficult to represent a string of control codes anyway; and how would you edit them? -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-10-27 19:02 -0700 |
| Message-ID | <ln7fm7da26.fsf@kst-u.example.com> |
| In reply to | #74026 |
Bartc <bc@freeuk.com> writes:
> On 27/10/2015 20:10, supercat@casperkitty.com wrote:
[...]
>> If a "grep" utility sees a line break where there isn't really supposed to
>> be one, that's often less of a problem than having it be blind to anything
>> on a line that follows a NUL. Code 1A is a bit of a nuisance, but I've
>> seen more printer setup strings that use NUL than that use 1A.
>
> Then that's binary data and not text. It would be difficult to represent
> a string of control codes anyway; and how would you edit them?
Many editors (including both vim and emacs) are quite capable of editing
files containing non-printable characters.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
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"
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2015-10-28 07:09 +0000 |
| Message-ID | <n0psar$2r7$2@news.xmission.com> |
| In reply to | #74031 |
In article <ln7fm7da26.fsf@kst-u.example.com>, Keith Thompson <kst-u@mib.org> wrote: >Bartc <bc@freeuk.com> writes: >> On 27/10/2015 20:10, supercat@casperkitty.com wrote: >[...] >>> If a "grep" utility sees a line break where there isn't really supposed to >>> be one, that's often less of a problem than having it be blind to anything >>> on a line that follows a NUL. Code 1A is a bit of a nuisance, but I've >>> seen more printer setup strings that use NUL than that use 1A. >> >> Then that's binary data and not text. It would be difficult to represent >> a string of control codes anyway; and how would you edit them? > >Many editors (including both vim and emacs) are quite capable of editing >files containing non-printable characters. Completely off-topic. There's nothing in any of the various C standards documents that even require the existence of anything resembling an "editor". -- Those on the right constantly remind us that America is not a democracy; now they claim that Obama is a threat to democracy.
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2015-10-28 11:27 +0000 |
| Message-ID | <slrnn31c95.5q5.grahn+nntp@frailea.sa.invalid> |
| In reply to | #74026 |
On Tue, 2015-10-27, Bartc wrote: > On 27/10/2015 20:10, supercat@casperkitty.com wrote: >> On Tuesday, October 27, 2015 at 2:34:24 PM UTC-5, Bart wrote: >>> Then it would be a binary file IMO. You have to draw the line somewhere. >> >> What exactly constitutes a "text" file, and what is the basis for limiting >> things to that? ... > I expect a text file to consist of bytes representing printable > characters from 32 to 127 (above that, you need to start thinking about > character sets more carefully). Yes. However, if you look at utf-8, it was designed so that a program could read an utf-8 text file the way it had always read text files, and only end up with extra "garbage" characters outside ASCII. No \0, \n or any other ASCII characters would seem to appear. The design of utf-8 is perhaps in itself a hint about the definition of "text file" ... /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-10-27 12:27 -0700 |
| Message-ID | <lnoafkcdt7.fsf@kst-u.example.com> |
| In reply to | #73963 |
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 <http://www.ghoti.net/~kst>
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"
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2015-10-27 13:18 -0700 |
| Message-ID | <dd96df1f-6e22-4dc4-b738-f7bf4d03798c@googlegroups.com> |
| In reply to | #73998 |
On Tuesday, October 27, 2015 at 2:27:25 PM UTC-5, Keith Thompson wrote: > supercat writes: > > 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. I suppose "refusal" was too strong a term, since I don't know that it was ever formally proposed, but I guess I'd be amazed if nobody proposed such a thing, given the common need for interactive programs and the common ability of systems to support such. I recall it being a perennial topic on c.l.c in the 1990s. If memory serves, doing it in Unix requires a sequence of ioctl calls that doesn't behave the same as e.g. on typical MS-DOS compilers (which often include a getch() function that behaves in non-buffered fashion). I appreciate, moreso perhaps than most, the need to allow C to be used as a language even on platforms which can't support all of the abilities one might like, but at the same time it would seem that if most platforms that run C have an ability which many programs need, it would be helpful to have the language standard indicate a standard means via which platforms with that ability should expose it to the programmer.
[toc] | [prev] | [standalone]
Page 5 of 5 — ← Prev page 1 2 3 4 [5]
Back to top | Article view | comp.lang.c
csiph-web