OK. LETS START REAL PROGRAMMING IN C FOR PROBLEMS!!!

[Markus Wichmann]

in "factorial *= fact_arg++;" in the loop

Depending on the type of fact_arg, that's either an overflow hazard (for
integer types) or at some point it will be a no-op (for floating point
types). Neither of these allocates memory.

As for factorial: Depending on its type, this line is either an overflow
hazard or it isn't. If factorial is floating point, this line will
propably never do anything more evil than setting it to infinity, at
which point addend will be calculated as zero.

CYA,
Markus

 

[88888 Dihedral]

Do you? Would you tell me what you know about division that the compiler
writer doesn't know?

I contribute a c function to divide a pointer to an unsigned char array with a known length that produces a remainder of the long real number.

int longreal_divide_mod5( char *longnum, int length)
{
int i;
unsinged long remainder; // 32 or 64 bits, I'll show the 32 bit version
tmp=0;

for( i=0, remainder=0;i<length;i++)
remainder+=longnum; // mod 255 done in the first pass

/*/ assume remainder won't over flow
tmp+= (remainder>>24); //top 8 bits
tmp+= ((remainder)<<8)>>24 ; // another 8 bits
tmp+= ((remainder)<<16)>>24 ; // another 8 bits
tmp+= remainder & 0xff;// final 8 bits
//4 *255<=1020 in 10 bits

while (i=tmp&512) if i { tmp^=512; tmp++};
while (i=tmp&256) if i { tmp^=256; tmp++};
// tmp in a byte now */
return tmp%5; //there is another way to avoid the mod
}

I think it is trivial to have a mod10 by using the above.

 

[Seebs]

I know that a division in C in some compiler in most CPUs is really slow. I write that in assembly.

Okay, I wasn't previously convinced that you were trolling, but now I am
convinced that you are.

This is stupid. Since some people reading won't immediately see why it's
stupid:

One possible interpretation is that you are writing a plain old division
instruction in assembly. This would be stupid, since it's exactly the same
instruction C would be executing. Furthermore, the concept of "most CPUs"
is thrown out the window the moment you start talking about assembly.
Finally, what specific CPUs are you thinking have slow division? Division
stopped being painfully slow a decade or two back.

Another is that you are hand-coding an operation as a series of steps. This
would be stupider than hand-coding a single divide operation.

You don't "know" this. You may believe it, but you're either a troll or
spectacularly stupid. And I do mean stupid, not ignorant. It's fine to not
know anything about how stuff works; most people don't know that. What's
stupid is pretending you know stuff when you don't.

-s

 

[Keith Thompson]

Lew Pitcher ha scritto: [snip]

