printf headache

[Joe Smith]

#include <stdio.h>

int main(void)
{
unsigned long gcd(unsigned long m, unsigned long n);
unsigned long m;
unsigned long n;
unsigned long t;
m = 2520;
n = 154;
t = gcd(m, n);
printf("%f is gcd\n", t);
return 0;
}

unsigned long gcd(unsigned long m, unsigned long n)
{
if(m < n)
{
unsigned long temp = m;
m = n;
n = temp;
}
if(n > 0)
{
unsigned long r;
do
{
r = m % n;
m = n;
n = r ? r : n;
} while(r > 0);
}

return n;
}
/* end code */
This compiles and behaves with the exception of the printf. I've scoured
K&R print flags to %% and am out of guesses. Joe

[Ian Collins]

Joe Smith wrote:

#include <stdio.h>

int main(void)
{
unsigned long gcd(unsigned long m, unsigned long n);
unsigned long m;
unsigned long n;
unsigned long t;
m = 2520;
n = 154;
t = gcd(m, n);
printf("%f is gcd\n", t);

You are using %f (float) to print an unsigned long. Try %d.

--
Ian Collins.

[Al Balmer]

On Thu, 04 May 2006 10:10:28 +1200, Ian Collins <ia******@hotmail.com>
wrote:

Joe Smith wrote:

#include <stdio.h>

int main(void)
{
unsigned long gcd(unsigned long m, unsigned long n);
unsigned long m;
unsigned long n;
unsigned long t;
m = 2520;
n = 154;
t = gcd(m, n);
printf("%f is gcd\n", t);

You are using %f (float) to print an unsigned long. Try %d.

Or maybe even %ld :-)

--
Al Balmer
Sun City, AZ

[Default User]

Ian Collins wrote:

Joe Smith wrote:

#include <stdio.h>

int main(void)
{
unsigned long gcd(unsigned long m, unsigned long n);
unsigned long m;
unsigned long n;
unsigned long t;
m = 2520;
n = 154;
t = gcd(m, n);
printf("%f is gcd\n", t);

You are using %f (float) to print an unsigned long. Try %d.

Why? That's also wrong. Either cast or use %ul.

Brian

[Ian Collins]

Al Balmer wrote:

On Thu, 04 May 2006 10:10:28 +1200, Ian Collins <ia******@hotmail.com>
wrote:

Joe Smith wrote:

#include <stdio.h>

int main(void)
{
unsigned long gcd(unsigned long m, unsigned long n);
unsigned long m;
unsigned long n;
unsigned long t;
m = 2520;
n = 154;
t = gcd(m, n);
printf("%f is gcd\n", t);

You are using %f (float) to print an unsigned long. Try %d.

Or maybe even %ld :-)

Or %ul :)

--
Ian Collins.

[Joe Smith]

"Ian Collins"

Joe Smith wrote:

snip

printf("%f is gcd\n", t);

You are using %f (float) to print an unsigned long. Try %d.

Yeah, that'll do it. In the development by Gallian he writes out the eqns
for what happens for this division algorithm with 2520 and 154 as input:
2520 = 154*16 +56
154=56*2+42
56=42*1+14
42=14*3+0
It is unclear to me whether this is where prop 2 book 7 Euclid finishes.
Mr. Heathfield, who kindly provided this code from Knuth, and I have been
talking past each other elsewhere as I was under the impression that the
Euclidean algorithm would ultimately express two numbers as a linear
combination. To do this, Gallian rewrites the eq's and substitutes:
56 = 2520+154(-16)
42=154+56(-2)
14=56+42(-1)
=56+[154+56(-2)](-1)
=56*3+154(-1)
=[2520 +154(-16)]3+154(-1)
14=2520*3 + 154(-49)

I think I need a memory technique to do what Professor Gallian does above.
Furthermore, one does not know a priori how many steps the division
algorithm requires. It would seem to me that I would have to run the
division algorithm and remember something each time. (Finally a question)
Given the truth of the previous sentence, what is the stingiest way to do it
in C? Joe

[Robert Gamble]

Default User wrote:

Ian Collins wrote:

Joe Smith wrote:

#include <stdio.h>

int main(void)
{
unsigned long gcd(unsigned long m, unsigned long n);
unsigned long m;
unsigned long n;
unsigned long t;
m = 2520;
n = 154;
t = gcd(m, n);
printf("%f is gcd\n", t);

You are using %f (float) to print an unsigned long. Try %d.

Why? That's also wrong. Either cast or use %ul.

That's wrong as well, it should be %lu.

Robert Gamble

[Robert Gamble]

Ian Collins wrote:

Al Balmer wrote:

On Thu, 04 May 2006 10:10:28 +1200, Ian Collins <ia******@hotmail.com>
wrote:

Joe Smith wrote:

#include <stdio.h>

int main(void)
{
unsigned long gcd(unsigned long m, unsigned long n);
unsigned long m;
unsigned long n;
unsigned long t;
m = 2520;
n = 154;
t = gcd(m, n);
printf("%f is gcd\n", t);

You are using %f (float) to print an unsigned long. Try %d.

Or maybe even %ld :-)

Or %ul :)

Or %lu if you want to print an unsigned long as opposed to an unsigned
int followed by the letter l :)

