printf headache

[Joe Smith]

[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]

"Ian Collins"


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]

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.

 

[Joe Smith]

"Martin Ambuhl"

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]

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?

 

[Joe Smith]

[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]

[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]

Joe Smith wrote:

[done and forgotten]

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.

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.

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:

[done and forgotten]

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.

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?

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]

Joe Smith wrote:
.... snip ...

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]

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.

 

[Joe Smith]

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.

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]

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?

 

[Rod Pemberton]

Arizona? Huh?

Do you read people's sig's?

 

[Al Balmer]

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.

 

[Joe Smith]

[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.

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

 

[Mark McIntyre]

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]

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?

 

[Old Wolf]

Joe Smith said:


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.