--- In [email protected], Yutaka OKAIE <[EMAIL PROTECTED]> wrote: > > From: peternilsson42 <[EMAIL PROTECTED]> > To: [email protected] > Sent: Monday, April 16, 2007 4:34:09 PM > Subject: [c-prog] Re: Hexadecimal to Decimal > > > > Yutaka OKAIE <y0kelist@> wrote: > > > > > > ... Here's the reply for your comments. > > > > Top posting is not recommended. That you felt you needed to > > put in that comment only highlights its disadvantages. > > Thanks for good advice. I'd like to pay attension to the > posting-styles. > > > > I think strings obtained with "fgets" end with "\n\0", right? > > > > No, not necessarily. If the line is longer than the > > destination buffer, or if the last line of input is not > > \n terminated, there will be no \n in the buffer. > > You're right. I haven't noticed this point which might > have led to onerous bugs. > > > > In order to manipulate the output appearance, > > > I replaced the '\n' with '\0', > > > > It's better to use strchr(..., '\n') to find if there > > actually was a \n. Then you can use the return pointer > > to zero it if needed. > > Yes. It was careless of me not to check if there > actually was a '\n'. > > > > so there are two '\0's at the end of the string "input". > > > > Technically, there's only ever one null byte in a string. > > What follows is not part of that string. > > Exactly. > > I now feel it's quite difficult work to write a complete > code taking how several users would use it into > considertaions. I need more precious advice from the old > know-it-all as well as experience of my own.
Thanks for the kudos. What I would have added to my previous post is indeed no more and no less than what Peter has suggested and what you understood out of it. You are right, writing complete code for all possible cases is not as easy as it might look like. And that's (one third of) the exact difference between a "code hacker" and a good programmer, as Thomas has stated it in the preface of his book he mentions from time to Time, Safe C++ Design Principles. [The second third is Good Commentation And Documentation; the last third is Thorough Interaction With End Users. Thomas, do you consider this very rough abbreviation correct?] No, I haven't read the complete e-book yet. I only had the honour to read and translate the very first chapter from English to German, and I have to say that almost every single word from this chapter perfectly reflects my personal experience. Although I still didn't have the time to work in C++, I am confident [Nico, download the book and read it! Now!] that what Thomas has written there is not only extremely useful to C++ programmers but also is vital to C programmer. In short, what can we learn from the hex2dec conversion? 1) always insert useful comments. 2) Reconsider the algorithm if you encounter "switch" statements with more than let's say four or five "case"s. 3) Thoroughly read every man page of any standard function you are going to use; read it completely; and check for special cases one might overlook at first glance (such as the question of '\n' at the end of a string read by "fgets()"). 4) Always, always, always define test cases which stretch beyond the capabilities and limitations of any standard library function / system call you use; this will help you to make your applications more robust and safer. See the many MS IE exploits utilising buffer overflows... 5) Take the time and read at least the following books: - The Art Of Computer Programming, 3 volumes, Donald Knuth; - Algorithms In C / Pascal, 1 vol., Robert Sedgewick; - Safe C++ Design Principles, 1 e-volume, Thomas Hruska. BTW a more personal question: how many people would fancy a complete German translation of Safe C++ Design Principles? It will take me several months to translate it, but if there are enough people interested in this translation, I'll do it. Regards, Nico
