Path: csiph.com!news.swapon.de!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: How to read a data file whose size is unknown in C? Date: Thu, 27 Aug 2015 09:18:08 -0700 Organization: None to speak of Lines: 98 Message-ID: References: <7b7a215a-b72a-48ba-bbdc-ddc22ad8c5b7@googlegroups.com> <271c85af-1480-4ee9-9102-9cab995c69a8@googlegroups.com> <629d31c7-2c94-48d3-b567-81fc041f7a5c@googlegroups.com> <55d78c72.14914812@news.xs4all.nl> <19583d3f-fb29-496b-8f45-df750bc222ac@googlegroups.com> <8357062a-f639-438a-83d1-2f0c7319b723@googlegroups.com> <1f1add4c-7e05-42c2-8223-389f85c9d107@googlegroups.com> <6c28b77b-4577-49af-b6ac-4fa1f3ed65ee@googlegroups.com> <55DE3D7B.7060706@verizon.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="945944de09706c9b4e29b53c9d2efdc2"; logging-data="29569"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19EgIZzwyxH3ytdufAJ9SIS" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:/2OXjGEWBSPewVhRdxd0KkeWWWY= sha1:QAoabl0GBoy8XEJQtVGSiTEhq0g= Xref: csiph.com comp.lang.c:68493 Malcolm McLean writes: > On Wednesday, August 26, 2015 at 11:28:28 PM UTC+1, James Kuyper wrote: >> On 08/26/2015 05:29 PM, David Kleinecke wrote: >> > Hum - and all over the world people thought that C was the "portable >> > high-level assembler" and used it as a portable high-level >> > assembler. That's all I intend - what people are already doing. >> > >> > Is there some specific reason why you object to that description of >> > C? >> >> Just because many people believe that nonsense doesn't make it true. >> Many people (Rick Hodgins being the most recent and egregious example I >> can think of) have posted complaints here about not being able to >> convince their C compilers to generate exactly the sequence of machine >> language instructions they want it to. If C were, in fact, a "portable >> high-level assembler", those objections would be entirely justified. And >> if it were true, the C language would have to have a very different >> structure. It doesn't provide any mechanism for specifying requirements >> that tight. >> > In fact it does. There's an asm keyword. Not in standard C, though the standard does mention it as a common extension. > Some compilers also allow you > to name variables, specify them "register", and force the named > register to be the resister assigned to that variable. Again, that's an extension, not part of C itself. [...] > Once upon a time i++ would generate "Increment i" and i += 1 would > generate "load x register with one, add x register to i". Do you have a citation for that? I wouldn't be surprised if that's correct for some early C compilers, but I also wouldn't be surprised if even the earliest compilers were able to generate the same code for `i++` and `i += 1`. > Those days > are long gone. However there's still a basic mapping from C constructs > to assembler constructs. The careful programmer has a pretty good idea > what code he'll generate. I consider myself a careful programmer, and 99% of the time I have no clue what CPU instructions will be generated for the C code I write. I don't always know which CPU it's going to run on. On rare occasions I might need to examine an assembly listing to track down a bug. > What really matters is the call interface. Now here, C is usually a > portable assembler. The standard doesn't actually require it, but > virtually every C compiler has a "calling convention" which allows > you to link with modules written in assembler. Typically it's > something like "first four parameters in registers, rest on stack" > (Clever programmers are careful to pass fewer than four parameters > in time critical code, for this reason). The existence of a common call interface used for C and assembly language doesn't imply that C is some kind of assembly language, any more than it implies that assembly language is really a dialect of C. > So you can write a module in assembler, and call a routine in C. > You can then write it in C for clarity (Heathfield's law). Once > it's right, you can replace all the C variables with assembler > register names. You can take out the for loops and put in gotos. > You can gradually bring it to a state where the C instructions > match one for one the assembly instructions, all the time testing > it against the clear version to make sure you haven't introduced > a mistake. Then it goes into assembler itself, often simply > wrapping with asm. > > So C is a portable assembler. That's the entire point and strength > of the language. There is a very stark difference between an assembly language and a non-assembly language. Assembly language programs specify CPU instructions. C programs specify run-time behavior (with a few extensions that let you exercise more control in limited circumstances). Certainly C is lower level than some other languages. C is semantically closer to assembly language than, say, Python is. But C and Python share the important characteristic that source code specifies behavior. I can imagine an actual "portable assembly language", in which you could write code that would specify instruction sequences while still being usable on multiple target systems. It would be difficult to specify the mapping, and the result would not look much like C. -- 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"