Robert Gamble

[Al Balmer]

On Thu, 04 May 2006 10:49:35 +1200, Ian Collins <ia******@hotmail.com>
wrote:

Al Balmer wrote:

On Thu, 04 May 2006 10:10:28 +1200, Ian Collins <ia******@hotmail.com>
wrote:

Joe Smith wrote:

#include <stdio.h>

int main(void)
{
unsigned long gcd(unsigned long m, unsigned long n);
unsigned long m;
unsigned long n;
unsigned long t;
m = 2520;
n = 154;
t = gcd(m, n);
printf("%f is gcd\n", t);

You are using %f (float) to print an unsigned long. Try %d.

Or maybe even %ld :-)

Or %ul :)

?
My compiler prefers %lu.

--
Al Balmer
Sun City, AZ

[Ian Collins]

Robert Gamble wrote:

Ian Collins wrote:

Al Balmer wrote:

Or maybe even %ld :-)

Or %ul :)

Or %lu if you want to print an unsigned long as opposed to an unsigned
int followed by the letter l :)

Do any implementations do that?
--
Ian Collins.

[Old Wolf]

Robert Gamble wrote:

Ian Collins wrote:

Or %ul :)

Or %lu if you want to print an unsigned long as opposed to an
unsigned int followed by the letter l :)

I actually did that one time. And the printer was using a font in
which the number 1 is indistinguishable from the letter l. I spent
some time tearing my hair out as to why my values which
should have been 4 and 6 were printing out as 41 and 61 :)

[Robert Gamble]

Old Wolf wrote:

Robert Gamble wrote:

Ian Collins wrote:

Or %ul :)

Or %lu if you want to print an unsigned long as opposed to an
unsigned int followed by the letter l :)

I actually did that one time. And the printer was using a font in
which the number 1 is indistinguishable from the letter l. I spent
some time tearing my hair out as to why my values which
should have been 4 and 6 were printing out as 41 and 61 :)

I don't always remember which way it goes either and %ul is somewhat
more intuitive (for Unsigned Long); luckily both my editor and compiler
know which it is ;)

Robert Gamble

[Robert Gamble]

Ian Collins wrote:

Robert Gamble wrote:

Ian Collins wrote:

Al Balmer wrote:
Or maybe even %ld :-)
Or %ul :)

Or %lu if you want to print an unsigned long as opposed to an unsigned
int followed by the letter l :)

Do any implementations do that?

All conforming ones do, what does yours do?

Robert Gamble

[Ian Collins]

Robert Gamble wrote:

Ian Collins wrote:

Robert Gamble wrote:

Ian Collins wrote:
Al Balmer wrote:
>Or maybe even %ld :-)
>

Or %ul :)
Or %lu if you want to print an unsigned long as opposed to an unsigned
int followed by the letter l :)

Do any implementations do that?

All conforming ones do, what does yours do?

Robert Gamble

#include <stdio.h>

int
main(void)
{
unsigned long l = (unsigned long)-1;

printf( "%d %ul %ld %lu\n", l, l, l, l );
}

-1 4294967295l -1 4294967295

With both Sun cc and gcc.

--
Ian Collins.

[Ian Collins]

Ian Collins wrote:

#include <stdio.h>

int
main(void)
{
unsigned long l = (unsigned long)-1;

printf( "%d %ul %ld %lu\n", l, l, l, l );
}

-1 4294967295l -1 4294967295
^

Bugger, I fell into the 1 != l trap...

--
Ian Collins.

[Robert Gamble]

Ian Collins wrote:

Robert Gamble wrote:

Ian Collins wrote:

Robert Gamble wrote:

Ian Collins wrote:
>Al Balmer wrote:
>
>
>>Or maybe even %ld :-)
>>
>
>Or %ul :)
Or %lu if you want to print an unsigned long as opposed to an unsigned
int followed by the letter l :)
Do any implementations do that?

All conforming ones do, what does yours do?

Robert Gamble

#include <stdio.h>

int
main(void)
{
unsigned long l = (unsigned long)-1;

printf( "%d %ul %ld %lu\n", l, l, l, l );
}

-1 4294967295l -1 4294967295

With both Sun cc and gcc.

I am not sure what you are trying to demonstrate here and your example
contains more than one instance of undefined behavior which gcc points
out when executed with the appropriate options:

warning: format '%d' expects type 'int', but argument 2 has
type 'long unsigned int'
warning: format '%u' expects type 'unsigned int', but argument
3 has type 'long unsigned int'

Notice that the letter l was printed after the value corresponding to
the %ul conversion specifier in your example which, aside from the
above-mentioned UB, is in line with my assertion.

Here is a more appropriate example:

#include <stdio.h>

int
main(void)
{
unsigned long l = 42;
printf( "%ul %lu\n", (unsigned)l, l );
return 0;
}

The cast is required to prevent undefined behavior and the result
should be:
42l 42

Robert Gamble

[CBFalconer]

Joe Smith wrote:

