Board index » cppbuilder » Re: strncpy/wcsncpy query (BCB6/STLPort)

Re: strncpy/wcsncpy query (BCB6/STLPort)


2006-07-11 01:08:10 AM
cppbuilder11
At 14:42:33, 10.07.2006, Hendrik Schober wrote:
Quote
>Sure. But if you can't trust a library, what to do? [...]

Whatever, trading some libraries bugs for your own isn't
an option.
If you don't even trust your own code, then you are in the wrong
business. <g>
Especially if this is only a small routine like wcscpy, it is IMO better
to use your own code which you fully control, than switch an entire 3rd
party library, which may introduce other bugs.
--
Rudy Velthuis [TeamB] rvelthuis.de/
"I have often regretted my speech, never my silence."
- Xenocrates (396-314 B.C.)
 
 

Re:Re: strncpy/wcsncpy query (BCB6/STLPort)

It's just fine to use something like wcscpy when you're just fooling around
but strongly suspect that the function either has a bug or operates in a
manner other than what you want.
It is quite a different thing when getting out a commercial program. In
that environment the first criteria is if the program works. For small
functions like this in production code it is not only normal but appropriate
to write your own function when there are questions about the available
library routine.
Using routines from the supplied libraries fall into the catagory "seems
right" while using routines which work are of the catagory "can feed my
family". I'll take the groceries every time.
. Ed
Quote
Rudy Velthuis wrote in message
news:xn0eokf0l918px400k-velthuis@www.teamb.com...

>>Sure. But if you can't trust a library, what to do? [...]
>
>Whatever, trading some libraries bugs for your own isn't
>an option.

If you don't even trust your own code, then you are in the
wrong business. <g>

Especially if this is only a small routine like wcscpy, it is
IMO better to use your own code which you fully control,
than switch an entire 3rd party library, which may introduce
other bugs.
 

Re:Re: strncpy/wcsncpy query (BCB6/STLPort)

"Ed Mulroy" < XXXX@XXXXX.COM >writes:
Quote
Using routines from the supplied libraries fall into the catagory
"seems right" while using routines which work are of the catagory
"can feed my family". I'll take the groceries every time.
You trust your compiler to "just work", so you don't write your own.
Why should the standard library implementation be any different?
For that matter, why should you suspect your code to be better than a
commercially developed, widely used and tested implementation?
Sure, not all 3rd party code is "quality", but this sort of sounds
like "not invented here" syndrome.
--
Chris (TeamB);
 

{smallsort}

Re:Re: strncpy/wcsncpy query (BCB6/STLPort)

At 21:33:06, 10.07.2006, Ed Mulroy wrote:
Quote
It's just fine to use something like wcscpy when you're just fooling
around but strongly suspect that the function either has a bug or
operates in a manner other than what you want.

It is quite a different thing when getting out a commercial program.
In that environment the first criteria is if the program works. For
small functions like this in production code it is not only normal but
appropriate to write your own function when there are questions about
the available library routine.
That is what I'd do as well.
--
Rudy Velthuis [TeamB] rvelthuis.de/
"You have to stay in shape. My grandmother, she started walking five
miles
a day when she was 60. She's 97 today and we don't know where she is!"
-- Ellen DeGeneres.
 

Re:Re: strncpy/wcsncpy query (BCB6/STLPort)

At 22:12:25, 10.07.2006, Chris Uzdavinis (TeamB) wrote:
Quote
For that matter, why should you suspect your code to be better than a
commercially developed, widely used and tested implementation?
If that commercially developed, widely used and tested implementation
uses wcslen() in the implementation of wcscpy(), then I suspect my code
to be better.
After all, if you want others to trust your code, you should trust your
own code as well. <g>
Using well tested libraries means that I don't have to reinvent the wheel
and many other little things, but if these libraries don't do what I
need, I must and will write my own code. And my code should also be
trusted and tested.
IOW, I generally don't use trusted and tested libraries because my own
code sucks, I just use them to avoid a lot of work. And they should be at
least as good as my code. But if they are faulty, or at least not what I
need, it is better and easier to write my own.
--
Rudy Velthuis [TeamB] rvelthuis.de/
"Humor is the great thing, the saving thing. The minute it crops up, all
our irritations and resentments slip away and a sunny spirit takes
their place." -- Mark Twain (1835-1910)
 

Re:Re: strncpy/wcsncpy query (BCB6/STLPort)

