[OT]"A to Z of C"
R. Rajesh Jeba Anbiah
browsing over the net costs much. We have so much of intellectuals who
cannot afford to book & Internet. Another problem is that people who
have money, steals codes from Internet and claims it as their own.
My friend and myself have decided to "serve" our society by writing a
non-profit book for "DOS programming with C". Quite honestly, we are
*not* Experts. So we have used the "public domain codes".
Many experts including Dr.DMR, Dr.Ralf Brown, Mr.Alex Russell,.....
granted permission to use their resources. We're grateful to them!
These are the terms of our book:
1. The book is for non-profit
2. It is a kind of compilation of programs. But it is not 100%
compilation.
3. Proper credits were given to the authors.
4. As it is non-profit basis, we cannot provide money to authors.
We have also successfully finished our book ("A to Z of C"). But, the
local publishers are not interested in the non-profit work. We
couldn't even publish the book ourselves as we're running out of
money...After a lot of struggle, we have contacted Wrox in the
beginning of this year. Wrox responded so positively in the inital
stage. But, till now no updates from them... So, we have decided to
place our work on the net (so that other people may benefitted). I
have only a free webspace with Freeservers. I don't know, whether it
will be reliable or not. Few of the chapters from the book is
available at http://guideme.itgo.com/atozofc/
If anyone of you have constructive criticism/any comments/knowledge in
publishing books/publishing online books, please share.
Thanks,
R. Rajesh Jeba Anbiah
---
"Success = 10% sweat + 90% tears"
Email: rrjanbiah@Y!com (Y!==yahoo.)
Arthur J. O'Dwyer
On Sat, 3 May 2003, R. Rajesh Jeba Anbiah wrote:
[...]
> available at http://guideme.itgo.com/atozofc/
>
> If anyone of you have constructive criticism/any comments/knowledge in
> publishing books/publishing online books, please share.
>
> Thanks,
> R. Rajesh Jeba Anbiah
Well, I'll just start browsing through the site from start to finish, and
tell you what I think could use fixing.
* (contents.pdf) Use proper English. Really. When I see section titles
like these,
4.1 Myth & Mistakes
4.2 Tips for better Programming
4.2.3 How to code better?
13.1 Where to contest?
it just makes me think that I'd better prepare for a rough ride.
* (ch02.pdf) Use proper English. Seriously. The first paragraph is all
messed up. Fixed: "C is often referred to as a 'systems programming
language' because it is used for writing compilers, editors, and even
operating systems. C was developed and implemented on the UNIX operating
system on the DEC PDP-11, by Dennis M. Ritchie. It evolved in 1971-73
from the B language created by Ken Thompson, which evolved (in 1969-70)
from Martin Richards' language BCPL." And this paragraph is _still_
awkward!
* (ch02.pdf) Your "Timeline" table displays without a bottom bar on page
1. And of course it's got a lot of spelling and grammar errors, but I'm
tired of correcting those.
* (ch03.pdf) Your example of Indian Hill style seems to have a mistake:
I think the 'int' in front of 'foo' should be aligned vertically with
'foo', not indented by one space.
* (ch03.pdf) While it's tempting to flaunt your own particular coding
style in your own publication, I doubt you'll find many programmers who
will agree with all of your style's decrees. (The StudlyCaps naming
convention for functions seems weird to me, for example.) So it doesn't
really seem worth it to make style such a big part of your book. I'd
spend only a page or so explaining the basic style *conventions* (not
guidelines) in use today. Things like:
Consistent indentation.
Use of ALL_CAPS for #defined macros.
The suffix _t to indicate a typedef'd type.
Proper prototypes for functions.
Include guards, and how *not* to name them.
Not putting parentheses with 'return' (as you seem to do).
The correct interpretation of 'while (n--)' and other idioms.
The infinite loop 'for(;;)'.
* (ch09.pdf) 9.3: Your GCD (Greatest Common *Divisor*) algorithm only
works for positive a,b, and crashes if b is zero.
* (ch09.pdf) 9.4: Dispose with the amazed tone. It's not like you've
never seen an exponentiation routine before. And given exp() and
log10(), I think nobody's ever going to use a user-defined exponentiation
routine in real code anyway. Also, crashes if x==0, n<0. Even if
you don't fix the problem, you should point out somewhere that it
exists, and warn the user not to call these functions with invalid
input.
* (ch09.pdf) 9.5: getchar() returns 'int'.
9.7: An array of single-character strings is overkill.
Rewrite this function. Preferably, to use
printf("%X", n);
9.8: Don't you think three nearly-identical functions
is enough?
And now I have to go, but I'll look at the rest (of the C-related
stuff, anyway) sometime soon.
-Arthur
CBFalconer
> On Sat, 3 May 2003, R. Rajesh Jeba Anbiah wrote:
> [...]
> > available at http://guideme.itgo.com/atozofc/
> >
> > If anyone of you have constructive criticism/any comments/knowledge
> > in publishing books/publishing online books, please share.
>
> finish, and tell you what I think could use fixing.
>
> * (contents.pdf) Use proper English. Really. When I see section
> titles like these,
>
> 4.1 Myth & Mistakes
> 4.2 Tips for better Programming
> 4.2.3 How to code better?
> 13.1 Where to contest?
>
> it just makes me think that I'd better prepare for a rough ride.
>
> * (ch02.pdf) Use proper English. Seriously. The first paragraph
If he puts everything up in .pdf files the results are extremely
awkward for browsing, and much bigger than needed. html files, if
validated, are better. They adapt to the users screen or printer
page dimensions, and lose virtually nothing. The minor penalty is
that some diagrams have to be supplied as jpgs (don't use gif).
--
Chuck F (cbfal...@yahoo.com) (cbfal...@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
John Doe
> all messed up. Fixed: "C is often referred to as a 'systems
> programming language' because it is used for writing compilers,
> editors, and even operating systems. C was developed and implemented
> on the UNIX operating system on the DEC PDP-11, by Dennis M. Ritchie.
> It evolved in 1971-73 from the B language created by Ken Thompson,
> which evolved (in 1969-70) from Martin Richards' language BCPL." And
> this paragraph is _still_ awkward!
There's really too much information crammed into such a short space.
> * (ch02.pdf) Your "Timeline" table displays without a bottom bar on
> page
> 1. And of course it's got a lot of spelling and grammar errors, but
> I'm tired of correcting those.
The last entry in this timeline is somewhat troubling. It states that the
book was created due to dissatisfaction with other books, while in you
original post you claim this is really a more noble reason. Why not state
this in your book?
These were some of you style guidelines:
> Include guards, and how *not* to name them.
Indulge me ;) Seriously...
> Not putting parentheses with 'return' (as you seem to do).
Why not? What is the reason behind this?
> The infinite loop 'for(;;)'.
What is the "advantage" of using the for construct over "while (1)"?
Thanks for the help,
--
Martijn Haak
http://www.sereneconcepts.nl
--- why did the chicken cross the moebius strip? -----
------------------- to get to the other ... er, um ---
John Doe
10.2
- calculating the square root of n (sqrt(n)) only once will be much more
efficient
- the text gives the idea this is _the_ efficient implementation, while more
effecient routines exist (especially for larger numbers), e.g.
http://www.cse.iitk.ac.in/news/primality.html
- to quote arthur: "use proper english" :)
- using goto and break wisely isn't bad programming practice (IMHO)
10.3
- you should change the for-loop to prevent it from being able to go beyond
the array (when someone enters a number greater than or equal to 9999, e.g.
when someone accidentaly types 40000 instead of 4000)
10.5
- the indentation is truly abominable on this one
Time for me to go nighty-nighty...
Good luck!
Emmanuel Delahaye
> I'd
> spend only a page or so explaining the basic style *conventions* (not
> guidelines) in use today. Things like:
>
> Consistent indentation.
Ok.
> Use of ALL_CAPS for #defined macros.
No. ALL_CAPS are for constant. (enum or macros)
function style macros will follow the current functions naming convention.
> The suffix _t to indicate a typedef'd type.
Well, '_t' is reserved by Posix. I prefer to stay clear and use
'_s' for typedef'ed structures
'_e' for typedef'ed enums
'_u' for typedef'ed unions
'_a' for typedef'ed arrays (but I don't use them)
> Proper prototypes for functions.
Ok.
> Include guards, and how *not* to name them.
Ok.
H_xxx
> Not putting parentheses with 'return' (as you seem to do).
> The correct interpretation of 'while (n--)' and other idioms.
> The infinite loop 'for(;;)'.
Ok.
- The 'reduce scope' policy :
- Project
-- Functionnal unit
--- Compilation unit
---- Function
----- Bloc
- The 'G_' prefix for global (if you insist to have globals)
--
-ed- emdel at noos.fr
The C-language FAQ: http://www.eskimo.com/~scs/C-faq/top.html
C-library: http://www.dinkumware.com/htm_cl/index.html
FAQ de f.c.l.c : http://www.isty-info.uvsq.fr/~rumeau/fclc/
Kevin Easton
> In 'comp.lang.c', "Arthur J. O'Dwyer" <a...@andrew.cmu.edu> wrote:
>
>> I'd
>> spend only a page or so explaining the basic style *conventions* (not
>> guidelines) in use today. Things like:
>>
>> Consistent indentation.
> Ok.
>> Use of ALL_CAPS for #defined macros.
>
> No. ALL_CAPS are for constant. (enum or macros)
>
> function style macros will follow the current functions naming convention.
It is a good idea to use ALL_CAPS() for function-style macros if they
may evaluate their argument(s) more than once. If they don't, I don't
think it matters.
- Kevin.
Arthur J. O'Dwyer
On Sun, 4 May 2003, John Doe wrote:
>
> These were some of you style guidelines:
>
> > Include guards, and how *not* to name them.
>
> Indulge me ;) Seriously...
For example, *don't* use the same naming style that you see in
your compiler's <stdio.h> file. That will probably look like this:
#ifdef __STDIO_H_
but you should never ever prefix your identifiers with underscores;
that's dangerous because some such identifiers are reserved by the
Standard. (I remember that double-underscored names are always reserved;
I don't recall about single-underscored ones.)
Some people suggest
#ifdef H_MYHEADER
while I prefer
#ifdef MYHEADER_H
(which is why I didn't suggest telling the reader how *to* name them,
just how *not* to name them. It's a religious issue IMHO).
> > Not putting parentheses with 'return' (as you seem to do).
>
> Why not? What is the reason behind this?
They're unnecessary, and they make 'return' look like a function call
(which it isn't).
> > The infinite loop 'for(;;)'.
>
> What is the "advantage" of using the for construct over "while (1)"?
Some optimizing compilers may recognize the 'for(;;)' loop more readily
than the 'while(1)', 'while(1==1)', 'while(0!=1)' variants. If I were
writing a compiler, that's the way I'd do it, because I'm lazy. :)
-Arthur
Arthur J. O'Dwyer
On Sun, 4 May 2003, Emmanuel Delahaye wrote:
>
> In 'comp.lang.c', "Arthur J. O'Dwyer" <a...@andrew.cmu.edu> wrote:
>
> > The suffix _t to indicate a typedef'd type.
>
> Well, '_t' is reserved by Posix.
Hmm. I didn't know that (I'm not a Posix programmer). But even if
you shouldn't advocate using _t in new code, it should still be pointed
out that many existing C programs use the _t suffix to indicate types
(and that if you see foo_t in code, that's probably what it means).
> I prefer to stay clear and use
>
> '_s' for typedef'ed structures
> '_e' for typedef'ed enums
> '_u' for typedef'ed unions
> '_a' for typedef'ed arrays (but I don't use them)
Smacks of Hungarian notation. If you're typedeffing the data type
anyway, shouldn't it (usually) be an ADT? So you shouldn't care what
sort of data structure it contains?
> - The 'reduce scope' policy :
>
> - Project
> -- Functionnal unit
> --- Compilation unit
> ---- Function
> ----- Bloc
To a point. I tend to look down on coders who write brace-ful code like
this (disregarding the other bad style issues introduced by my desire to
make the example fit in twenty lines):
int foo(int n)
{
int *a = malloc(n*sizeof *a);
int count;
{
int done=0;
for (count=0; count<n && !done; ++count)
read(&a[count], &done);
}
{
int i, l=0;
for (i=0; i<count; i++)
l += process(&a[i]);
printf("l = %d\n", l);
}
}
> - The 'G_' prefix for global (if you insist to have globals)
No, that's another of those "My Personal Style" things. I certainly
wouldn't write code that used prefixes for every global variable.
My personal style is to use StudlyCaps for globals, abbrlowercase
for locals, and abbr_underscored_lwrcase() for functions. But I know
better than to recommend that style to anyone else. :)
-Arthur
Kevin Easton
>>
>> These were some of you style guidelines:
>>
>> > Include guards, and how *not* to name them.
>>
>> Indulge me ;) Seriously...
>
> For example, *don't* use the same naming style that you see in
> your compiler's <stdio.h> file. That will probably look like this:
>
> #ifdef __STDIO_H_
>
> but you should never ever prefix your identifiers with underscores;
> that's dangerous because some such identifiers are reserved by the
> Standard. (I remember that double-underscored names are always reserved;
> I don't recall about single-underscored ones.)
Underscore followed by an uppercase letter or another underscore
are reserved. That's why the new types in C99 are named _Bool, _Complex
etc. - because that's in the implementation's reserved namespace.
> Some people suggest
>
> #ifdef H_MYHEADER
>
> while I prefer
>
> #ifdef MYHEADER_H
>
> (which is why I didn't suggest telling the reader how *to* name them,
> just how *not* to name them. It's a religious issue IMHO).
The reason that the former is preferred is that identifiers starting
with uppercase E are reserved, so you can't name your header files
anything starting with `e' under your scheme.
- Kevin.
R. Rajesh Jeba Anbiah
suggestions...
First of all, my first language is not english. I'm not an expert
in grammars. Few people have worked on the material. But, it seems
they couldn't even make it better... Here in India, the correct
english is really problem as we have AmE, CaE, BrE...
Most of you have suggested corrections. As I don't have a personal
computer, immediate correction is a problem for me. If anyone of you
is interested in improving the standard of the book, I can give the
whole material. I also heard that Linux was also improved by internet
people....But, being an illiterate about those technologies, I don't
know how they achieved it---where to put the material---how to form
such community, etc.
Regarding indentation & formatting.... it's actually a problem of
Mircrosoft Word. Initial document was prepared with Word 2000 in our
college lab. The table support & line diagrams are really messy in
Word 2000. But, even then we could be able to achieve the layout we
actually wanted. Later for few corrections on the document, we've
opened the file in Word XP of my friend's system. Word XP messed up a
lot--fonts have changed--tables have scrambled, etc. So, it's a
problem of Word XP. If you look at the original document, you can find
it.
Another thing is our target audience was Indians & the user level
of the book is intermediate. IMO, intermediate Indian C programmers
have the ability to grab the logic of programs. So, we'd thought that
it would be a waste of time to include comments on "range of inputs &
outputs", side-effects, etc
Once again, thanks a lot for all your support!
R. Rajesh Jeba Anbiah
> If he puts everything up in .pdf files the results are extremely
> awkward for browsing, and much bigger than needed. html files, if
> validated, are better. They adapt to the users screen or printer
> page dimensions, and lose virtually nothing.
I couldn't find any better way of converting Word documents to
HTML files. Even though Word has "save as html" option, the generated
code is somewhat messy. And there is no option to save specified
number of pages say, for example 1-10. Also, there is no option to
include header & footer. That's why I've preferred PDF. PDF provides
book like appearance, provides single file & also, preserve
formatting.
>The minor penalty is
> that some diagrams have to be supplied as jpgs (don't use gif).
Couldn't understand the reason.
Thanks for the comment.
---
"Success = 10% sweat + 90% tears"
Email: rrjanbiah-at-Y!com (Y!==yahoo.)
R. Rajesh Jeba Anbiah
> Well, I'll just start browsing through the site from start to finish, and
> tell you what I think could use fixing.
Thanks a lot for your great comments.
> * (contents.pdf) Use proper English. Really. When I see section titles
> like these,
>
> 4.1 Myth & Mistakes
> 4.2 Tips for better Programming
> 4.2.3 How to code better?
> 13.1 Where to contest?
>
> it just makes me think that I'd better prepare for a rough ride.
I apoligize my poor english. In Tamil, we can break some grammar
rules. But, in english it seems that it cannot be. Our aim was to
provide a friendly book which doesn't have any formal words. But, in
english it seems that it is not allowed...
> * (ch02.pdf) Use proper English. Seriously. The first paragraph is all
> messed up. Fixed: "C is often referred to as a 'systems programming
> language' because it is used for writing compilers, editors, and even
> operating systems. C was developed and implemented on the UNIX operating
> system on the DEC PDP-11, by Dennis M. Ritchie. It evolved in 1971-73
> from the B language created by Ken Thompson, which evolved (in 1969-70)
> from Martin Richards' language BCPL." And this paragraph is _still_
> awkward!
Thanks for correcting the passage.
> * (ch02.pdf) Your "Timeline" table displays without a bottom bar on page
It's actually a problem of Word XP.
> 1. And of course it's got a lot of spelling and grammar errors, but I'm
> tired of correcting those.
>
> * (ch03.pdf) Your example of Indian Hill style seems to have a mistake:
> I think the 'int' in front of 'foo' should be aligned vertically with
> 'foo', not indented by one space.
Again, It's actually a problem of Word XP.
> * (ch03.pdf) While it's tempting to flaunt your own particular coding
> style in your own publication, I doubt you'll find many programmers who
> will agree with all of your style's decrees. (The StudlyCaps naming
> convention for functions seems weird to me, for example.) So it doesn't
> really seem worth it to make style such a big part of your book. I'd
> spend only a page or so explaining the basic style *conventions* (not
> guidelines) in use today. Things like:
>
> Consistent indentation.
> Use of ALL_CAPS for #defined macros.
> The suffix _t to indicate a typedef'd type.
> Proper prototypes for functions.
> Include guards, and how *not* to name them.
> Not putting parentheses with 'return' (as you seem to do).
> The correct interpretation of 'while (n--)' and other idioms.
> The infinite loop 'for(;;)'.
If it's wrong, I apologize. For me, the stuglycase is still convincing
as it could differentiate the user function with inbuilt function.
> * (ch09.pdf) 9.3: Your GCD (Greatest Common *Divisor*) algorithm only
> works for positive a,b, and crashes if b is zero.
>
> * (ch09.pdf) 9.4: Dispose with the amazed tone. It's not like you've
> never seen an exponentiation routine before. And given exp() and
> log10(), I think nobody's ever going to use a user-defined exponentiation
> routine in real code anyway. Also, crashes if x==0, n<0. Even if
> you don't fix the problem, you should point out somewhere that it
> exists, and warn the user not to call these functions with invalid
> input.
Agreed. But, the main idea is to provide the logic. I know, no one
will use user-defined functions.
> * (ch09.pdf) 9.5: getchar() returns 'int'.
Is it a bug? Can't we assign int to char?
> 9.7: An array of single-character strings is overkill.
> Rewrite this function. Preferably, to use
> printf("%X", n);
> 9.8: Don't you think three nearly-identical functions
> is enough?
Ok. Thanks for the comments.
> And now I have to go, but I'll look at the rest (of the C-related
> stuff, anyway) sometime soon.
Sure. Thanks a lot.
---
"Success = 10% sweat + 90% tears"
Email: rrjanbiah-at-Y!com (Y!==yahoo.)
CBFalconer
>
> > If he puts everything up in .pdf files the results are extremely
> > awkward for browsing, and much bigger than needed. html files, if
> > validated, are better. They adapt to the users screen or printer
> > page dimensions, and lose virtually nothing.
>
> I couldn't find any better way of converting Word documents to
> HTML files. Even though Word has "save as html" option, the generated
> code is somewhat messy. And there is no option to save specified
> number of pages say, for example 1-10. Also, there is no option to
> include header & footer. That's why I've preferred PDF. PDF provides
> book like appearance, provides single file & also, preserve
> formatting.
>
> >The minor penalty is
> > that some diagrams have to be supplied as jpgs (don't use gif).
>
> Couldn't understand the reason.
gifs use patented technology, specifically LZW encoding. There
are better formats, although probably png is the optimum for
avoiding patent/copyright problems.
As to Word/pdf, if the material is your own consider moving to
info source format (txi ?). That allows generating info pages,
html, LaTex, postscript, and plain text. All open source.
R. Rajesh Jeba Anbiah
Thanks for your comments.
> There's really too much information crammed into such a short space.
Couldn't understand, in which sense (positive/negative) you are
telling..
> The last entry in this timeline is somewhat troubling. It states that the
> book was created due to dissatisfaction with other books, while in you
> original post you claim this is really a more noble reason. Why not state
> this in your book?
If I understand right, you are blaming that there is a
contradiction in the statements?? But, *honestly* I don't find any
differences. We have lot of books that priced higher & don't
acknowledge the real authors of the snippets. That's why we have
dissatisfaction. Couldn't still understand whether it has any 3rd
meaning... BTW, I will upload the chapter-1 soon, which has the FAQ
about the book...
Thanks for the feed.
---
"Success = 10% sweat + 90% tears"
Email: rrjanbiah-at-Y!com (Y!==yahoo.)
R. Rajesh Jeba Anbiah
> Some more comments:
>
> 10.2
> - calculating the square root of n (sqrt(n)) only once will be much more
> efficient
> - the text gives the idea this is _the_ efficient implementation, while more
> effecient routines exist (especially for larger numbers), e.g.
> http://www.cse.iitk.ac.in/news/primality.html
Thanks for the point. But, what we meant is the handling of
boolean. There's lot of implementations that use goto, break &
continue. So, comparing to that it is efficient.
> - to quote arthur: "use proper english" :)
> - using goto and break wisely isn't bad programming practice (IMHO)
I'm not an expert. But, still it's hard to persuade me the use of
goto & break, as there is a better way of writing the code.
> 10.3
> - you should change the for-loop to prevent it from being able to go beyond
> the array (when someone enters a number greater than or equal to 9999, e.g.
> when someone accidentaly types 40000 instead of 4000)
Ok
> 10.5
> - the indentation is truly abominable on this one
Ok.
Thanks a lot for your comments!
---
"Success = 10% sweat + 90% tears"
Email: rrjanbiah-at-Y!com (Y!==yahoo.)
Jeremy Yallop
> It is a good idea to use ALL_CAPS() for function-style macros if they
> may evaluate their argument(s) more than once. If they don't, I don't
> think it matters.
I'd be inclined to use the all-caps convention in any case. Macros
are fundamentally different to functions: they may modify argumenets,
the sequence point behaviour is different and there are no "macro
pointers".
Jeremy.
Dan Pop
>My friend and myself have decided to "serve" our society by writing a
>non-profit book for "DOS programming with C". Quite honestly, we are
>*not* Experts. So we have used the "public domain codes".
Your society would be better served by if you dropped the "DOS " prefix
from your title and adjust the book's contents accordingly.
Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan...@ifh.de
pete
>
> >
>
> Is it a bug? Can't we assign int to char?
It is normal practice to check the return value from getchar for EOF,
which you can't do if ch is of type char.
putchar() also takes an int type as an argument.
There's is nothing in ReverseChar() which suggests
that char as a good choice for variable type.
It is good to match up types when comparing or assigning.
--
pete
Arthur J. O'Dwyer
On Mon, 5 May 2003, R. Rajesh Jeba Anbiah wrote:
>
> "Arthur J. O'Dwyer wrote:
> > and tell you what I think could use fixing.
>
> Thanks a lot for your great comments.
>
> > * (contents.pdf) Use proper English. Really. When I see section titles
> > like these,
> >
> > 4.1 Myth & Mistakes
> > 4.2 Tips for better Programming
> > 4.2.3 How to code better?
> > 13.1 Where to contest?
> >
> > it just makes me think that I'd better prepare for a rough ride.
>
> rules. But, in [E]nglish it seems [that] cannot be. Our aim was to
> provide a friendly book which doesn't have any formal words. But, in
You can still use small words; that's a concept that we call "register" --
how many big words you use. But it's still important to put those words
together in the right way. Plurals, capitalization, correct spelling,
correct grammar -- it's all important. Your section titles might
correctly have read:
4.1 Myths and Mistakes
4.2 Tips for Better Programming
4.2.3 How to Code Better
13.1 Contests
> > * (ch03.pdf) Your example of Indian Hill style seems to have a mistake:
> > I think the 'int' in front of 'foo' should be aligned vertically with
> > 'foo', not indented by one space.
>
> Again, [it's] actually a problem of Word XP.
Well, I'd say it's a fairly major one, given that the whole point of that
section was to demonstrate a particular coding style's use of indentation.
> > * (ch03.pdf) While it's tempting to flaunt your own particular coding
> > style in your own publication, I doubt you'll find many programmers who
> > will agree with all of your style's decrees. (The StudlyCaps naming
> > convention for functions seems weird to me, for example.) So it doesn't
> > really seem worth it to make style such a big part of your book. I'd
> > spend only a page or so explaining the basic style *conventions* (not
> > guidelines) in use today. Things like:
> >
> > Consistent indentation.
> > Use of ALL_CAPS for #defined macros.
> > The suffix _t to indicate a typedef'd type.
> > Proper prototypes for functions.
> > Include guards, and how *not* to name them.
> > Not putting parentheses with 'return' (as you seem to do).
> > The correct interpretation of 'while (n--)' and other idioms.
> > The infinite loop 'for(;;)'.
>
> If it's wrong, I apologize. For me, the stuglycase is still convincing
> as it could differentiate the user function with inbuilt function.
Why would anybody care whether a function was user-defined or not?
All functions in C behave the same way; there's no difference between
the standard library's strcpy() function and someone else's my_strcpy()
function. So there's no need to differentiate them on that account.
And if it's a maintenance issue ("Here I have function StrDup -- I must
have written that one myself; it's not a standard function,") I don't
think that capitalization plays all that important a role in the
identifier-recognition part of my brain. :)
My main point, though, was that *because* nobody's ever going to agree on
style issues, it's simply not a good idea to waste space in your book by
making style guidelines that nobody will ever follow. At best, people
with other styles will pay no attention; at worst, they'll laugh at you
and put down the book.
> > * (ch09.pdf) 9.3: Your GCD (Greatest Common *Divisor*) algorithm only
> > works for positive a,b, and crashes if b is zero.
> >
> > * (ch09.pdf) 9.4: Dispose with the amazed tone. It's not like you've
> > never seen an exponentiation routine before. And given exp() and
> > log10(), I think nobody's ever going to use a user-defined exponentiation
> > routine in real code anyway. Also, crashes if x==0, n<0. Even if
> > you don't fix the problem, you should point out somewhere that it
> > exists, and warn the user not to call these functions with invalid
> > input.
>
> Agreed. [But] the main idea is to provide the logic. [I know] no one
> will use [these] functions.
But the logic you provided was incomplete! You didn't account for all
the cases where one argument was negative, or another was zero. And
if you're expecting to train real programmers on this book, you'd better
get good documentation habits ingrained early.
> > * (ch09.pdf) 9.5: getchar() returns 'int'.
>
> Is it a bug? Can't we assign int to char?
Not without loss of information. What if getchar() returned EOF?
> > 9.7: An array of single-character strings is overkill.
> > Rewrite this function. Preferably, to use
> > printf("%X", n);
> > 9.8: Don't you think three nearly-identical functions
> > is enough?
>
> Ok. Thanks for the comments.
>
> > And now I have to go, but I'll look at the rest (of the C-related
> > stuff, anyway) sometime soon.
>
> Sure. Thanks a lot.
You're welcome.
-Arthur
Arthur J. O'Dwyer
On Mon, 4 May 2003, R. Rajesh Jeba Anbiah wrote:
>
> Thanks a lot to all the people who provided their comments &
> suggestions...
>
> in grammars. Few people have worked on the material. [But] it seems
> they couldn't even make it better... Here in India, [correct]
> [E]nglish is really problem as we have AmE, CaE, BrE...
American, Canadian, and British English differ very slightly in the
fundamentals. For example, they all capitalize proper names like
"English," they all use the same grammatical forms, and they all
conjugate verbs the same way. There are minor spelling differences
(is it still spelled "programme" in British?), but as long as you're
reasonably consistent, nobody will mind.
> Most of you have suggested corrections. As I don't have a personal
> computer, immediate correction is a problem for me. If anyone of you
> is interested in improving the standard of the book, I can give the
> whole material. I also heard that Linux was also improved by internet
> people....But, being an illiterate about those technologies, I don't
> know how they achieved it---where to put the material---how to form
> such community, etc.
If you want to retain control over the material, you might be best off
just posting the entire book on your own website (in HTML) with a form
at the bottom for people to enter corrections. Those whom you trust
can be given a password to change the pages directly.
For a project of this kind, it might be better just to put the entire
thing up on a Wiki site (use Google to find some examples) and then let
anyone who cares make their own changes.
And of course if you have a good enough product, it will eventually
circulate enough that most of the bugs will get fixed by themselves
(compare the Jargon File, HAKMEM, etc). But you'll need a good enough
product first. ;)
> Regarding indentation & formatting.... it's actually a problem of
> Mircrosoft Word. Initial document was prepared with Word 2000 in our
> college lab. The table support & line diagrams are really messy in
> Word 2000. But, even then we could be able to achieve the layout we
> actually wanted. Later for few corrections on the document, we've
> opened the file in Word XP of my friend's system. Word XP messed up a
> lot--fonts have changed--tables have scrambled, etc. So, it's a
> problem of Word XP. If you look at the original document, you can find
> it.
Quick fix: save as HTML, and then run an HTML beautifier on the source.
Search Google for "html beautifier" to find a bunch of those.
Less quick fix: convert the project to an open-source format (so the
Real Programmers can look at it) and post the original source to the
Web as well as PDF and HTML versions. Any Real Programmers who don't
care for the HTML version can download the original source and create
their own PostScript, DVI, or whatever.
> Another thing is our target audience was Indians & the user level
> of the book is intermediate. IMO, intermediate Indian C programmers
> have the ability to grab the logic of programs. So, we'd thought that
> it would be a waste of time to include comments on "range of inputs &
> outputs", side-effects, etc
You'd be surprised how many "intermediate" programmers don't know the
next thing about logic. And again on the English: if you're not writing
for native English speakers, would it perhaps be better to write in your
(shared?) native language? You wouldn't get technical feedback from a
lot of English-speaking people, but you wouldn't get grammar feedback
either.
HTH,
-Arthur
Emmanuel Delahaye
> Some people suggest
>
> #ifdef H_MYHEADER
>
> while I prefer
>
> #ifdef MYHEADER_H
This was discussed here before. The reason is that an identifier starting
with H is always valid.
My name being Emmanuel Delahaye, it means that my initials are ED.
If I write
#ifdef ED_HEADER_H
I'm cooked, because identifiers starting with E[A-Z] are reserved for
extensions of the E-codes (Error code like ERANGE and the like).
but
#ifdef H_ED_HEADER
#ifdef H_ENRON_HEADER
are fine at any time.
Arthur J. O'Dwyer
On Sat, 3 May 2003, Arthur J. O'Dwyer wrote:
> On Sat, 3 May 2003, R. Rajesh Jeba Anbiah wrote:
[...]
> And now I have to go, but I'll look at the rest (of the C-related
> stuff, anyway) sometime soon.
More comments:
ch10.pdf (10.1): This is not a reason to choose C; it's a reason to
choose assembler. The macro you supply is not guaranteed to work in
C, even if you fix the syntax error (not enough closing parentheses.
(For those who want to comment further, this is a reference to the
old chestnut
#define ISPOWOF2( n ) ( ! ( n & ( n-1 ) )
ch10.pdf (10.2): This is a very inefficient prime-number checker.
For one thing, you're calculating sqrt((double)n) every single time
through the loop. For another, you're checking for divisibility
by 2, 4, 6, 8, 10..., when it's obvious that you don't need to
check any even numbers except 2 (which should be done with the %
operator, not the & operator, BTW - I don't see any reason to fiddle
with bits here). Finally, the whole 'flag' variable is just silly.
I don't care if you think it's "good programming" to avoid break
statements - that's what C uses them for, and if you don't like it,
you might consider using Pascal. (It probably slows your code down,
too.)
ch10.pdf (10.7.1): You wrote "(here we get ab)" when you probably meant
"(here we get atemp)". You might want to consider what would happen
were the user to call swap(int, i, f). How could you fix this problem?
And your XOR version, while avoiding the usual UB, still has more bugs
than the sensible version. Besides, you've already celebrated your
L33Tness in section 10.6 - no need to repeat yourself here.
ch10.pdf (Projects): I'm sure that at least Dennis Ritchie and Brian
Kernighan have solved all the problems in K&R. I wouldn't be surprised
if Richard Heathfield has done most of 'em, too. (Who's the one with
all the solutions on his web page?)
ch11.pdf: Why have a one-page chapter that doesn't say anything? At
the least, you should present a quine program written in pure ISO C
(I can send you one if you like); you should explain why you think this
sort of thing is important (code-data equivalence, perhaps?); you might
refer the interested reader to Ken Thompson's ACM lecture or to another
good source of quine-related puzzles.
Quines *are* a lot of fun, but why waste time with trivial ASCII-based
examples when there are much more fundamental ways to create them?
-Arthur
Alan Balmer
<a...@andrew.cmu.edu> wrote:
>> [E]nglish is really problem as we have AmE, CaE, BrE...
>
>American, Canadian, and British English differ very slightly in the
>fundamentals.
Oh. I thought that second one was "California English" :-)
--
Al Balmer
Balmer Consulting
removebalmerc...@att.net
R. Rajesh Jeba Anbiah
> On Sat, 3 May 2003, Arthur J. O'Dwyer wrote:
> > On Sat, 3 May 2003, R. Rajesh Jeba Anbiah wrote:
> > > http://guideme.itgo.com/atozofc/
> [...]
> > And now I have to go, but I'll look at the rest (of the C-related
> > stuff, anyway) sometime soon.
>
> More comments:
Thanks a lot for your great comments.
Regarding Prime number... the original page reads:
BOOLEAN IsPrime( int n ) /* checks for prime */
{
int i;
BOOLEAN flag = ( i>1 );
for( i=2 ; flag && i<=sqrt(n) ; ++i )
flag = ( n%i );
return( flag );
} /*--IsPrime( )--------*/
There's one logical error in the above (not sure, how it
happened):
BOOLEAN flag = ( i>1 );
It should rather read:
BOOLEAN flag = ( n>1 );
Now, the fixed version:
BOOLEAN IsPrime( int n ) /* checks for prime */
{
int i;
BOOLEAN flag = ( n>1 );
for( i=2 ; flag && i<=sqrt(n) ; ++i )
flag = ( n%i );
return( flag );
} /*--IsPrime( )--------*/
> ch10.pdf (10.2): This is a very inefficient prime-number checker.
Ok
> For one thing, you're calculating sqrt((double)n) every single time
> through the loop.
Agreed.
>For another, you're checking for divisibility
> by 2, 4, 6, 8, 10..., when it's obvious that you don't need to
> check any even numbers except 2
No. The loop seems to be ok & it executes only once when the no.
is divisible by 2.
>(which should be done with the %
> operator, not the & operator, BTW - I don't see any reason to fiddle
> with bits here).
I have used only the % operator, not the '&'
>Finally, the whole 'flag' variable is just silly.
> I don't care if you think it's "good programming" to avoid break
> statements - that's what C uses them for, and if you don't like it,
> you might consider using Pascal. (It probably slows your code down,
> too.)
Thanks for your comments. Here, the network is mucking
up...Shortly, I'll respond to your other comments.
---
"I don't believe in the God who doesn't give me food, but shows me
heaven"---Swami Vivekananda
Email: rrjanbiah-at-Y!com (Y!==yahoo.)
Arthur J. O'Dwyer
On Wed, 7 May 2003, R. Rajesh Jeba Anbiah wrote:
>
> "Arthur J. O'Dwyer" wrote:
>
> > > On Sat, 3 May 2003, R. Rajesh Jeba Anbiah wrote:
> > > > http://guideme.itgo.com/atozofc/
>
[re: prime number checker]
> BOOLEAN IsPrime( int n ) /* checks for prime */
> {
> int i;
> BOOLEAN flag = ( n>1 );
> for( i=2 ; flag && i<=sqrt(n) ; ++i )
> flag = ( n%i );
> return( flag );
> } /*--IsPrime( )--------*/
>
> > ch10.pdf (10.2): This is a very inefficient prime-number checker.
> > For one thing, you're calculating sqrt((double)n) every single time
> > through the loop.
>
> Agreed.
The solution is to pull the calculation outside of the loop.
> >For another, you're checking for divisibility
> > by 2, 4, 6, 8, 10..., when it's obvious that you don't need to
> > check any even numbers except 2
>
> No. The loop seems to be ok & it executes only once when the no.
> is divisible by 2.
But when the number is divisible only by 99991 (i.e., is not divisible
by 2), your loop checks it for divisibility by twice as many numbers as
necessary. Solution: check for divisibility by 2 separately, and then
check all the odd numbers.
> >(which should be done with the %
> > operator, not the & operator, BTW - I don't see any reason to fiddle
> > with bits here).
>
> I have used only the % operator, not the '&'
Yes, but I was fairly sure that you'd (1) figure out the algorithm I
was suggesting on your own; and (2) try to implement it thinking that
(n&1) would be equal to (n%2), which might not quite be the case.
Unfortunately, you didn't get past (1), so my comment didn't make
sense to you.
> > Finally, the whole 'flag' variable is just silly.
> > I don't care if you think it's "good programming" to avoid break
> > statements - that's what C uses them for, and if you don't like it,
> > you might consider using Pascal. (It probably slows your code down,
> > too.)
The fixed code I'm suggesting looks like this:
int IsPrime ( int n ) /* checks for prime */
{
int i;
int limit;
if (n <= 1) return 0;
if (n <= 3) return 1;
if (n % 2 == 0) return 0;
limit = (int) sqrt(n);
for (i=3; i <= limit; i+=2)
if (n % i == 0)
return 0;
return 1;
}
HTH,
-Arthur
R. Rajesh Jeba Anbiah
My sincere thanks to all the people who answered in this thread.
I need permission to use your comments. And I will contact you
personally sometime (in the end of this month).
Once again, thanks a lot for your comments, support & time.
---
"Belive it or not, patriotism is one of the dividing forces"
Email: rrjanbiah-at-Y!com
Mike Wahler
news:abc4d8b8.03051...@posting.google.com...
> I appologize my poor response. I couldn't respond immediately.
>
> My sincere thanks to all the people who answered in this thread.
> I need permission to use your comments.
Anything posted here, unless specifically marked otherwise,
is in the 'public domain' and does not require anyone's
permission to reproduce.
-Mike
Mark McIntyre
Well, strictly speaking that ain't true, but I don't think anyone's
going to quibble.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
Thomas Stegen
>
> Anything posted here, unless specifically marked otherwise,
> is in the 'public domain' and does not require anyone's
> permission to reproduce.
It is copyrighted to the writer unless marked otherwise.
--
Thomas.
"How long is six months? Ten years?"
- Denis Johnson, Fiskadoro
Arthur J. O'Dwyer
On Sun, 18 May 2003, Thomas Stegen wrote:
>
> Mike Wahler wrote:
> >
> > Anything posted here, unless specifically marked otherwise,
> > is in the 'public domain' and does not require anyone's
> > permission to reproduce.
>
> It is copyrighted to the writer unless marked otherwise.
Both [partially] correct, IMHO. Of course (under U.S. law, which
probably doesn't apply everywhere the U.S. thinks it does), everything
on this newsgroup is copyrighted and can't be legally reproduced
anywhere by anyone, without written or otherwise legally-admissible
permission. But just as obviously [I'd hope], I don't think anyone
here is trying to make money off their Usenet postings, and could
not care less if somebody reproduced them, properly attributed, for
other non-commercial purposes [like making a free e-book].
I speak only for myself, but I hope other people agree. IANAL.
Consider my permission granted.
-Arthur
Dik T. Winter
...
> Both [partially] correct, IMHO. Of course (under U.S. law, which
> probably doesn't apply everywhere the U.S. thinks it does), everything
> on this newsgroup is copyrighted and can't be legally reproduced
> anywhere by anyone, without written or otherwise legally-admissible
> permission.
That is under the Berne Convention, signed by many countries. The US was
one of the last to sign it (in 1989). It has been signed by 150 countries.
> But just as obviously [I'd hope], I don't think anyone
> here is trying to make money off their Usenet postings, and could
> not care less if somebody reproduced them, properly attributed, for
> other non-commercial purposes [like making a free e-book].
Posting an article on Usenet implies the permission to quote by
tradition.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
Default User
"Dik T. Winter" wrote:
> Posting an article on Usenet implies the permission to quote by
> tradition.
Quoting comes under the Fair Use exemption, as it is for the purpose of
commentary or criticism. No permission, implied or otherwise, is
required.
Brian Rodenborn
Mark McIntyre
<Dik.W...@cwi.nl> wrote:
>In article <Pine.LNX.4.53L-031...@unix49.andrew.cmu.edu> "Arthur J. O'Dwyer" <a...@andrew.cmu.edu> writes:
>...
> > Both [partially] correct, IMHO. Of course (under U.S. law, which
> > probably doesn't apply everywhere the U.S. thinks it does), everything
> > on this newsgroup is copyrighted and can't be legally reproduced
> > anywhere by anyone, without written or otherwise legally-admissible
> > permission.
(snip)
>Posting an article on Usenet implies the permission to quote by
>tradition.
Tradition doesn't stand much chance these days. ISTR someone got sued
for "stealing" an idea fron someone else's usenet posting, and
certainly I've heard of (and experienced) threats being bandied about.
RP Henry
"Mark McIntyre" <markmc...@spamcop.net> wrote in message
news:2nbicvcqguab2pv47...@4ax.com...
> On Mon, 19 May 2003 15:03:43 GMT, in comp.lang.c , "Dik T. Winter"
> <Dik.W...@cwi.nl> wrote:
>
> >In article <Pine.LNX.4.53L-031...@unix49.andrew.cmu.edu>
"Arthur J. O'Dwyer" <a...@andrew.cmu.edu> writes:
> >...
> > > Both [partially] correct, IMHO. Of course (under U.S. law, which
> > > probably doesn't apply everywhere the U.S. thinks it does), everything
> > > on this newsgroup is copyrighted and can't be legally reproduced
> > > anywhere by anyone, without written or otherwise legally-admissible
> > > permission.
>
> (snip)
>
> >Posting an article on Usenet implies the permission to quote by
> >tradition.
>
> Tradition doesn't stand much chance these days. ISTR someone got sued
> for "stealing" an idea fron someone else's usenet posting, and
> certainly I've heard of (and experienced) threats being bandied about.
Refer them to the fair use doctrine of the copyright law of 1976 (assuming
US jurisdiction).
Default User
Mark McIntyre wrote:
> >Posting an article on Usenet implies the permission to quote by
> >tradition.
>
> Tradition doesn't stand much chance these days. ISTR someone got sued
> for "stealing" an idea fron someone else's usenet posting, and
> certainly I've heard of (and experienced) threats being bandied about.
But that really doesn't have much to do with properly formatted quoting.
Lifting something from a usenet posting and presenting it as your own
work would indeed be copyright violation. Quoting would be fair use.
Brian Rodenborn
Mark McIntyre
<first...@company.com> wrote:
>Lifting something from a usenet posting and presenting it as your own
>work would indeed be copyright violation. Quoting would be fair use.
Oh, I don't doubt that you're morally and effectively correct, but
strictly copyright law doesn't relate to claiming that the material is
your own, it relates to use of the material without permission. You're
thinking of something else, possibly trademark infringement or
plagiarism. Fair use by the way is interesting to define... !!
Dik T. Winter
> Mark McIntyre wrote:
> > >Posting an article on Usenet implies the permission to quote by
> > >tradition.
> >
> > Tradition doesn't stand much chance these days. ISTR someone got sued
> > for "stealing" an idea fron someone else's usenet posting, and
> > certainly I've heard of (and experienced) threats being bandied about.
>
> work would indeed be copyright violation. Quoting would be fair use.
The Berne Convention explicitly states that when you quote you *must*
acknowledge the source. However what I meant is that Usenet tradition
has it that you may quote an article in full; that is not covered by
fair use.
Daniel Haude
> Regarding indentation & formatting.... it's actually a problem of
> Mircrosoft Word.
You should use TeX/LaTeX. An excellent, widely distributed free
typesetting system which yields the same result everywheer. Available for
just about every operating system, part of probably every Linux
distribution. Runs admirably on even the slowest computers.
--Daniel
--
"With me is nothing wrong! And with you?" (from r.a.m.p)