#include <stdio.h>

int main(void)
{
unsigned long gcd(unsigned long m, unsigned long n);
unsigned long m;
unsigned long n;
unsigned long t;
m = 2520;
n = 154;
t = gcd(m, n);
printf("%f is gcd\n", t);
return 0;
}

unsigned long gcd(unsigned long m, unsigned long n)
{
if(m < n)
{
unsigned long temp = m;
m = n;
n = temp;
}
if(n > 0)
{
unsigned long r;
do
{
r = m % n;
m = n;
n = r ? r : n;
} while(r > 0);
}

return n;
}
/* end code */
This compiles and behaves with the exception of the printf. I've scoured
K&R print flags to %% and am out of guesses. Joe

Apparently noone has bothered to notice that you are calling gcd
before declaring it, and that the system thus assumes gcd to return
an int.

The simple practice of writing subroutines ahead of routines that
call them will avoid this sort of silly error. With proper flags
the better compilers would have also complained.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

[Ian Collins]

CBFalconer wrote:

Joe Smith wrote:

#include <stdio.h>

int main(void)
{
unsigned long gcd(unsigned long m, unsigned long n);

Apparently noone has bothered to notice that you are calling gcd
before declaring it, and that the system thus assumes gcd to return
an int.
Note the first line of main.
The simple practice of writing subroutines ahead of routines that
call them will avoid this sort of silly error. With proper flags
the better compilers would have also complained.

Not in this case, but I agree with writing subroutines before they are used.

--
Ian Collins.

[Joe Smith]

"CBFalconer" <cb********@yahoo.com> wrote in message

Joe Smith wrote:

#include <stdio.h>

int main(void)
{
unsigned long gcd(unsigned long m, unsigned long n);
unsigned long m;
unsigned long n;
unsigned long t;
m = 2520;
n = 154;
t = gcd(m, n);
printf("%f is gcd\n", t);
return 0;
}

unsigned long gcd(unsigned long m, unsigned long n)
{
if(m < n)
{
unsigned long temp = m;
m = n;
n = temp;
}
if(n > 0)
{
unsigned long r;
do
{
r = m % n;
m = n;
n = r ? r : n;
} while(r > 0);
}

return n;
}
/* end code */
This compiles and behaves with the exception of the printf. I've scoured
K&R print flags to %% and am out of guesses. Joe
Apparently noone has bothered to notice that you are calling gcd
before declaring it, and that the system thus assumes gcd to return
an int.

I believe that this is what forked me.
The simple practice of writing subroutines ahead of routines that
call them will avoid this sort of silly error. With proper flags
the better compilers would have also complained.

I struggle with flags in the contemporary programming environment. As to the
former contention, Mr. Knuth wrote the subroutine while I was watching Tom &
Jerry. I would like to characterize the improper call as part of the rust
I'm trying to shed. Joe
--------------
it never helps to have already thrown K&R
at the arbitrary wall

[pete]

Robert Gamble wrote:

Default User wrote:

Ian Collins wrote:

Joe Smith wrote:
> #include <stdio.h>
>
> int main(void)
> {
> unsigned long gcd(unsigned long m, unsigned long n);
> unsigned long m;
> unsigned long n;
> unsigned long t;
> m = 2520;
> n = 154;
> t = gcd(m, n);
> printf("%f is gcd\n", t);

You are using %f (float) to print an unsigned long. Try %d.

Why? That's also wrong. Either cast or use %ul.

That's wrong as well, it should be %lu.

I usually write "long unsigned" instead of "unsigned long",
to remind me not to make a mistake like that, again.

--
pete

[Joe Smith]

"pete" <pf*****@mindspring.com>

Default User wrote:

> Ian Collins wrote:
> > Joe Smith wrote:

[original code snipped]
I usually write "long unsigned" instead of "unsigned long",
to remind me not to make a mistake like that, again.

#include <stdio.h>

int main(void)
{
long unsigned gcd(long unsigned m, long unsigned n);
long unsigned m;
long unsigned n;
long unsigned t;
m = 2520;
n = 154;
t = gcd(m, n);
printf("%lu is gcd\n", t);
return 0;
}

long unsigned gcd(long unsigned m, long unsigned n)
{
if(m < n)
{
long unsigned temp = m;
m = n;
n = temp;
}
if(n > 0)
{
long unsigned r;
do
{
r = m % n;
m = n;
n = r ? r : n;
} while(r > 0);
}
return n;
}
/* end source */
I believe this is correct. After a night's sleep and morningly K&R, I don't
think it's true that gcd is called before being declared. Joe

[Martin Ambuhl]

Joe Smith wrote:

"Ian Collins"

Joe Smith wrote:

snip

printf("%f is gcd\n", t);

You are using %f (float) to print an unsigned long. Try %d.

Yeah, that'll do it.

No, it won't. It's wrong. It's an error. It's very bad advice from
one person who can't read documentation to another. Learn the
difference between 'int' and 'long'; then learn the difference between
'signed' and 'unsigned'. "%d" is wrong in two different ways.

[Keith Thompson]

pete <pf*****@mindspring.com> writes:

Robert Gamble wrote:

Default User wrote: [...]

> Why? That's also wrong. Either cast or use %ul.

That's wrong as well, it should be %lu.

I usually write "long unsigned" instead of "unsigned long",
to remind me not to make a mistake like that, again.

That's perfectly legal, but purely as a matter of style:

Ick.

The type is referred to as "unsigned long" or "unsigned long int" in
the standard and in every C book I've seen. If I see "long unsigned"
in code, I'll understand it, but I'll have to pause for a second or so
to remember what it means, and even longer to figure out why it's
written backwards. Some readers might not even know that it's legal.

It's not *quite* as bad as (42 == x), though.

This is nothing more or less than my personal opinion.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Joe Smith]

"Martin Ambuhl"

Joe Smith wrote:

"Ian Collins"

Joe Smith wrote:

snip

printf("%f is gcd\n", t);

You are using %f (float) to print an unsigned long. Try %d.

Yeah, that'll do it.

No, it won't. It's wrong. It's an error. It's very bad advice from one
person who can't read documentation to another. Learn the difference
between 'int' and 'long'; then learn the difference between 'signed' and
'unsigned'. "%d" is wrong in two different ways.

You are quite literally correct in your assertion that I have trouble
reading documentation after ten hours of reading documentation. His
mistaken reply allowed output on my console of an executable whose source
was non Standard. In my reply to pete upthread, I think I have it kosher.
Joe

[Ian Collins]

Martin Ambuhl wrote:

No, it won't. It's wrong. It's an error. It's very bad advice from
one person who can't read documentation to another.

Why so rude? Are you so perfect that you never misread a post to Usenet?
--
Ian Collins.

[Joe Smith]

"Ian Collins" <ia******@hotmail.com> wrote in message

Martin Ambuhl wrote:

No, it won't. It's wrong. It's an error. It's very bad advice from
one person who can't read documentation to another.

[Mr. Collins' reasonable objection to the tone]

Now, that I've enjoyed a further ten, delicious hours of sleep and again
morningly K&R, I would like to ask a few questions about about Table B-1:
1) printf is fprintf to stdout?
2) "Between the % and the conversion character there may be, in order:" Is
this what makes %lu correct and %ul not?
3)"If the character after the % is not a conversion character, the behavior
is undefined." If Keith Thompson and pete let %lu go with only objections
to style, then this statement is wrong. How could it be said correctly?