for (p = 0; p < P; ++p)
{
e[0] = 0;
multiply(e,10,I+X);
fputc(e[0]+'0',stdout);
if (p%5 == 4)
if (p%50 == 49)

here my compiler says:

temp.c: In function ‘main’:
temp.c:50: warning: suggest explicit braces to avoid ambiguous ‘else’

The code in question is:

if (p%5 == 4)
if (p%50 == 49)
fputs("\n\t",stdout);
else
fputc(' ',stdout);

The C standard is pretty clear about the association of <<else>> to the
appropriate <<if>>For instance, in IEC 9899-1999, section 6.8.4.1 ("The if
statement"), point 3, it says:
"An else is associated with the lexically nearest preceding if that is
allowed by the syntax."

That doesn't seem very ambiguous to me.

It's not ambiguous at all as far as the language is concerned, but it
could be ambiguous to a human reader.

I suggest that your compiler's warning level is wound up too tight. I know
that compilers are permitted to emit warnings for anything they want, from
noting potential syntax errors to baying at a full moon. That doesn't mean
that the compiler doesn't know what to do with the code, or that the code
violates the C standard in any way. It just means that the compiler writer
thought that the programmer would like to know something.

I disagree. The warning is an important one. The solution (though it's
not required by the language) is to add braces:

if (p%5 == 4) {
if (p%50 == 49) {
fputs("\n\t",stdout);
}
else {
fputc(' ',stdout);
}
}

Certainly you can turn off the warning if you like, but I wouldn't (and
frankly I probably wouldn't see the warning in the first place when
compiling my own code).

[...]

 

[Lew Pitcher]

Lew Pitcher ha scritto: [snip]
for (p = 0; p < P; ++p)
{
e[0] = 0;
multiply(e,10,I+X);
fputc(e[0]+'0',stdout);
if (p%5 == 4)
if (p%50 == 49)

here my compiler says:

temp.c: In function ‘main’:
temp.c:50: warning: suggest explicit braces to avoid ambiguous ‘else’

The code in question is:

if (p%5 == 4)
if (p%50 == 49)
fputs("\n\t",stdout);
else
fputc(' ',stdout);

The C standard is pretty clear about the association of <<else>> to the
appropriate <<if>>For instance, in IEC 9899-1999, section 6.8.4.1 ("The
if statement"), point 3, it says:
"An else is associated with the lexically nearest preceding if that is
allowed by the syntax."

That doesn't seem very ambiguous to me.

It's not ambiguous at all as far as the language is concerned, but it
could be ambiguous to a human reader.

I suggest that your compiler's warning level is wound up too tight. I
know that compilers are permitted to emit warnings for anything they
want, from noting potential syntax errors to baying at a full moon. That
doesn't mean that the compiler doesn't know what to do with the code, or
that the code violates the C standard in any way. It just means thatthe
compiler writer thought that the programmer would like to know something.

I disagree. The warning is an important one. The solution (though it's
not required by the language) is to add braces:

if (p%5 == 4) {
if (p%50 == 49) {
fputs("\n\t",stdout);
}
else {
fputc(' ',stdout);
}
}

I've worked in shops that required "clean" (no errors, no warnings)
compiles. Often the programmers took very convoluted steps to ensure
compliance (granted, this was in COBOL, so compliance became very wordy).

Certainly you can turn off the warning if you like, but I wouldn't (and
frankly I probably wouldn't see the warning in the first place when
compiling my own code).

I agree that warnings are good to see. But, taking concern when the warning
warns you that the code will do /what you intended it to do/ seems just
silly to me. And, that's the point I was trying to get across (obviously,
poorly).

Of course, the programmer has (at least) three options:
1) to confirm that the warning can be ignored (because it warns about
a /wanted/ condition).
2) to ignore or disable warnings, or
3) to change the code so that the warning goes away.

In the above example code, you seem to advocate option #3.

However, I /know/ (from your past postings) that you don't believe thisin
all cases. How do I know? Well, because you regularly advocate for option
#1 or option #2 when people complain that their call to malloc() results in
a warning. You /definitely/ don't like option #3 in those cases, because in
practice it results in code that uses a cast of malloc()s return value to
eliminate the warning. You know the dangers of that sort of code fix as
much as I do.

In any case, I originally wrote that code as a learning experience, and
didn't intend it to be an example of "best practices". I, too, watch the
warnings, and evaluate the code that such messages highlight. But, I know
when to ignore warnings when they tell me that what I'm doing is what I
intended to do.

 

[James Kuyper]

On 11/28/2011 01:34 PM, Lew Pitcher wrote:
.....

I agree that warnings are good to see. But, taking concern when the warning
warns you that the code will do /what you intended it to do/ seems just
silly to me. And, that's the point I was trying to get across (obviously,
poorly).

Are you suggesting that compilers should never warn about unclear coding
practices? I could see an argument that this particular construct is not
unclear; but it doesn't seem reasonable to me to object to a warning
just because the code does what it was intended to do. If it's
unnecessarily difficult for a future programmer (or even the same
programmer, at some future time) to clearly determine a) what the code
will actually do or b) whether the designer actually intended it to do
that, then the code is unclear, whether or not it actually does what it
was intended to do.

 

[Lew Pitcher]

On 11/28/2011 01:34 PM, Lew Pitcher wrote:
....

Are you suggesting that compilers should never warn about unclear coding
practices?

Nope. I'm suggesting that programmers should not panic at the sight of
warnings; they /don't/ necessarily mean that something is wrong with the
code.

I could see an argument that this particular construct is not
unclear; but it doesn't seem reasonable to me to object to a warning
just because the code does what it was intended to do.

It's not the warning, it's the undue /concern/ that some attach to seeing
warnings.

If it's
unnecessarily difficult for a future programmer (or even the same
programmer, at some future time) to clearly determine a) what the code
will actually do or b) whether the designer actually intended it to do
that, then the code is unclear, whether or not it actually does what it
was intended to do.

Warnings take investigation. But, having investigated and found that the
code does what it is supposed to do, the investigation is complete. There's
no need to silence the warning in that case.

 

[James Kuyper]

