Survey Results

FirstPrevNext

Re: Buffer over-runs Michael P Butler10-Jun-02 0:29 Michael P Butler 10-Jun-02 0:29  Christian Graus wrote: sprintf instead of their C++ equivelants. Ok, I admit it. I still have a tendancy to use sprintf when I haven't got MFC CString::Format. So what is the nice C++ equivelant? I do need to learn to code better. Michael "Eureka" is Greek for "This bath is too hot" Re: Buffer over-runs Christian Graus10-Jun-02 0:48 Christian Graus 10-Jun-02 0:48  Check out my article on ostringstream... Christian I am completely intolerant of stupidity. Stupidity is, of course, anything that doesn't conform to my way of thinking. - Jamie Hale - 29/05/2002 Re: Buffer over-runs Tim Smith10-Jun-02 1:39 Tim Smith 10-Jun-02 1:39  Ugh... ostringstream is an over kill. *PRINTF* can be used safely!!!! Tim Smith I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk? Re: Buffer over-runs Christian Graus10-Jun-02 1:56 Christian Graus 10-Jun-02 1:56  Tim Smith wrote: *PRINTF* can be used safely!!!! Sure. You just need to create ugly, C style strings, handle your own types manually, and create huge buffers to decrease the possibility of overflows. Christian I am completely intolerant of stupidity. Stupidity is, of course, anything that doesn't conform to my way of thinking. - Jamie Hale - 29/05/2002 Re: Buffer over-runs James R. Twine10-Jun-02 4:11 James R. Twine 10-Jun-02 4:11     Or, you can (1) use stack allocated TCHAR buffers, to avoid the unnecessary overhead of dynamic memory allocation that most string classes require, and (2) use _sntprintf(...) to prevent buffer overruns, at the expense of length checking (which you get using C++ string classes, anyway...).  This also gives me the benefit of easy (IMHO, compared to the stream modifiers) manipulation of the display/format of a value: I believe that       "0x%08X"    -is easier to type than using stream manipulators.    Although I must admit that using ostrstream is usually faster (at runtime) than sprintf(...).    Peace! -=- James. "Some People Know How To Drive, Others Just Know How To Operate A Car." (Try Check Favorites Sometime!) Re: Buffer over-runs Tim Smith10-Jun-02 10:34 Tim Smith 10-Jun-02 10:34  Not when people using endl. I see that ALL THE TIME. Using ENDL will bring any application to its knees. Tim Smith I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk? Re: Buffer over-runs Christian Graus10-Jun-02 13:02 Christian Graus 10-Jun-02 13:02  You should clarify - endl sends a flush as well as a newline, so using it for every newline will bring an application to it's knees. Using it to do a new line and flush will perform exactly as you would expect. Christian I am completely intolerant of stupidity. Stupidity is, of course, anything that doesn't conform to my way of thinking. - Jamie Hale - 29/05/2002 Re: Buffer over-runs James R. Twine11-Jun-02 3:17 James R. Twine 11-Jun-02 3:17     Yes, but that is due people misunderstanding "how things work" (meaning endl).  Granted, stuff like that happens far too often these days in the Software Development world...  Entropy Abounds.    Peace! -=- James. "Some People Know How To Drive, Others Just Know How To Operate A Car." (Try Check Favorites Sometime!) Re: Buffer over-runs jkgh12-Jun-02 11:27 jkgh 12-Jun-02 11:27  Half the reason people switch away from VB is to find out what actually goes on.. and then like me they find out that they weren't quite as good as they thought - they've been nannied. Alice thought that running very fast for a long time would get you to somewhere else. " A very slow kind of country!" said the queen. "Now, here , you see, it takes all the running you can do, to keep in the same place". Re: Buffer over-runs Christian Graus10-Jun-02 13:07 Christian Graus 10-Jun-02 13:07  Wow - the email I got was so full of &nbsp's that it was illegible. You're right that typing in the format is usually more intuitive than using iostream modifiers. That's because we are all used to it, because we were taught C instead of C++. However, given that you agree it's faster, AND there is no way that any printf variant will accept user defined types, isn't it worthwhile learning to do things in C++ ? I find I can format things with iostream modifiers as easily as with printf nowadays. It's just a case of learning how. Christian I am completely intolerant of stupidity. Stupidity is, of course, anything that doesn't conform to my way of thinking. - Jamie Hale - 29/05/2002 Re: Buffer over-runs peterchen11-Jun-02 8:53 peterchen 11-Jun-02 8:53  James R. Twine wrote: is usually faster (at runtime) I once had a app log component changed from streams to snprintf - since the streams were freaking slow. Dunno how thsi fits with your experience, but it has cured from from using streams unequivocally. Peter Back in the days before yer Gighertz and Teraflops there was something we old timers called paranoia. Andrew Torrance, The Lounge   [sighist] Re: Buffer over-runs James R. Twine11-Jun-02 9:21 James R. Twine 11-Jun-02 9:21     I specifically mentioned ostrstream, not streams in general.  And it would be interesting to see how the streams in your case were being used, just to be sure that they were not being abused.    Peace! -=- James. "Some People Know How To Drive, Others Just Know How To Operate A Car." (Try Check Favorites Sometime!) Re: Buffer over-runs Tim Smith10-Jun-02 10:38 Tim Smith 10-Jun-02 10:38  After using them for a while, I basically came to the conclusion that these streams need to be redesigned fromt he ground up again. Nice start, but they have a lot of limitations (not to mention adding 50k to your program just so you can format a number). Right tool for the right job. Printf works just fine. Tim Smith I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk? Re: Buffer over-runs (clarification) Tim Smith10-Jun-02 10:49 Tim Smith 10-Jun-02 10:49  Ok, my real point to all this really isn't about if streams are better than *printf. They both work just find but only a fool wouldn't see that streams are safer. HOWEVER, my real point was that buffer overrun problems extend far outside the formatting of output and strings. Streams will go a long way to fixing these problems, but they won't even come close to correcting all buffer overrun problems. Tim Smith I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk? Re: Buffer over-runs James R. Twine10-Jun-02 4:03 James R. Twine 10-Jun-02 4:03     I think you mean sprintf(...), because the discussion is about buffer overruns...    And snprintf(...) is a simple way to prevent them.    Peace! -=- James. "Some People Know How To Drive, Others Just Know How To Operate A Car." (Try Check Favorites Sometime!) Re: Buffer over-runs John M. Drescher10-Jun-02 16:23 John M. Drescher 10-Jun-02 16:23  Tim Smith wrote: ostringstream As a MFC, ATL and WTL programmer I never use any streams at all. Although, I do use stl containers like map, list, set, and vector a lot. John Re: Buffer over-runs Chris Losinger12-Jun-02 7:44 Chris Losinger 12-Jun-02 7:44  at least use snprintf - to limit the number of chars to be put in the buffer. -c shh! the audience (and the NSA) is listening ISEffects - effects for images Re: Buffer over-runs Matt Gullett10-Jun-02 16:48 Matt Gullett 10-Jun-02 16:48  We should definitely use appropriate C++ classes for dealing with memory when raw performance is not needed. When raw performance is needed, though, there is no substitute for stack allocated C style arrays. And heap allocated C style arrays will still outperform any object oriented solution available today. I have experimented in one of my libraries with CString, std::string and TCHAR arrays and there is no doubt that TCHAR arrays delivered the best performance by far and in this particular system, performance was/is far more important than OOP. It definitely requires more work to make sure that it is done right and does not overwrite memory or access deleted memory but when needed it's the only way to go. Not near release Matt Newman9-Jun-02 16:15 Matt Newman 9-Jun-02 16:15  I haven't worried at all about security yet since I haven't gotten even close to a release version. - Matt Newman / Windows XP Activist -Sonork ID: 100.11179 Could you Would you with a goat? - Dr Suess Re: Not near release Andreas Saurwein10-Jun-02 4:25 Andreas Saurwein 10-Jun-02 4:25  Is that your way of telling you will tuck in security just before release? Well, then I would suggest some readings on that topic. Andreas Vote against software patents in europe Re: Not near release Matt Newman10-Jun-02 16:17 Matt Newman 10-Jun-02 16:17  Somewhat. I am trying to get the core of the program done first. However, say my program uses password autheticiation the CheckPassword() function doesn't do anything it just assumes it is okay and passes it on. When I get a functioning build (ie the starts doing it's function) I will make CheckPassword() actually check the password etc etc. For example the server I am working on accepts connections and nothing more so there isn't any need for security so far. - Matt Newman / Windows XP Activist -Sonork ID: 100.11179 Could you Would you with a goat? - Dr Suess Re: Not near release Andreas Saurwein10-Jun-02 21:30 Andreas Saurwein 10-Jun-02 21:30  I really suggest that you read some book on security (e.g. Writing Secure Code, MS Press). There is more to security programming than a CheckPassword() function. And since you mentioned a server, things like DoS and similar attacks come into mind. Think about Andreas Vote against software patents in europe Re: Not near release Matt Newman11-Jun-02 4:47 Matt Newman 11-Jun-02 4:47  Andreas Saurwein wrote: There is more to security programming than a CheckPassword() function I was just using that as an example. I do have to worry about DoS etc but my server doesn't really do anything that could be exploited yet. I was mearly saying that my project is in it's infancy and is even close to exposing criticaly information. Andreas Saurwein wrote: Writing Secure Code, MS Press Thanks for the book suggestion I will have to check that out. - Matt Newman / Windows XP Activist -Sonork ID: 100.11179 Could you Would you with a goat? - Dr Suess PARANOID ! Mauricio Ritter9-Jun-02 15:14 Mauricio Ritter 9-Jun-02 15:14  When you work in a bank... security is always an issue... I´m really paranoid with security... just as my bosses Mauricio Ritter - Brazil Sonorking now: 100.13560 Trank The alcohol is one of the greatest enemys of man, but a man who flee from his enemys is a coward. Re: PARANOID ! Komtiki10-Jun-02 18:55 Komtiki 10-Jun-02 18:55  I do GSM MO & BioMetric Solutions and security is really a big issue. Especially if you ship products worldwide!! Empowerment through development. If the development only WANTS TO WORK!!

Last Visit: 31-Dec-99 18:00     Last Update: 26-Jun-24 7:00 Refresh 123 Next ᐅ

General    News    Suggestion    Question    Bug    Answer    Joke    Praise    Rant    Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.