It would seem that the flip side of things I like about C is the inability
to yell 'print the damn thing'. Joe

[Robert Gamble]

Joe Smith wrote:

"Ian Collins" <ia******@hotmail.com> wrote in message

Martin Ambuhl wrote:

No, it won't. It's wrong. It's an error. It's very bad advice from
one person who can't read documentation to another.

[Mr. Collins' reasonable objection to the tone]

Now, that I've enjoyed a further ten, delicious hours of sleep and again
morningly K&R, I would like to ask a few questions about about Table B-1:
1) printf is fprintf to stdout?

Yes.
2) "Between the % and the conversion character there may be, in order:" Is
this what makes %lu correct and %ul not?
Yes.
3)"If the character after the % is not a conversion character, the behavior
is undefined." If Keith Thompson and pete let %lu go with only objections
to style, then this statement is wrong. How could it be said correctly?
I'm not sure what you are asking here. %lu prints a "long unsigned
int", %ul prints an "unsigned int" followed by the l character, it is
not undefined, there is the legal %u conversion followed by the literal
letter l. Keith and pete were discussing how to write the actual name
of the type, both "unsigned long int" and "long unsigned int" are legal
as is any other permutation such as "int unsigned long".
It would seem that the flip side of things I like about C is the inability
to yell 'print the damn thing'. Joe

The puts() function probably comes closest to fitting that bill but it
doesn't do formatted text.

Robert Gamble

[Joe Smith]

"Robert Gamble" <rg*******@gmail.com> wrote in message
news:11**********************@j33g2000cwa.googlegr oups.com...

Joe Smith wrote:

[done and forgotten]

Now, that I've enjoyed a further ten, delicious hours of sleep and again
morningly K&R, I would like to ask a few questions about about Table B-1:
1) printf is fprintf to stdout?

Yes.

I know that, among others, CBFalconer likes to see explicit use of stdin and
stdout. I'm curious why I don't see more fprintf.

2) "Between the % and the conversion character there may be, in order:"
Is
this what makes %lu correct and %ul not?

Yes.

I'm a little hoist on my own logic, there. I believe Mr. Gamble is
claiming:
%lu is correct
%ul is not correct *
Furthermore, a couple words on order:
I had hoped that Morgan Freeman, one of my favorite actors, would pass
before I had to level this criticism at him, but 'top to bottom, left to
right' is, while rhyming with 'sight', wrong for lexicographic order of the
English language. Correct is 'left to right, top to bottom'. I suspect
that the reason that the writer for Easy Reader has this wrong is that he
didn't want Mr. Freeman to have to talk about his scrotum to a bunch of
children.

3)"If the character after the % is not a conversion character, the
behavior
is undefined." If Keith Thompson and pete let %lu go with only
objections
to style, then this statement is wrong. How could it be said correctly?

