K&R Ex 1-3

[Gio]

I'm reading the K&R book and doing the exercises. Currently, I'm working
on Exercise 1-3.

Here's what I have:

#include <stdio.h>

main()
{
     float fahr, celsius;
     float lower, upper, step;

     lower = 0;   /* lower limit of temperatuire scale */
     upper = 300; /* upper limit */
     step = 20;   /* step size */
     fahr = lower;

     printf("F\t\tC\n");
     while (fahr <= upper) {
         celsius = (5.0/9.0) * (fahr-32.0);
         printf("%4.0f %7.1f\n", fahr, celsius);
         fahr = fahr + step;
     }
}

Now, this completes the exercise. Technically, anyway. However, I want
to make the "F" and "C" align properly above the right side of their
respective columns.

I realize this is probably a really minor thing, but I'd appreciate the
help none-the-less!

- Gio

 

[Ian Collins]

I'm reading the K&R book and doing the exercises. Currently, I'm working
on Exercise 1-3.

Here's what I have:

#include <stdio.h>

main()[/QUOTE]

make that int main(void).

While you are there, turn  your compiler's warnings up, the above should
have caused one.
[QUOTE]
{
float fahr, celsius;
float lower, upper, step;

lower = 0;   /* lower limit of temperatuire scale */
upper = 300; /* upper limit */
step = 20;   /* step size */
fahr = lower;

printf("F\t\tC\n");
while (fahr <= upper) {
celsius = (5.0/9.0) * (fahr-32.0);
printf("%4.0f %7.1f\n", fahr, celsius);
fahr = fahr + step;
}
}

Now, this completes the exercise. Technically, anyway. However, I want
to make the "F" and "C" align properly above the right side of their
respective columns.

Just add some spaces to the first print and a couple of tabs to the second.

printf(" F\t\t C\n");
printf("%4.0f\t\t%7.1f\n", fahr, celsius);

 

[Ben Bacarisse]

I'm reading the K&R book and doing the exercises. Currently, I'm
working on Exercise 1-3.

printf("F\t\tC\n");
while (fahr <= upper) {
celsius = (5.0/9.0) * (fahr-32.0);
printf("%4.0f %7.1f\n", fahr, celsius);
fahr = fahr + step;
}

Now, this completes the exercise. Technically, anyway. However, I want
to make the "F" and "C" align properly above the right side of their
respective columns.

I like to do this using the same sizes you have in the numeric
format:

printf("%4s %7s\n", "F", "C");

It keeps everything clear, and you can even wire in a configurable size
from a macro if you really want to (although that is a serious case of
overkill in this exercise).

 

[Gio]

While you are there, turn your compiler's warnings up, the above

should have caused one.

Well.. ah.. I'm working on an Apple II; the compiler I ran this program
on is technically pre-ANSI, but I've kept the differences in mind (and
the documentation close at hand). I figured I could ask a K&R question,
though.

As to why I'm learning C on an Apple IIe.. I'm doing it to get used to
the compiler and the limitations of the computer. And because I'm
slightly nuts.

- Gio

 

[Gio]

printf("%4s %7s\n", "F", "C");

Aha! This is perfect for me, thank you! I didn't know that it could work
like that.

- Gio

 

[Ian Collins]

Ian Collins said:


Why?

You know why.

 

[Ian Collins]

Ian Collins said:


If I knew why, I wouldn't need to ask why. I can see no reason why main()
should require a K&R C implementation (such as the OP is using) to issue a
diagnostic message. Please explain.

The OP didn't say he was using such an old compiler until his reply to
my post.

 

[Bill Buckels]

You know why.

Not on a K&R Compiler. Also warning levels not available on this
particular compiler, however 60% of Apple II developers wrote in Aztec
C. During the mid 80's Aztec C was the largesty selling C compiler.
And the best C compiler of the 80's and perhaps of all time.

Go to the Aztec C Website and take a look:

http://www.clipshop.ca/Aztec/index.htm

Bill Bucxels

 

[Ian Collins]

*Please* don't quote signatures.

Not on a K&R Compiler.

See my reply to Richard.

 

[Gio]

There are, however, definite advantages to be had in bringing

yourself kicking and screaming into the late 1980s. The ANSI C
Standard of 1989 was a significant step forward for C.

