Hi all,
I've been wondering whether this code would cause problems (as in a
potential crash). I've tested it on certain compilers and it did not
cause problems, but I'm still dubious. Note that I'm deliberately not
terminating source. Therefore strncpy will read into memory
unintentionally. This is not the way I write code - just pure
curiosity.
char from[10] = "";
strncpy( from, "0123456789", sizeof(source) );
char to[50] = "";
strncpy( to, from, sizeof(to) ); //Is this bad...?
//or
memcpy( to, from, sizeof(to) ); //Bad?
I can accept that overwriting memory should cause problems. Is
overreading just as bad.
Looking forward to your replies...
Werner 8 1227
Werner wrote: I've been wondering whether this code would cause problems (as in a potential crash). I've tested it on certain compilers and it did not cause problems, but I'm still dubious. Note that I'm deliberately not terminating source. Therefore strncpy will read into memory unintentionally. This is not the way I write code - just pure curiosity.
char from[10] = ""; strncpy( from, "0123456789", sizeof(source) );
What is 'source'? Did you mean 'sizeof(from)'?
char to[50] = "";
strncpy( to, from, sizeof(to) ); //Is this bad...?
This is bad. You're accessing memory that doesn't necessarily exist
by reading beyond 'sizeof(from)'.
//or memcpy( to, from, sizeof(to) ); //Bad?
Same difference.
I can accept that overwriting memory should cause problems. Is overreading just as bad.
Yes.
V
application will crash (OS exception generated) when trying to access
not mapped pages. win32/intel platform have 4096 bytes page, how they
are allocated by heap manager - depends. it is low probability to hit
guarded page overeading few bytes on brain new heap.
try to overread few megabytes :).
anyway even tiny probabilities summed together makes code unstable.
Victor Bazarov wrote: Werner wrote: I've been wondering whether this code would cause problems (as in a potential crash). I've tested it on certain compilers and it did not cause problems, but I'm still dubious. Note that I'm deliberately not terminating source. Therefore strncpy will read into memory unintentionally. This is not the way I write code - just pure curiosity.
char from[10] = ""; strncpy( from, "0123456789", sizeof(source) ); What is 'source'? Did you mean 'sizeof(from)'?
char to[50] = "";
strncpy( to, from, sizeof(to) ); //Is this bad...?
This is bad. You're accessing memory that doesn't necessarily exist by reading beyond 'sizeof(from)'.
Since the contents of the from array is a null-terminated string, the
strncpy call in this example is OK. strncpy stops copying characters
when it reaches the terminating zero-valued character in from. To
handle the case when the characters in from are not null-terminated, I
would suggest replacing sizeof(to) with sizeof(from) as long as
sizeof(from) continues to be equal or less than sizeof(to).
But given that this is a C++ newsgroup, I would just replace the whole
program with one that uses std::strings and be free of these concerns. //or memcpy( to, from, sizeof(to) ); //Bad?
Same difference.
This statement is worse than the previous statement, because unlike the
previous statement, this one is unsafe. Replacing strncpy with memcpy
removes the check on the number of bytes read from "from" and therefore
accesses unallocated memory addresses.
Greg
Greg wrote: Victor Bazarov wrote: Werner wrote: I've been wondering whether this code would cause problems (as in a potential crash). I've tested it on certain compilers and it did not cause problems, but I'm still dubious. Note that I'm deliberately not terminating source. Therefore strncpy will read into memory unintentionally. This is not the way I write code - just pure curiosity.
char from[10] = ""; strncpy( from, "0123456789", sizeof(source) ); What is 'source'? Did you mean 'sizeof(from)'?
char to[50] = "";
strncpy( to, from, sizeof(to) ); //Is this bad...?
This is bad. You're accessing memory that doesn't necessarily exist by reading beyond 'sizeof(from)'.
Since the contents of the from array is a null-terminated string,
Uh... What? Come again? Where is the null terminator written there?
[...]
//or memcpy( to, from, sizeof(to) ); //Bad?
Same difference.
This statement is worse than the previous statement, because unlike the previous statement, this one is unsafe. [..]
Both have undefined behaviour.
V
Greg wrote: Victor Bazarov wrote: Werner wrote: I've been wondering whether this code would cause problems char from[10] = ""; strncpy( from, "0123456789", sizeof(source) );
What is 'source'? Did you mean 'sizeof(from)'?
char to[50] = "";
strncpy( to, from, sizeof(to) ); //Is this bad...?
This is bad. You're accessing memory that doesn't necessarily exist by reading beyond 'sizeof(from)'.
Since the contents of the from array is a null-terminated string,
But it isn't. The first strncpy cause 'from' to be filled
with 10 bytes, none of which is a null terminator.
Victor Bazarov wrote: Werner wrote: I've been wondering whether this code would cause problems (as in a potential crash). I've tested it on certain compilers and it did not cause problems, but I'm still dubious. Note that I'm deliberately not terminating source. Therefore strncpy will read into memory unintentionally. This is not the way I write code - just pure curiosity.
char from[10] = ""; strncpy( from, "0123456789", sizeof(source) ); What is 'source'? Did you mean 'sizeof(from)'?
Yes, sorry about that. I used to be called source... char to[50] = "";
strncpy( to, from, sizeof(to) ); //Is this bad...?
This is bad. You're accessing memory that doesn't necessarily exist by reading beyond 'sizeof(from)'.
//or memcpy( to, from, sizeof(to) ); //Bad?
Same difference.
I can accept that overwriting memory should cause problems. Is overreading just as bad.
Yes.
V
forester wrote: application will crash (OS exception generated) when trying to access not mapped pages. win32/intel platform have 4096 bytes page, how they are allocated by heap manager - depends. it is low probability to hit guarded page overeading few bytes on brain new heap. try to overread few megabytes :).
anyway even tiny probabilities summed together makes code unstable.
Thank you, question answered. Therefore read violations may cause
instabilities too - accessing unmapped memory. Furthermore when using
strncpy (or even more important, memcpy), care is to be taken to not
overread (that confirms my fears).
Kind regards,
Werner
Greg wrote: Victor Bazarov wrote: Werner wrote: I've been wondering whether this code would cause problems (as in a potential crash). I've tested it on certain compilers and it did not cause problems, but I'm still dubious. Note that I'm deliberately not terminating source. Therefore strncpy will read into memory unintentionally. This is not the way I write code - just pure curiosity.
char from[10] = ""; strncpy( from, "0123456789", sizeof(source) ); What is 'source'? Did you mean 'sizeof(from)'?
char to[50] = "";
strncpy( to, from, sizeof(to) ); //Is this bad...?
This is bad. You're accessing memory that doesn't necessarily exist by reading beyond 'sizeof(from)'.
Since the contents of the from array is a null-terminated string,
NOT! I explicitly state that - see (NOTE).
the strncpy call in this example is OK. strncpy stops copying characters when it reaches the terminating zero-valued character in from. To handle the case when the characters in from are not null-terminated, I would suggest replacing sizeof(to) with sizeof(from) as long as sizeof(from) continues to be equal or less than sizeof(to).
But given that this is a C++ newsgroup, I would just replace the whole program with one that uses std::strings and be free of these concerns.
I assume then, that initialising std::string with a (const char*) with
the likes of <from> mentioned here above is OK? (NOT) Furthermore,
std::string cannot be used over processor/hardware/communication
boundaries. On the other hand, bytes are used over these boundaries.
This makes this question relevant on a C++ newsgroup. When performing
string manipulations with normal strings, I do use std::string.
Unfortunately not all strings are necessarily normal. //or memcpy( to, from, sizeof(to) ); //Bad?
Same difference.
This statement is worse than the previous statement, because unlike the previous statement, this one is unsafe. Replacing strncpy with memcpy removes the check on the number of bytes read from "from" and therefore accesses unallocated memory addresses.
Greg
Werner This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Mudge |
last post by:
Please, someone, tell me why OO in PHP is better than procedural.
|
by: bigoxygen |
last post by:
Hi.
I'm using a 3 tier FrontController Design for my web application right
now.
The problem is that I'm finding to have to duplicate a lot of code for
similar functions; for example, listing...
|
by: jason |
last post by:
Hello.
Newbie on SQL and suffering through this.
I have two tables created as such:
drop table table1;
go
drop table table2;
go
|
by: Dario de Judicibus |
last post by:
I'm getting crazy. Look at this code:
#include <string.h>
#include <stdio.h>
#include <iostream.h>
using namespace std ;
char ini_code = {0xFF, 0xFE} ;
char line_sep = {0x20, 0x28} ;
|
by: Andrew Thompson |
last post by:
It seems most people get there JS off web sites, which is
entirely logical. But it is also a great pity since most
of that code is of such poor quality.
I was looking through the JS FAQ for any...
|
by: ED |
last post by:
I currently have vba code that ranks employees based on their average
job time ordered by their region, zone, and job code. I currently
have vba code that will cycle through a query and ranks each...
|
by: Namratha Shah \(Nasha\) |
last post by:
Hey Guys,
Today we are going to look at Code Access Security.
Code access security is a feature of .NET that manages code depending on its
trust level. If the CLS trusts the code enough to...
|
by: Joe Fallon |
last post by:
I have some complex logic which is fairly simply to build up into a string.
I needed a way to Eval this string and return a Boolean result.
This code works fine to achieve that goal.
My...
|
by: Alan Silver |
last post by:
Hello,
Newbie here, so please forgive what is probably a basic question ...
I see a lot of discussion about "code behind", which if I have
understood correctly, means that the script code goes...
|
by: DolphinDB |
last post by:
Tired of spending countless mintues downsampling your data? Look no further!
In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
|
by: isladogs |
last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM).
In this month's session, we are pleased to welcome back...
|
by: isladogs |
last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM).
In this month's session, we are pleased to welcome back...
|
by: jfyes |
last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
|
by: PapaRatzi |
last post by:
Hello,
I am teaching myself MS Access forms design and Visual Basic. I've created a table to capture a list of Top 30 singles and forms to capture new entries. The final step is a form (unbound)...
|
by: Defcon1945 |
last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
|
by: Shællîpôpï 09 |
last post by:
If u are using a keypad phone, how do u turn on JavaScript, to access features like WhatsApp, Facebook, Instagram....
|
by: Faith0G |
last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 3 Apr 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome former...
| |