Nope. I'm suggesting that programmers should not panic at the sight of
warnings; they /don't/ necessarily mean that something is wrong with the
code.

Well, that at least I can agree with. However, I don't think anyone
panicked about this particular warning.

It's not the warning, it's the undue /concern/ that some attach to seeing
warnings.

How much concern should be attached is debatable.

Warnings take investigation. But, having investigated and found that the
code does what it is supposed to do, the investigation is complete.

No, it is not. The warning was not only about the possibility that the
code might be wrong, but also about the possibility that it might be
unclear. Until you've also investigated the clarity of the code, the
investigation is not complete. If it does what it was supposed to do,
but was also unclear, it should be re-written to be clearer. Not because
it has to be re-written to be correct - it is correct. Not because it
will silence the warning - though it will achieve that effect. It
should be re-written just because it was unclear (and only if that is
indeed the case).

I personally don't find the dropping of optional curly brackets to be
unclear, unless the code that they would otherwise have enclosed is
fairly long; at least 5 lines, maybe 8. But I do think that the basic
principle is sound: code which does what its supposed to do in an
unclear fashion should be re-written for improved clarity (unless you're
planning to enter it in the IOCCC).

 

[Kleuske]

Warnings take investigation. But, having investigated and found that the
code does what it is supposed to do, the investigation is complete.
There's no need to silence the warning in that case.

It would be nice to leave a comment, at least and better (if it's possible
without too much trouble) to eliminate it. Not because it will make your
program better, but it may save some poor schmuck the trouble of investigating
it again. In my experience, the schuck might even be yourself, a year or two
down the line.

 

[Keith Thompson]

On November 26, 2011 06:11, in comp.lang.c, (e-mail address removed) wrote:
Lew Pitcher ha scritto:
[snip]
for (p = 0; p < P; ++p)
{
e[0] = 0;
multiply(e,10,I+X);
fputc(e[0]+'0',stdout);
if (p%5 == 4)
if (p%50 == 49)

here my compiler says:

temp.c: In function ‘main’:
temp.c:50: warning: suggest explicit braces to avoid ambiguous ‘else’

The code in question is:

if (p%5 == 4)
if (p%50 == 49)
fputs("\n\t",stdout);
else
fputc(' ',stdout);

The C standard is pretty clear about the association of <<else>> to the
appropriate <<if>>For instance, in IEC 9899-1999, section 6.8.4.1 ("The
if statement"), point 3, it says:
"An else is associated with the lexically nearest preceding if that is
allowed by the syntax."

That doesn't seem very ambiguous to me.

It's not ambiguous at all as far as the language is concerned, but it
could be ambiguous to a human reader.

I suggest that your compiler's warning level is wound up too tight. I
know that compilers are permitted to emit warnings for anything they
want, from noting potential syntax errors to baying at a full moon. That
doesn't mean that the compiler doesn't know what to do with the code, or
that the code violates the C standard in any way. It just means that the
compiler writer thought that the programmer would like to know something.

I disagree. The warning is an important one. The solution (though it's
not required by the language) is to add braces:

if (p%5 == 4) {
if (p%50 == 49) {
fputs("\n\t",stdout);
}
else {
fputc(' ',stdout);
}
}

I've worked in shops that required "clean" (no errors, no warnings)
compiles. Often the programmers took very convoluted steps to ensure
compliance (granted, this was in COBOL, so compliance became very wordy).

Certainly you can turn off the warning if you like, but I wouldn't (and
frankly I probably wouldn't see the warning in the first place when
compiling my own code).

I agree that warnings are good to see. But, taking concern when the warning
warns you that the code will do /what you intended it to do/ seems just
silly to me. And, that's the point I was trying to get across (obviously,
poorly).

Of course, the programmer has (at least) three options:
1) to confirm that the warning can be ignored (because it warns about
a /wanted/ condition).
2) to ignore or disable warnings, or
3) to change the code so that the warning goes away.

In the above example code, you seem to advocate option #3.

However, I /know/ (from your past postings) that you don't believe this in
all cases. How do I know? Well, because you regularly advocate for option
#1 or option #2 when people complain that their call to malloc() results in
a warning. You /definitely/ don't like option #3 in those cases, because in
practice it results in code that uses a cast of malloc()s return value to
eliminate the warning. You know the dangers of that sort of code fix as
much as I do.