"Chris Uzdavinis (TeamB)" < XXXX@XXXXX.COM >wrote in message
Quote
"Ed Mulroy" < XXXX@XXXXX.COM >writes:

>Using routines from the supplied libraries fall into the catagory
>"seems right" while using routines which work are of the catagory
>"can feed my family". I'll take the groceries every time.

You trust your compiler to "just work", so you don't write your own.
Why should the standard library implementation be any different?

For that matter, why should you suspect your code to be better than a
commercially developed, widely used and tested implementation?
While I agree with you for the most part, the problem is when the
implementation of the standard library that you're using is broken.
In the case we're talking about, that seems to be the case so
providing your own solution sounds like the only choice.
In theory, you're correct but in reality, I know you've had
to provide work-arounds for broken implementations
of the standard library as I have used your fixes myself <g>
 

Re:Re: strncpy/wcsncpy query (BCB6/STLPort)

"Rudy Velthuis [TeamB]" < XXXX@XXXXX.COM >writes:
Quote
IOW, I generally don't use trusted and tested libraries because my
own code sucks, I just use them to avoid a lot of work. And they
should be at least as good as my code. But if they are faulty, or at
least not what I need, it is better and easier to write my own.
I don't mean to imply your (or Ed's) code sucks, but that bugs happen,
and custom code that is not so well tested, optimized, and used is
simply more likely to contain bugs.
--
Chris (TeamB);
 

Re:Re: strncpy/wcsncpy query (BCB6/STLPort)

