So if strcmp (x, "\0") ==0 would work (wouldn't it???) - since you are asking to determine if string x is equal to a null terminated empty string.
End of quote
Hmm, maybe we are misunderstanding each other here. I mean that "\0" is a string, which is entirely different from the null character '\0'. "\0" as a string takes at least two bytes but '\0' as a null character is only one byte long. The null character ('\0') is therefore used as a string terminator, but the string "\0" just means a '\' character followed by the number '0' and does not have any special meaning to a string. Hence strcmp/strncmp string compare (and such string routines) would look at it differently. Perhaps you can try strcmp(x, "") instead, although I think ('\0' == x[0]) is much faster/lighter.
Look at it another way, in your C# example above, what is the difference between (x == null) and (x == "\0") ?
You are assuming that a string OBJECT in C# (or other .NET language) or Java is the same as how they are done in C or C++. Since they are objects, they have methods etc...
End of quote
I don't dispute the object-ness + methods idea of OO. But let me ask a question (pls excuse the high simplification, extrapolate to your fav OO-methods/etc):
str1 = "Hello";
str2 = "World";
str3 = str1 + str2; // which == "HelloWorld"
How did the language/compiler/etc concatenate/join/append/etc the two strings? Chances are they malloc/realloc-ed etc new/more space on str1 then copied the bytes from str1 and/or str2 etc etc. Bottom line is, the strings are still represented as an array at a low level. So the fundamental difference of the string "\0" vs the character '\0' is still there.
Maybe - but if the langauge won't allow it (e.g. .NET managed code - cannot overrun buffer) - how can you get a security hole?
End of quote
That assumes that the guy who wrote the .Net APIs, DLLs, compilers, etc etc all did not make a big mistake. And clearly, those guys needs to understand buffer overruns eh? For example, try writing a Windows Device Driver or Linux Kernel Module in anything but C (not even C++).
Something else to note - unless you REALLY need tight efficent code, higher level languages are easier to develop and are ALMOST as good when compiled. Try writing sockets programming in C# with built in framework support vs C or C++)
End of quote
I fully agree with you. As I said in my earlier post, such advancements are really useful. For example, I thank God I don't need to write ASM.. 
But IMHO some fundamental understanding should be learned by programmers at least, even if they write higher level code exclusively.
Sins Forums