I'm not sure what you are asking here. %lu prints a "long unsigned
int", %ul prints an "unsigned int" followed by the l character, it is
not undefined, there is the legal %u conversion followed by the literal
letter l. Keith and pete were discussing how to write the actual name
of the type, both "unsigned long int" and "long unsigned int" are legal
as is any other permutation such as "int unsigned long".

My claim is that if
fprintf(stdout, "%lu\n", gcd);
is ISO then
then the first sentence in 3) needs revision.

[io stuff]

I'm going to snipe your elsethread method of getting an integer from the
keyboard. Eighty chars is about right, meaning about an order of magnitude
bigger than what a sensible person would input under this circumstance. Joe

[Robert Gamble]

Joe Smith wrote:

"Robert Gamble" <rg*******@gmail.com> wrote in message
news:11**********************@j33g2000cwa.googlegr oups.com...

Joe Smith wrote: [done and forgotten]

Now, that I've enjoyed a further ten, delicious hours of sleep and again
morningly K&R, I would like to ask a few questions about about Table B-1:
1) printf is fprintf to stdout?

Yes.

I know that, among others, CBFalconer likes to see explicit use of stdin and
stdout. I'm curious why I don't see more fprintf.

I haven't noticed that tendency but if it exists it would just be a
matter of style.

2) "Between the % and the conversion character there may be, in order:"
Is
this what makes %lu correct and %ul not?

Yes.

I'm a little hoist on my own logic, there. I believe Mr. Gamble is
claiming:
%lu is correct
%ul is not correct *

If the intent is to print an unsigned long int then yes, that is what I
am claiming. What is it that you do not understand here?

3)"If the character after the % is not a conversion character, the
behavior
is undefined." If Keith Thompson and pete let %lu go with only
objections
to style, then this statement is wrong. How could it be said correctly?

I'm not sure what you are asking here. %lu prints a "long unsigned
int", %ul prints an "unsigned int" followed by the l character, it is
not undefined, there is the legal %u conversion followed by the literal
letter l. Keith and pete were discussing how to write the actual name
of the type, both "unsigned long int" and "long unsigned int" are legal
as is any other permutation such as "int unsigned long".

My claim is that if
fprintf(stdout, "%lu\n", gcd);
is ISO then
then the first sentence in 3) needs revision.

Okay, I see your point here. I don't have K&R in front of me at the
moment but here is how the standard puts it: "If a conversion
specification is invalid, the behavior is undefined". The conversion
specification refers to the combination of all the components (flags,
lenght, width, etc.) that describe the conversion that should take
place. I am sure that it could be argued that "conversion character"
could refer to any character in the "conversion specification" but I
will admit that the wording you provided can reasonably be construed as
misleading.
I'm going to snipe your elsethread method of getting an integer from the
keyboard. Eighty chars is about right, meaning about an order of magnitude
bigger than what a sensible person would input under this circumstance.

If you are referring to my post in the thread "How to sscanf return
integer only", I wouldn't recommend it unless you have a similar goal
as the OP in that thread. The strto* functions are usually enough by
themselves for most purposes.

Robert Gamble

[CBFalconer]

Robert Gamble wrote:

Joe Smith wrote:

.... snip ...

I know that, among others, CBFalconer likes to see explicit use
of stdin and stdout. I'm curious why I don't see more fprintf.

I haven't noticed that tendency but if it exists it would just be
a matter of style.

If I write an i/o routine, I probably haven't decided what files to
use in on. Therefore the actual file becomes a parameter. If I
want to jam it to a particular file I can use a macro. See the
relationship between ggets() and fggets() in:

<http://cbfalconer.home.att.net/download/ggets.zip>

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

[Al Balmer]

On 5 May 2006 13:06:29 -0700, "Robert Gamble" <rg*******@gmail.com>
wrote:

Joe Smith wrote:

"Robert Gamble" <rg*******@gmail.com> wrote in message
news:11**********************@j33g2000cwa.googlegr oups.com...

> Joe Smith wrote:

<snip>

>> 3)"If the character after the % is not a conversion character, the
>> behavior
>> is undefined." If Keith Thompson and pete let %lu go with only
>> objections
>> to style, then this statement is wrong. How could it be said correctly?
>
> I'm not sure what you are asking here. %lu prints a "long unsigned
> int", %ul prints an "unsigned int" followed by the l character, it is
> not undefined, there is the legal %u conversion followed by the literal
> letter l. Keith and pete were discussing how to write the actual name
> of the type, both "unsigned long int" and "long unsigned int" are legal
> as is any other permutation such as "int unsigned long".
My claim is that if
fprintf(stdout, "%lu\n", gcd);
is ISO then
then the first sentence in 3) needs revision.

Okay, I see your point here. I don't have K&R in front of me at the
moment but here is how the standard puts it: "If a conversion
specification is invalid, the behavior is undefined".

K&R does indeed say conversion character, and in context, it looks
like a genuine misstatement, though it doesn't appear in the errata:

"The conversion characters and their meanings are shown in Table B-1.
If the character after the % is not a conversion character, the
behavior is undefined."

Table B-1, of course, contains only conversion characters, not other
conversion specifications.
The conversion
specification refers to the combination of all the components (flags,
lenght, width, etc.) that describe the conversion that should take
place. I am sure that it could be argued that "conversion character"
could refer to any character in the "conversion specification" but I
will admit that the wording you provided can reasonably be construed as
misleading.

--
Al Balmer
Sun City, AZ

[Joe Smith]

"Al Balmer" <al******@att.net> wrote in message
news:vm********************************@4ax.com...

On 5 May 2006 13:06:29 -0700, "Robert Gamble" <rg*******@gmail.com>
wrote:

Joe Smith wrote:

"Robert Gamble" <rg*******@gmail.com> wrote in message
news:11**********************@j33g2000cwa.googlegr oups.com...
> Joe Smith wrote:

<snip>

>> 3)"If the character after the % is not a conversion character, the
>> behavior
>> is undefined." If Keith Thompson and pete let %lu go with only
>> objections
>> to style, then this statement is wrong. How could it be said
>> correctly?
>
> I'm not sure what you are asking here. %lu prints a "long unsigned
> int", %ul prints an "unsigned int" followed by the l character, it is
> not undefined, there is the legal %u conversion followed by the
> literal
> letter l. Keith and pete were discussing how to write the actual name
> of the type, both "unsigned long int" and "long unsigned int" are
> legal
> as is any other permutation such as "int unsigned long".

My claim is that if
fprintf(stdout, "%lu\n", gcd);
is ISO then
then the first sentence in 3) needs revision.

Okay, I see your point here. I don't have K&R in front of me at the
moment but here is how the standard puts it: "If a conversion
specification is invalid, the behavior is undefined".

K&R does indeed say conversion character, and in context, it looks
like a genuine misstatement, though it doesn't appear in the errata:

"The conversion characters and their meanings are shown in Table B-1.
If the character after the % is not a conversion character, the
behavior is undefined."

Table B-1, of course, contains only conversion characters, not other
conversion specifications.

The conversion
specification refers to the combination of all the components (flags,
lenght, width, etc.) that describe the conversion that should take
place. I am sure that it could be argued that "conversion character"
could refer to any character in the "conversion specification" but I
will admit that the wording you provided can reasonably be construed as
misleading.

It's hard for me to talk to Arizona. My concern is that I might say yx and
you reply %yx without seeing a difference. But that's slightly missstated,
and misstated might be precisely the way I describe Arizona. Joe

[Keith Thompson]

"Joe Smith" <gr**********@netzero.net> writes:
[...]

It's hard for me to talk to Arizona. My concern is that I might say yx and
you reply %yx without seeing a difference. But that's slightly missstated,
and misstated might be precisely the way I describe Arizona. Joe

Arizona? Huh?

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Rod Pemberton]

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...

"Joe Smith" <gr**********@netzero.net> writes:
[...]

It's hard for me to talk to Arizona. My concern is that I might say yx and you reply %yx without seeing a difference. But that's slightly missstated, and misstated might be precisely the way I describe Arizona. Joe

Arizona? Huh?

Do you read people's sig's?

[Al Balmer]

On Sat, 6 May 2006 04:01:52 -0400, "Joe Smith"
<gr**********@netzero.net> wrote:

"Al Balmer" <al******@att.net> wrote in message
news:vm********************************@4ax.com.. .

On 5 May 2006 13:06:29 -0700, "Robert Gamble" <rg*******@gmail.com>
wrote:

Joe Smith wrote:
"Robert Gamble" <rg*******@gmail.com> wrote in message
news:11**********************@j33g2000cwa.googlegr oups.com...
> Joe Smith wrote:

<snip>

>> 3)"If the character after the % is not a conversion character, the
>> behavior
>> is undefined." If Keith Thompson and pete let %lu go with only
>> objections
>> to style, then this statement is wrong. How could it be said
>> correctly?
>
> I'm not sure what you are asking here. %lu prints a "long unsigned
> int", %ul prints an "unsigned int" followed by the l character, it is
> not undefined, there is the legal %u conversion followed by the
> literal
> letter l. Keith and pete were discussing how to write the actual name
> of the type, both "unsigned long int" and "long unsigned int" are
> legal
> as is any other permutation such as "int unsigned long".

My claim is that if
fprintf(stdout, "%lu\n", gcd);
is ISO then
then the first sentence in 3) needs revision.

Okay, I see your point here. I don't have K&R in front of me at the
moment but here is how the standard puts it: "If a conversion
specification is invalid, the behavior is undefined".

K&R does indeed say conversion character, and in context, it looks
like a genuine misstatement, though it doesn't appear in the errata:

"The conversion characters and their meanings are shown in Table B-1.
If the character after the % is not a conversion character, the
behavior is undefined."

Table B-1, of course, contains only conversion characters, not other
conversion specifications.

The conversion
specification refers to the combination of all the components (flags,
lenght, width, etc.) that describe the conversion that should take
place. I am sure that it could be argued that "conversion character"
could refer to any character in the "conversion specification" but I
will admit that the wording you provided can reasonably be construed as
misleading.