Quote
You trust your compiler to "just work", so you don't write
your own. Why should the standard library implementation
be any different?
...
For that matter, why should you suspect your code to be
better than a commercially developed, widely used and
tested implementation?
I already said why - you would do it when you "strongly suspect that
the function either has a bug or operates in a manner other than
what you want".
There is no reason why my code as described in my message as "For small
functions" would be inferior to a commercially developed, widely used and
tested implementation.
Did you not read all of what I wrote?
Is it common for what you write to be inferior code?
I didn't think so. Mine isn't inferior either.
As an example:
For many years I used my own strcpy function, a clone implementation whose
only difference is that it does not crash if passed a NULL pointer. Only
when Windows 3.0 (maybe Win386, can't remember which) came out and supplied
lstrcpy which had that behavior did I stop using my function. I was not
wrong to supply my own function and my implementation was as of as high a
quality as that of the C library vendors.
. Ed
Quote
Chris Uzdavinis wrote in message
news: XXXX@XXXXX.COM ...

>Using routines from the supplied libraries fall into the catagory
>"seems right" while using routines which work are of the catagory
>"can feed my family". I'll take the groceries every time.

You trust your compiler to "just work", so you don't write your own.
Why should the standard library implementation be any different?

For that matter, why should you suspect your code to be better than a
commercially developed, widely used and tested implementation?

Sure, not all 3rd party code is "quality", but this sort of sounds
like "not invented here" syndrome.
 

Re:Re: strncpy/wcsncpy query (BCB6/STLPort)

"Duane Hebert" < XXXX@XXXXX.COM >writes:
Quote
In theory, you're correct but in reality, I know you've had to
provide work-arounds for broken implementations of the standard
library as I have used your fixes myself <g>
Sure, bugs happen even in commercial code, and I've helped work around
them. We've all have had to workaround some problem at some point,
either bugs in the compiler or in some 3rd party (or co-worker's)
code.
But it's different to assume that the library is going to be broken
and write your own replacement in advance of actually discovering any
bugs.
--
Chris (TeamB);
 

Re:Re: strncpy/wcsncpy query (BCB6/STLPort)

At 23:54:46, 10.07.2006, Chris Uzdavinis (TeamB) wrote:
Quote
"Rudy Velthuis [TeamB]" < XXXX@XXXXX.COM >writes:

>IOW, I generally don't use trusted and tested libraries because my
>own code sucks, I just use them to avoid a lot of work. And they
>should be at least as good as my code. But if they are faulty, or at
>least not what I need, it is better and easier to write my own.

I don't mean to imply your (or Ed's) code sucks, but that bugs happen,
and custom code that is not so well tested, optimized, and used is
simply more likely to contain bugs.
Still, I think one should not be afraid to rely on one's own code. <g>
--
Rudy Velthuis [TeamB] rvelthuis.de/
The "abort()" function is now called "choice()."
-- from the "Politically Correct UNIX System VI Release notes"
 

Re:Re: strncpy/wcsncpy query (BCB6/STLPort)

At 23:58:43, 10.07.2006, Chris Uzdavinis (TeamB) wrote:
Quote
But it's different to assume that the library is going to be broken
and write your own replacement in advance of actually discovering any
bugs.
I never said one should write a replacement library. Just a replacement
for wcsncpy() that doesn't use wcslen().
--
Rudy Velthuis [TeamB] rvelthuis.de/
"I do not fear computers. I fear the lack of them." -- Isaac Asimov.
 

Re:Re: strncpy/wcsncpy query (BCB6/STLPort)

"Chris Uzdavinis (TeamB)" < XXXX@XXXXX.COM >wrote in message
Quote
But it's different to assume that the library is going to be broken
and write your own replacement in advance of actually discovering any
bugs.
I don't think that I implied that. The case in question seems
like a broken implementation. I'm only saying that short
of changing implementations, your only choice is to write
something that works for that function.
FWIW, I always assume that the std lib stuff is
going to work. I'm too lazy to do differently <g>
 

Re:Re: strncpy/wcsncpy query (BCB6/STLPort)

Rudy Velthuis [TeamB] < XXXX@XXXXX.COM >wrote:
Quote
At 14:42:33, 10.07.2006, Hendrik Schober wrote:

>>Sure. But if you can't trust a library, what to do? [...]
>
>Whatever, trading some libraries bugs for your own isn't
>an option.

If you don't even trust your own code, then you are in the wrong
business. <g>
If you blindly trust your own code more than the code
of a commercial library that's used by hundreds of
thousends, then /you/, Rudy, are in the right business. :o>
Quote
Especially if this is only a small routine like wcscpy, it is IMO better
to use your own code which you fully control, than switch an entire 3rd
party library, which may introduce other bugs.
I have seen enough of those "it's-only-a-small-routine"
thingies containing surprisingly stupid bugs. If I use
a commercial library and suspect it to be buggy, the
very first thing I try to find a better one. My boss
will also usually favour byuing some tested lib over
me spending my time writing and testing my own. Our
customers don't pay for us re-inventing wcsncpy(),
they pay us for code /using/ wcsncpy().
I had to do a lot of write-my-own because some lib did
fail to meet expectations and it wasn't possible to
replace it, but I never liked it and neither did the
boss.
Schobi
--
XXXX@XXXXX.COM is never read
I'm Schobi at suespammers dot org
"The sarcasm is mightier than the sword."
Eric Jarvis
 

Re:Re: strncpy/wcsncpy query (BCB6/STLPort)

Duane Hebert < XXXX@XXXXX.COM >wrote:
Quote
"Chris Uzdavinis (TeamB)" < XXXX@XXXXX.COM >wrote in message
news: XXXX@XXXXX.COM ...
>"Ed Mulroy" < XXXX@XXXXX.COM >writes:
>
>>Using routines from the supplied libraries fall into the catagory
>>"seems right" while using routines which work are of the catagory
>>"can feed my family". I'll take the groceries every time.
>
>You trust your compiler to "just work", so you don't write your own.
>Why should the standard library implementation be any different?
>
>For that matter, why should you suspect your code to be better than a
>commercially developed, widely used and tested implementation?

While I agree with you for the most part, the problem is when the
implementation of the standard library that you're using is broken.
Buy a better one.
Dinkumware /in Source/ (usable on many platforms) costs
$1,150/seat. Heck, that's the equivalent of only 15 good
computing books. Add the hours you spent fiddling with
bugs, glitches and the inferiority of your current one
and project that into the future to see how long it will
take until this cost amortized.
Quote
[...]
Schobi
--
XXXX@XXXXX.COM is never read
I'm Schobi at suespammers dot org
"The sarcasm is mightier than the sword."
Eric Jarvis
 

Re:Re: strncpy/wcsncpy query (BCB6/STLPort)

At 12:24:52, 11.07.2006, Hendrik Schober wrote:
Quote
>>Whatever, trading some libraries bugs for your own isn't
>>an option.
>
>If you don't even trust your own code, then you are in the wrong
>business. <g>

If you blindly trust your own code more than the code
of a commercial library
No one talked about trusting anything BLINDLY. Code replacing that one
routine must be tested like all the other code, of course.
If anything is to be trusted blindly, it is 3rd party code, I'd say.
But if that library uses wcslen() in the implementation of wcsncpy() then
yes, I trust my own code better.
--
Rudy Velthuis [TeamB] rvelthuis.de/
"Egotist: a person more interested in himself than in me."
- Ambrose Bierce (1842-1914)