*nods* My first experience with coding was a CS class in college; they
taught ANSI C (ISO C was, I think, a year away). The person that makes
the compiler I'm using (Aztec-C) available has been talking to the
company that owns it to see if he can get the source and update it to
ANSI standards.

There is another compiler for the Apple IIe called cc65. It's not too
bad, really, and it is (according to the webpage) almost conforming to
the ISO standard. The program from the K&R book would not compile in it
without modification. Unfortunately, I can't get its output file to run
under ProDOS, which is the OS of choice for the Apple IIe.

While that is probably a personal problem, I'm going down the path of
least resistance for now.

- Gio

 

[Keith Thompson]

I'm reading the K&R book and doing the exercises. Currently, I'm working
on Exercise 1-3.

Here's what I have:

#include <stdio.h>

main()[/QUOTE]

make that int main(void).

While you are there, turn  your compiler's warnings up, the above should
have caused one.[/QUOTE]
[...]

For certain values of "should".  A C90-conforming implementation is
not required to issue a diagnostic for that declaration of main,
though a decent one will do so anyway if you ask it nicely.

 

[Ian Collins]

Look, if your point is that the int main(void) form is *preferable*, I
agree completely. I use that form myself and recommend it to others. But
there's quite a lot of distance between "this form is preferred to that
form" and "that form should have caused the implementation to issue a
diagnostic message".

Your recommended options for gcc would.

 

[Default User]

Gio wrote:

nods My first experience with coding was a CS class in college; they
taught ANSI C (ISO C was, I think, a year away). The person that
makes the compiler I'm using (Aztec-C) available has been talking to
the company that owns it to see if he can get the source and update
it to ANSI standards.

Aztec. Aztec. This sound familiar. Oh, aren't you the guy from RAIF
that was thinking of writing a text-adventure game to learn C?




Brian

 

[Gio]

Oh, aren't you the guy from RAIF that was thinking of writing a

text-adventure game to learn C?

Yep! That's me. Good to see you! I recognize you as well.

My plans have changed a little; instead of making up a new game, I will
be porting over the original Adventure.

- Gio

 

[Bill Buckels]

There are, however, definite advantages to be had in bringing
Given a choice between the best C compiler ever written for the Apple
II from the same company who produced the best C compilers ever
written, and trying to use a partially compliant ANSI 89 committee
animal that is hard if not harder to use and featureless by
comparison, I would argue that one should in fact not follow a gang of
kickers and screamers whether they have or not had the experience of
developing for older platforms as well as new, nor the wisdom to tell
the difference, or perhaps do know the difference but should not be
followed anyway.

K & R function prototypes are no problem. If that presents a problem
then one should probably consider taking up pizza delivery rather than
C programming.

I quite agree that in a perfect world the academic approach of using a
single standard would be wonderful, but since each case needs to be
considered on its own merit, probably less focus on what dialect of a
language is better, and since in many ways ANSI C extended K & R C, it
is not bad for a stranger in a strange land to learn to speak in
simple sentences before learning more complicated ones.

If you recall that a function is an int by default in K & R and so are
variables and these can be omitted and unsafely assumed to be int,
consider also that GIO does not need to omit types and can still
operate in a typesafe manner. He doesn't need to use typedefs and
return structures from functions.

Or didn't anyone who wrote a C program before 1989 do at least as good
a job as what I see around me today? You already know what I will say
when someone who has only been programming in C for 10 years or so
challenges me on this.

The examples that I have given him which by the way are also available
to anyone here who cares to look are pretty good. And he studied C as
well and from what I have seen so far he doesn't have much trouble
understanding.

http://www.clipshop.ca/Aztec/index.htm

Now until we can get the source code from Manx Software Systems which
looks like it will come if it still exists, I am not going to start
writing an ansi compliant replacement compiler for the Apple II.

Part of this work may even have been done for the Apple II according
to one of Manx's developers. We'll see. Until then Brodie's C89 was
significant but not currently an option here.

The benefit of having the source code for the Aztec C compilers for
the Apple II, Commodore 64, Amiga, Atari, Mac 68000, Z80 and 8080, and
of course 8086 MS-DOS and CP/M 86, and also of the linkers, the
library managers, symbolic debuggers, and all the rest of those first-
class cross-compilers and native-mode compilers, some which are
already ANSI 89 will be to make them available as cross-compilers for
such platforms as we wish. The Aztec C cross compilers that I have
currently only run in MS-DOS or CP/M.

