Daniel said:
At about the time of 1/5/2006 2:27 AM, Flash Gordon stated the following:
Really?
strata:/home/dr2867/c/modules 1038 $$$ ->./compile strscpy.c strscpy.o
gcc -W -Wall -Wshadow -Wpointer-arith -Wcast-align -Wstrict-prototypes
-Wnested-externs -Wwrite-strings -Wfloat-equal -Winline -Wtrigraphs
-ansi -std=c89 -pedantic -ggdb3 -c -o strscpy.o strscpy.c
Seems to compile just fine on my system... FreeBSD 6.0-RELEASE
Yes, really. I have multiple Windows boxes with different versions of MS
Visual Studio and MS Visual C++ (all of which include C compilers) and
*none* of them have the non-standard header you used.
What the hell?
It was an EXAMPLE. Going beyond INT_MAX? Who the hell is going to pass
2GB text strings around in memory. Most machines don't HAVE 2GB RAM
installed. Granted, if need be I can use an unsigned long, but again
who is going to need it? I'll be very interesting in hearing your
answer reguarding real world applications..
Some machines have had 16 bit ints, so that could be 32K. However, the
point is that if you are writing a replacement for a system function
then you should arbitrarily introduce a lower limit on what it can copy
with than the function it is to replace. After all, if you are trying to
write a safer alternative to a standard function is it really a good
thing to introduce another trap for the unwary?
One example, BTW, where one can sometimes end up dealing with very large
strings (larger than you expect), is when something like an RTF document
is stored in a database and the user chooses to be stupid and embed a
high resolution true-colour image in the header of the document (I know
this through experience or what *real* users do, and in our case the
application did *not* crash, but transferring the document over the
network was taking a very long time). If the non-standard 3rd-party DB
library gives it to you as a string and you then have to copy it
somewhere else for use by another non-standard third party library...
Now, it could be argued that the large RTF document should have been
rejected (although where do you place the limit?) but it is certainly
not acceptable (to me) to invoke undefined behaviour just because the
user has been even more stupid that I expect users to be.
About the bcopy function. I was not aware that it was not ISO C90.
Well, you do now.
As a programmer, I use what is available on the platform that I code on.
So do I, and I regularly use things that are not part of C but are
either extensions or third party libraries.
Because my software has to work in the real world, I have to code it so
that it is robust, safe, and secure.
Using a non-standard function when there is a perfectly good standard
function does not help in this. Using your alternative to strcpy or
using strlcpy (another extension) can assist, but that was not the case
here.
Admittedly you did not know bcopy was non-standard, but now you do. If
you've read the link I posted you will also know that there have been
version of bcopy that did *not* copy with overlapping source and
destination.
> Granted, I am still learning, but
I'm doing quite well. I don't get may errors or warnings when my code
compiles. When I do get an error or warning, I track it down and fix it.
It is also useful to know what is standard and what is not. This does
not mean don't use non-standard things, but when you are using them you
should know you are using them.
Personally I don't use any of the b* functions from BSD even when
programming on systems that provide them (which I do regularly) because
there are perfectly good alternatives that are part of the C standard.
Also, knowing what is standard helps you avoid having people complain at
you for using non-standard things in this group ;-)