在 2019/12/16 4:00, Jeffrey Walton 写道: > > If RTFM was going to work, then it would have happened in the last 50 > years or so. > > If error free programming was going to happen, then it would have > happened in the last 50 years or so. > > Come back to reality. >
What's your point? Don't RTFM then don't code, period.
>
> Microsoft calls them "safer" functions. They are "safer" then the
> original C functions they are supplementing. For completeness,
> Microsoft does not claim they are completely safe.
>
They are of course not 'safer' for two reasons:
One is that by having an additional parameter you ask for an additional
size argument, but it is still possible that the user passed a wrong
size, such as when you want the number of `wchar_t`s but your user
supplied the number of bytes, which you have no clue about. The best
advice would be using C++ templates to deduce the size of output buffer,
but it doesn't work in C, and even in C++ it works only when the
argument is an array, string, vector, etc. It doesn't work if the
argument is a pointer, in which case you still have to pass the size
yourself.
The other reason is that by requiring more arguments you increase the
probability of bugs. Let's say there is a 1% chance that you pass a
wrong argument. Then if there is 1 argument, the probability that you do
everything right is 99%. If there are 2 arguments, it is 98.01%. If
there are 10 arguments, it is 97.0299%. If there are 100 arguments, it
is about 36.6%. It is not something we would like.
> Hugh? Are you begging the argument:
>
> char* ptr = malloc (50);
>
> And then claiming you don't know the size?
>
Why don't you use Java which keeps tracking of allocated arrays and
throws exceptions in case of out-of-bound access?
> Developer training does not work. If it was going to work, then it
> would have happened in the last 50 years or so.
>
> Microsoft recognized the fact years ago. You have to force developers
> to use something safer.
>
Let's take a C++ example. A lot of people still prefer `operator[]` to
`.at()`, which is prone to errors; but they have been taught and have
got used to that for decades. It is not developer training that does not
work. It is /bad/ developer training that does not work.
>
> I don't think a known dangerous and banned function is a good example.
> strcpy() is banned by both Microsoft and APple. Only Linux still
> embraces strcpy(). strcpy() still suffers the problem that is trying
> to be corrected.
>
I don't think `strcpy()` is unsafe. The only real issue of it is that it
copies strings without returning its length. So in order to get the
length you have to scan the copied string again. `stpcpy()` would be a
much better alternative.
>
> I generally consider the Glibc folks better trained in C and more
> knowledgeable of the C standard then me. If the Glibc folks are making
> the mistakes, then there is no hope in practice for folks like me or
> those who are just starting in C. There are too many sharp edges.
>
Yes yes why don't you use Java? If you write C you are supposed to have
been well educated ('well educated' means at least you should RTFM
before ask). C is not for beginners.
--
Best regards,
LH_Mouse
signature.asc
Description: OpenPGP digital signature