Hmm. Warnings on calls to malloc() often result from a missing
"#include <stdlib.h>". One way to avoid the warning is to add a
cast; the *right* way is to leave the cast out and add the required
#include directive. Of course I don't advocate the first solution,
which silences the warning while leaving the program with undefined
behavior. Adding the #include is an instance of #3.

Or are you talking about some other problem with malloc() calls?

In any case, I don't have a general rule about how to deal with
warnings. There are cases where I dislike changing the code to
deal with an overly picky compiler. For example, if "do { ... }
while (0)" in a macro definition results in a warning that the
condition is always false, that's just too bad; it's the right
way to do it. Similarly, "some_complicated type obj = { 0 };"
may trigger a warning about missing initializers; that's just the
compiler being insufficiently clever in recognizing a perfectly
good idiom.

In any case, I originally wrote that code as a learning experience, and
didn't intend it to be an example of "best practices". I, too, watch the
warnings, and evaluate the code that such messages highlight. But, I know
when to ignore warnings when they tell me that what I'm doing is what I
intended to do.

My own preference would be to write

if (cond1)
if (cond2)
something;
else
something;

as

if (cond1) {
if (cond2) {
something;
}
else {
something;
}
}

*whether the compiler warns about it or not*. I use braces for
all control structures, even when they're not strictly necessary.
I'll sometimes omit the braces if the whole thing fits on one line,
but that's uncommon. (It's a habit I picked up from Perl, where
they're always required, but I think it's a good idea for C anyway.)

If I were *really* strict about this, I'd add lots of extra braces to
"if .. else if ... else if ... else ..." chains, but that's such
a common idiom that I treat them as linear rather than nested.
I do not claim to be 100% consistent.

Of course not everyone follows the same style rules I do. (Of course
*THEY SHOULD*!!!1!!!).

 

[88888 Dihedral]

Ben Bacarisseæ–¼ 2011å¹´11月22日星期二UTC+8上åˆ7時51分18秒寫é“：

Le 20/11/11 20:12, 88888 Dihedral a écrit :
PROBLEM 1: COMPUTE THE EULER'S NUMBER UP TO 30 DIGITS AFTER 1.
THE DIGIT REQUIRED SHOULD BE PARAMETER BY THE CALLER!
Euler's constant is the limit of the sum when N goes to infinity of:
1 + 1/2 + 1/3 + 1/4 + ... 1/N - ln(n)
The location of you reply suggests a connection between the article and
the series directly above it but I can't see a direct connection. The
last thing this thread needs is more confusion between e and gamma!

char const * ec( unsigned const n /* 0 <= n <= 30 */ )
{ static char result[ 33 ];
strncpy( result, "2.718281828459045235360287471352", n + 2 );
result[ n + 2 ]= 0;
return result; }

Good one! You reply to a post about the potential for confusion between
the posted series and e by posting a function to compute e.

Since this seems to be a solution to the OP, could you not have replied
to that message?

(Also, I think it's good to mark where you cut text out. Better still
is to cut anything not needed for context. You cut all of Lew's text,
to which you code *does* relate, but you left mine and Jacob's to which it
does not.)

Don't you work on RSA encoding and decoding ?

 

[Ben Bacarisse]

Don't you work on RSA encoding and decoding ?

No. I did once run a project in that area, but that was more than two
decades ago. Why do you ask?

 

[88888 Dihedral]

Ben Bacarisseæ–¼ 2011å¹´12月28日星期三UTC+8上åˆ11時09分25秒寫é“：

No. I did once run a project in that area, but that was more than two
decades ago. Why do you ask?

If there's no demand for heavy load computing,
it will be a bad time for programmers and engineers.

 

[Seebs]

Ben Bacarisse??? 2011???12???28????????????UTC+8??????11???09???25????????????

If there's no demand for heavy load computing,
it will be a bad time for programmers and engineers.

Okay, obviously you can't make a reliable diagnosis over the Internet and
all that, but this really looks schizotypal. These responses are to some
kind of internal monologue, not to other posts.

-s

 

[Dr Nick]

If there's no demand for heavy load computing,
it will be a bad time for programmers and engineers.

What makes you believe it will be a bad time for programmers and
engineers?

 

[88888 Dihedral]

Dr Nickæ–¼ 2011å¹´12月29日星期四UTC+8上åˆ2時49分16秒寫é“：

What makes you believe it will be a bad time for programmers and
engineers?

It is trivial to search a list in O(1).