It's hard for me to talk to Arizona. My concern is that I might say yx and
you reply %yx without seeing a difference. But that's slightly missstated,
and misstated might be precisely the way I describe Arizona. Joe

I'll agree that you've misstated something, because I have no idea
what you're talking about. The Arizona version of K&R is the same as
everyone else's.

--
Al Balmer
Sun City, AZ

[Joe Smith]

"Al Balmer" <al******@att.net> wrote in message
news:a4********************************@4ax.com...

On Sat, 6 May 2006 04:01:52 -0400, "Joe Smith"
<gr**********@netzero.net> wrote:

"Al Balmer" <al******@att.net> wrote in message
news:vm********************************@4ax.com. ..

On 5 May 2006 13:06:29 -0700, "Robert Gamble" <rg*******@gmail.com>
wrote:

Joe Smith wrote:
> "Robert Gamble" <rg*******@gmail.com> wrote in message
> news:11**********************@j33g2000cwa.googlegr oups.com...
> > Joe Smith wrote:
<snip>

> >> 3)"If the character after the % is not a conversion character, the
> >> behavior
> >> is undefined." If Keith Thompson and pete let %lu go with only
> >> objections
> >> to style, then this statement is wrong. How could it be said
> >> correctly?
> >
> > I'm not sure what you are asking here. %lu prints a "long unsigned
> > int", %ul prints an "unsigned int" followed by the l character, it
> > is
> > not undefined, there is the legal %u conversion followed by the
> > literal
> > letter l. Keith and pete were discussing how to write the actual
> > name
> > of the type, both "unsigned long int" and "long unsigned int" are
> > legal
> > as is any other permutation such as "int unsigned long".
>
> My claim is that if
> fprintf(stdout, "%lu\n", gcd);
> is ISO then
> then the first sentence in 3) needs revision.

Okay, I see your point here. I don't have K&R in front of me at the
moment but here is how the standard puts it: "If a conversion
specification is invalid, the behavior is undefined".

K&R does indeed say conversion character, and in context, it looks
like a genuine misstatement, though it doesn't appear in the errata:

"The conversion characters and their meanings are shown in Table B-1.
If the character after the % is not a conversion character, the
behavior is undefined."

Table B-1, of course, contains only conversion characters, not other
conversion specifications.

The conversion
specification refers to the combination of all the components (flags,
lenght, width, etc.) that describe the conversion that should take
place. I am sure that it could be argued that "conversion character"
could refer to any character in the "conversion specification" but I
will admit that the wording you provided can reasonably be construed as
misleading.

[stupid OT crap]
I'll agree that you've misstated something, because I have no idea
what you're talking about. The Arizona version of K&R is the same as
everyone else's.

--
Al Balmer
Sun City, AZ

Sorry, Al, that my little hissy fit was directed at you. I was fresh out of
a fisticuffs. My claim is that % followed by l (ell) violates the sentence
preceding Table B-1. Obviously, the Standard is relevant, and K&R talk
pedagogical. I think the sentence would be correct if it said 'if the
character after the % , and after all the optional things above, is not one
of the below characters, the behavior is undefined.' Not exactly
Shakespeare. Joe
-------
I should kicked him harder and more.

[Mark McIntyre]

On Sat, 6 May 2006 05:18:17 -0400, in comp.lang.c , "Rod Pemberton"
<do*********@bitfoad.cmm> wrote:

"Keith Thompson" <ks***@mib.org> wrote in message
news:ln************@nuthaus.mib.org...

"Joe Smith" <gr**********@netzero.net> writes:
[...]

> It's hard for me to talk to Arizona. My concern is that I might say yxand > you reply %yx without seeing a difference. But that's slightlymissstated, > and misstated might be precisely the way I describe Arizona. Joe

Arizona? Huh?

Do you read people's sig's?

Do you think they're relevant?
--
Mark McIntyre

"The lusers I know are so clueless, that if they were dipped in clue
musk and dropped in the middle of pack of horny clues, on clue prom
night during clue happy hour, they still couldn't get a clue."
--Michael Girdwood, in the monastery

[Joe Smith]

"Robert Gamble" <rg*******@gmail.com> wrote in message
news:11**********************@e56g2000cwe.googlegr oups.com...

Joe Smith wrote:
[%lu and angels on the head of a pin][I'm going to snipe your elsethread method of getting an integer from the keyboard. Eighty chars is about right, meaning about an order of magnitude
bigger than what a sensible person would input under this circumstance.]
If you are referring to my post in the thread "How to sscanf return
integer only", I wouldn't recommend it unless you have a similar goal
as the OP in that thread. The strto* functions are usually enough by
themselves for most purposes.

Indeed something more on the line of strto** is what I'm looking at. One of
the things I find hard about reading K&R is that when you look at the
appendix, the arguments appear without the development in which they made
sense. So you gotta go back and read the entire chapter, something that
cannot be done while golfing.... Joe

[Richard Heathfield]

Joe Smith said:

Mr. Heathfield, who kindly provided this code from Knuth,
No, I didn't. The code is /not/ from Knuth. Knuth describes the algorithm,
but does not implement it (at least, not as far as I am aware). The
implementation, warts and all, is my own.
and I have been
talking past each other elsewhere as I was under the impression that the
Euclidean algorithm would ultimately express two numbers as a linear
combination.

Why? Euclid's Algorithm provides the greatest common denominator of two
values. There is only /one/ greatest common denominator for any two values,
so why would you expect two numbers in your result?

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Old Wolf]

Richard Heathfield wrote:

Joe Smith said:

and I have been
talking past each other elsewhere as I was under the impression that the
Euclidean algorithm would ultimately express two numbers as a linear
combination.

Why? Euclid's Algorithm provides the greatest common denominator of two
values. There is only /one/ greatest common denominator for any two values,
so why would you expect two numbers in your result?

He may be thinking of the 'reverse Euclidean algorithm', ie.
once you have determined that g = gcd(a,b) via the Euclidean
algorithm, you can then backtrack through the steps to find
x,y such that g = ax + by.

[Old Wolf]

Old Wolf wrote:

He may be thinking of the 'reverse Euclidean algorithm', ie.
once you have determined that g = gcd(a,b) via the Euclidean
algorithm, you can then backtrack through the steps to find
x,y such that g = ax + by.

OT, but interesting: note that this lets us solve any
equation such as:

23x = 1 (mod 240)

where the 23 and the 240 are coprime (because if two
numbers are coprime then 1 is their g.c.d.).

This has an application in public key cryptography, where
once you have picked a public key 'e', the private key
'd' is specified by:

ed = 1 (mod phi(n))

(and 'e' was chosen such that e and phi(n) are coprime).

[Al Balmer]

On Sat, 6 May 2006 18:38:24 -0400, "Joe Smith"
<gr**********@netzero.net> wrote:

I'll agree that you've misstated something, because I have no idea
what you're talking about. The Arizona version of K&R is the same as
everyone else's.

--
Al Balmer
Sun City, AZ

Sorry, Al, that my little hissy fit was directed at you. I was fresh out of
a fisticuffs. My claim is that % followed by l (ell) violates the sentence
preceding Table B-1. Obviously, the Standard is relevant, and K&R talk
pedagogical. I think the sentence would be correct if it said 'if the
character after the % , and after all the optional things above, is not one
of the below characters, the behavior is undefined.' Not exactly
Shakespeare. Joe

I'm not going to quote it again, but if you reread it, you'll find
that I was not only agreeing with you, but offering proof, since I
*did* have a copy of K&R at hand.

--
Al Balmer
Sun City, AZ

[Michael Wojcik]

In article <4b*************@individual.net>, Ian Collins <ia******@hotmail.com> writes:

CBFalconer wrote:

Joe Smith wrote:

#include <stdio.h>

int main(void)
{
unsigned long gcd(unsigned long m, unsigned long n);

Apparently noone has bothered to notice that you are calling gcd
before declaring it, and that the system thus assumes gcd to return
an int.

Note the first line of main.

Though this does demonstrate one problem with putting function
declarations at block scope: even experienced programmers may miss
them when reading the code, because it's common to put them at
file scope.

And it's common to put them at file scope in part because they can't
be placed at block scope if they include the "static" sc-specifier,
which is another problem with putting them at block scope.

In sum: Joe, don't put function declarations at block scope. Put
them at file scope, thus:

#include <stdio.h>

unsigned long gcd(unsigned long m, unsigned long n);

int main(void)
{

--
Michael Wojcik mi************@microfocus.com

She felt increasingly (vision or nightmare?) that, though people are
important, the relations between them are not, and that in particular
too much fuss has been made over marriage; centuries of carnal
embracement, yet man is no nearer to understanding man. -- E M Forster

[Joe Smith]

"Michael Wojcik" <mw*****@newsguy.com> wrote in message
news:e3********@news1.newsguy.com...

In article <4b*************@individual.net>, Ian Collins
<ia******@hotmail.com> writes:

CBFalconer wrote:

> Joe Smith wrote:
>
>>#include <stdio.h>
>>
>>int main(void)
>>{
>>unsigned long gcd(unsigned long m, unsigned long n);

>
> Apparently noone has bothered to notice that you are calling gcd
> before declaring it, and that the system thus assumes gcd to return
> an int.
>

Note the first line of main.

Though this does demonstrate one problem with putting function
declarations at block scope: even experienced programmers may miss
them when reading the code, because it's common to put them at
file scope.

And it's common to put them at file scope in part because they can't
be placed at block scope if they include the "static" sc-specifier,
which is another problem with putting them at block scope.

In sum: Joe, don't put function declarations at block scope. Put
them at file scope, thus:

#include <stdio.h>

unsigned long gcd(unsigned long m, unsigned long n);

int main(void)
{

God, I knew that. They pulled five staples out of my head last year.
Cbfalconer goes nuts every time he sees it and for obvious reasons. One of
the best poems I ever wrote was about a fella named 'Wojcik'. If just so
happens to rhyme with 'fat chick' and of course "paycheck." Joe