The person that makes
the compiler I'm using (Aztec-C) available has been talking to the
company that owns it to see if he can get the source and update it to
ANSI standards.

That person would be me.

There is another compiler for the Apple IIe called cc65. It's not too
bad, really, and it is (according to the webpage) almost conforming to
the ISO standard. The program from the K&R book would not compile in it
without modification. Unfortunately, I can't get its output file to run
under ProDOS, which is the OS of choice for the Apple IIe.

Aztec C for the Apple II is "almost" ANSI but it's not.

But when it comes to compilers Aztec C is without equal. It was for
its time simnply the best and was squashed by some very giant
companies including Microsoft who once took out 6 full page ads in a
computer magazine to slam Aztec C.

For quite some time, around 85, 86, or so, it was the world's largest
selling C compiler.

The two unparalelled individuals behind its core were Thomas Fenwick
who later went on to write the CE Kernel, and James Goonow who then
worked with Carl Sassenrath on VIDStream and REBOL.

The floating point libraries at a time when FP was unheard of were
flawless and actually the 6 or so individuals that put these together
are like the whose-who of who invented floating point for compilers as
we know them.

While that is probably a personal problem, I'm going down the path of
least resistance for now.

I think that you aren't the person with the problem and I don't so
much think the problem with that compiler is personal so much as it
isn't finished. By contrast the Aztec C compiler for the Apple II was
used by 60% of the Apple II dvelopers.

We call the path of least reasistance the critical path and it is
always the best one to take because if it turns-out to be the wrong
one you will find-out sooner than the slower path with the most
resistance. Also as suggested perhaps a little more strongly than I
should have (perhaps not) if you can't just jump-in and start coding
then hiow are ya gonna get any learning done?

"All the tired horses in the sun, how'm'I 'sposed to get any riding
done?"

- Bob Dylan

 

[Bill Buckels]

I seem to vaguely recall that the originator of Aztec C made its
source generally available some time ago.  

No Harry didn't.

 

[arnuld]

Why?

so any ANSI C conforming compiler is not required to issue a warning ?


GCC does that and I think it is a good idea:

"control reaches the end of a non-void function"


but GCC never gives the warning if I omit the void of main(void)

 

[Peter Nilsson]

so any ANSI C conforming compiler is not required to issue
a warning ?

Compilers talk in terms of warnings and errors. The standard
talks only of diagnostics, some of which are required. There
is no direct correlation between the two worlds except that
an 'error' tends to cause compilation to fail.

In clc it is better to talk of required diagnostics which are those
that a conforming implementation are required to issue (at
least one of) when encountering a constraint violation.

Whether required diagnostics become errors or warnings
is entirely a matter for the implementation writer. The
standard just needs the implementation to go 'beep'!

GCC does that and I think it is a good idea:

"control reaches the end of a non-void function"

In C, non-void functions are not required to return a value.
So this should be a warning in most cases. If it's an error,
then the compiler needs to prove that there exists a function
that attempts to use the return value after calling the non-
void function that doesn't return a value.

but GCC never gives the warning if I omit the void of
main(void)

Turn up your warning levels then.

 

[arnuld]

Strange - I get a different message. Here's my test program:

...[SNIP]........

foo.c:4: warning: return-type defaults to `int'
foo.c:4: warning: function declaration isn't a prototype

I have seen this warning with GCC at my home, did not remember which
version it was. Right now at company's workstation it is GCC 3.4.

It does if you kick it hard enough (see above).

tried even -std=c99 flag, still no luck

 

[santosh]

On Mon, 21 Apr 2008 05:21:00 +0000, Richard Heathfield wrote:

Strange - I get a different message. Here's my test program:

...[SNIP]........

foo.c:4: warning: return-type defaults to `int'
foo.c:4: warning: function declaration isn't a prototype

I have seen this warning with GCC at my home, did not remember which
version it was. Right now at company's workstation it is GCC 3.4.

It does if you kick it hard enough (see above).

tried even -std=c99 flag, still no luck

Are you using -Wall -W and -pedantic flags?