For example.
char psarg[2];
strncmp(psarg, "aloha", 5);
Will it lead to memory corruption?
-Parag
--
comp.lang.c.moderated - moderation address: cl...@plethora.net -- you must
have an appropriate newsgroups line in your header for your mail to be seen,
or the newsgroup name in square brackets in the subject line. Sorry.
The standard doesn't say what will happen, only that the behavior is
undefined.
That allows for the possibility (among a great many other possibilities)
of run-time array bounds checking. If checking is done, it might take
the form of treating the above code as equivalent to strncmp(psarg,
"aloha", 2) - but that's pretty unlikely. It's far more likely to cause
your program to abort. If checking is not done, trying to read past the
end of the array might cause a memory access violation, also aborting
your program, or your program might simply be allowed to read whatever
it is that is past the end of the array.
Since strncmp() only reads the memory, rather than writing it, memory
corruption is extremely unlikely - but since the behavior is undefined,
it's certainly possible.
All of those different possibilities serve to reinforce the key point:
it's not useful to worry about what might happen if a program with
undefined behavior gets executed; you should simple learn how to
identify code that has undefined behavior, and then make sure not to
write it.
--
James Kuyper
>Does the runtime check for the length of the string for strncmp.
>
>For example.
>char psarg[2];
>
>strncmp(psarg, "aloha", 5);
>
>
>Will it lead to memory corruption?
strncmp does not alter memory and therefore cannot lead to memory
corruption. Were you thinking of strncpy?
You don't show any initialization for or assignment to psarg so it is
possible its value is indeterminate. If so, your code invokes
undefined behavior, especially if there is no '\0' in either of the
two bytes to terminate strncmp's effort.
There are no limits on what undefined behavior does so memory
corruption is a (very unlikely in this case) possibility.
--
Remove del for email
The runtime could check the length of the string, and if it's too
long, *CAUSE* all sorts of bad behavior, such as abrupt termination
of your program, or sending emails of resignation to your boss.
Or maybe it just returns a result, correct or incorrect.
> For example.
> char psarg[2];
>
> strncmp(psarg, "aloha", 5);
>
>
> Will it lead to memory corruption?
Undefined behavior can do anything, including, theoretically,
violating the laws of physics or retroactively altering the C
standard.
Since strncmp() doesn't *write* on the strings involved, I wouldn't
expect it to write on memory accidentally. If it's being malicious,
such as on the DS9K platform, all bets are off.
I was wrong, it won't be exactly the same in the case that psarg is
lonher than 5
--
⚂⚃ 100% natural
strncmp stops at the first '\0' in either string same as strcmp;
(it also stops at n)
> For example.
> char psarg[2];
>
> strncmp(psarg, "aloha", 5);
> Will it lead to memory corruption?
strncmp doesn't write to memory
depending on what's in psarg it can lead to other errors.
if strlen(psarg) < sizeof psarg there will be no problems
as strlen("aloha") == 5
strncmp(psarg, "aloha", 5); will behave the same as
strcmp(psarg, "aloha");
--
⚂⚃ 100% natural
strncmp does not write to memory so it can not cause memory
corruption, and as long as both string arguments are NULL terminated
then strncmp will not attempt to read memory outside of the strings.
On Apr 9, 8:20 am, parag <parag.p...@gmail.com> wrote:
> Does the runtime check for the length of the string for strncmp.
>
> For example.
> char psarg[2];
>
> strncmp(psarg, "aloha", 5);
>
> Will it lead to memory corruption?
> -Parag
> --
> comp.lang.c.moderated - moderation address: c...@plethora.net -- you must
> parag <parag...@gmail.com> writes:
>>Does the runtime check for the length of the string for strncmp.
Even without question mark I regard this as the question of the OP.
>>For example.
>>char psarg[2];
You snipped a newline; without further context this definition
might have file scope.
>>strncmp(psarg, "aloha", 5);
>>Will it lead to memory corruption?
>
> »If an array is accessed beyond the end of an object,
> the behavior is undefined.«
>
> ISO/IEC 9899:1999 (E), 7.21.1#1 String function conventions
The strncmp function compares not more than n characters
(characters that follow a null character are not compared) from
the array pointed to by s1 to the array pointed to by s2.
7.21.4.4p2 l.c.
(F'up to original newsgroup)
-- Ralf
It knows nothing about how the first two arguments were declared.
Your example WILL invoke undefined behavior, which COULD include
corruption of memory (but in practice corruption is unlikely
since strncmp does not try to store anything anywhere; it only
compares characters in the two strings). The undefined behavior
begins in this case with the attempt to compare the third byte
of "aloha" with the (non-existant) third byte of psarg, unless
the first or second byte of psarg contained a '\0', in which
case it will probably appear to succeed.
--
Fred K
>Does the runtime check for the length of the string for strncmp.
>
>For example.
>char psarg[2];
>
>strncmp(psarg, "aloha", 5);
>
>
>Will it lead to memory corruption?
>-Parag
Should have said ...
No. No. To both questions.
-ralph
>Does the runtime check for the length of the string for strncmp.
>
>For example.
>char psarg[2];
>
>strncmp(psarg, "aloha", 5);
>
>
>Will it lead to memory corruption?
>-Parag
No.
However, might return an invalid answer depending on what follows
psarg in memory. strncmp stops on a terminating null. Without a
terminating null it will stop at the value of the third argument.
It will use the pointer arguments directly, type casting them to
'pointer to unsigned char' only to determine a nonzero return value.
It 'peeks' but never 'writes'.
-ralph