I haven't a hope in hell of working out what it's supposed to do, but when I compile and run it on my Pi it prints out "0.250". Mind you, it does generate loads of compiler warnings so I bet it's not doing what it was intended to do, even though it compiles.
It's in K&R C rather than ANSI C so it needs some fiddling with compiler options to make it compile correctly on a modern system. It calculates pi by measuring the area of the crude circle drawn in the source code.
It's not that hard.
The first line defines the symbol "_" to expand to the second part. We'll come back to that later.
The next line defines the global variables 'F' and 'OO', which are both initialized to 0 (written as "00", but that's the same thing), and then defines the main function.
The main function calls the function F_OO, then prints the result of multiplying 4 by -F divided by OO divided (again) by OO. The dot beween the 4 and the * turns the 4 into a floating-point number, which is necessary for the printf format, but is otherwise uninteresting.
The function F_OO simply has several lines of the _ and - characters. The latter is simply retained; the former gets expanded because it's a macro.
_-_ would turn into:
|-----macro----| |-----macro----|
-F
Ahem A Rivet's Shot writes: [...]
Quibble: No, strtok() doesn't return an array of pointers (for the simple reason that a C function cannot return an array value). It returns a single string pointer on each call. You have to call it multiple times to get pointers to all the tokens. It uses its own static memory to keep track.
Incidentally, I don't believe strtok is used to turn a string into argc and argv. That's handled by the shell, and tokenizing on white space doesn't work. For example:
echo arg1 'arg 2'
passes two arguments to echo, not three. (bash does use strtok in some places; I'm not sure just how it's used.)
[followups to comp.lang.c]Pascal,
So I may take you agree that such a nul character did indeed get send and that your statement that its not is false ? Thank you.
For /certain types/ of old machines ? True.
For all other machines, including most, if not all of the computers in the last decennia or two ? They mostly do not even recogise that character and handle it the same as the nul character: displaying some kind of made-up glyph or simply ignoring it (as was the case for that teletype I spoke of). In other words: wrong again.
And than how would you than send a zero-length string ? Yep, thats right: By sending one-or-more nul bytes/chars (depending on the size of the character-count field). In other words, such a nul /does/ gets send in such a situation.
And /these/ nul characters do /not/ get ignored on reception in any way.
Which means that your "But it was entirely ignored (had to be), by the receiving device." is false too.
Bottom line: You have been making blanket statements on a wide range of machines and usages, without even considering that even their functioning/usage is uncomparable.
Regards, Rudy Wieser
[] [] [] I'm sorry, but the above is why this sort of discussion never ends. When someone is intimately familiar with the syntax of a language, the meaning/functioning of a line like the above - or, say, in C, something like *a++=b(&c--) - _is_ obvious; to anyone else, it is far from so. And the person to whom it _is_ second nature sees no point in explaining it with a comment, either: (a) it just _does_ seem so obvious to them, (b) they'd actually find it difficult _to_ explain, in much the same way as describing the mechanics of walking isn't easy, even though most of us can do it. (Forgetting it took us some _years_ to learn!)
"J. P. Gilliver (John)" wrote
| I'm sorry, but the above is why this sort of discussion never ends. When | someone is intimately familiar with the syntax of a language, the | meaning/functioning of a line like the above - or, say, in C, something | like *a++=b(&c--) - _is_ obvious; to anyone else, it is far from so. And | the person to whom it _is_ second nature sees no point in explaining it | with a comment, either: (a) it just _does_ seem so obvious to them, (b) | they'd actually find it difficult _to_ explain, in much the same way as | describing the mechanics of walking isn't easy, even though most of us | can do it. (Forgetting it took us some _years_ to learn!)
You're generous to ascribe honest intentions. It's usually just a case of swagger: "I dare you to grovel and ask me what this means." People do it. Officials do it. Trades do it. Just look at the tech world, "leveraging solutions across the enterprise". Their jargon is gibberish to everyone else but they think they sound technical.
My favorite example is "micturate". Medical doctors like to use obscure words to sound authoritative. So when the general public got used to "urinate" they had to switch to micturate to make sure people wouldn't know what they were talking about. I'm waiting for penis and vagina to get overused to the point that they sound like swears and can no longer be used in polite company. (It's getting close to that time, I think.) Somehow the experts will cook up somethnig more obscure, probably derived from Greek, so that doctors and TV commentators can talk about sex in an offical capacity.
| *a++=b(&c--)
Get out of town!
I read somewhere that in some African countries where English is spoken (maybe as a second language), the "correct" words such as "penis" and vagina" are regarded as foul-mouthed and offensive, whereas our four-letter words are regarded as the correct ones to use in polite company.
Reminds me of that Greek chap in Shirley Valentine who told Shirley that he wanted to "make f*ck" with her.
Oh, one can. but.. some very interesting umm, new features can be introduced in your code when doing so.
Have something to add? Share your thoughts — no account required.
Ask the community — no account required