strcpy and strcat's return type

[zeroDontSpamtype]

Hi,

Why do strcpy and strcat (and strupr and strlwr in some nonstandard
implementations) return a char*? Surely the logical (and DMA-safe)
)return type for these would have been void??

Thanks,

James McLaughlin.

[Lew Pitcher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

ze**************@yahoo.com wrote:

Hi,

Why do strcpy and strcat (and strupr and strlwr in some nonstandard
implementations) return a char*? Surely the logical (and DMA-safe)
)return type for these would have been void??

Why should strcat() return a void *, when both of it's arguments are
char *, and the function is defined as working on character strings?

The same goes for strcpy(): why do you think that it should return void
* rather than char *?
ISTM that, since both functions
a) take char * as arguments (and not void *),
b) work on char * data, and
c) create results best described by char * pointers,
both functions /should/ return char * pointers to the results that they
have generated.

- --

Lew Pitcher, IT Specialist, Enterprise Data Systems
Enterprise Technology Solutions, TD Bank Financial Group

(Opinions expressed here are my own, not my employer's)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)

iD8DBQFC5ickagVFX4UWr64RAmWKAJ9ymd+jL7wIqVGgrHNTo1 98BnxJDgCgrXyr
BGAvh0N9wubb8W9NJLmfxIA=
=6TrQ
-----END PGP SIGNATURE-----

[Jirka Klaue]

Lew Pitcher:

ze**************@yahoo.com:

....

Why do strcpy and strcat (and strupr and strlwr in some nonstandard
implementations) return a char*? Surely the logical (and DMA-safe)
)return type for these would have been void??

Why should strcat() return a void *, when both of it's arguments are
char *, and the function is defined as working on character strings?

He said void, not void *. And to answer the actual question: I think,
they return char * to allow such things as

return strcat(strcpy(buf, path), file);

Jirka

[Kenneth Brody]

Jirka Klaue wrote:

Lew Pitcher:

ze**************@yahoo.com:

...

Why do strcpy and strcat (and strupr and strlwr in some nonstandard
implementations) return a char*? Surely the logical (and DMA-safe)
)return type for these would have been void??

Why should strcat() return a void *, when both of it's arguments are
char *, and the function is defined as working on character strings?

He said void, not void *. And to answer the actual question: I think,
they return char * to allow such things as

return strcat(strcpy(buf, path), file);

Besides, wasn't there originally no such thing as a void function? (I
know I worked on platforms without "void".)

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

[Malcolm]

<ze**************@yahoo.com> wrote

Why do strcpy and strcat (and strupr and strlwr in some nonstandard
implementations) return a char*? Surely the logical (and DMA-safe)
)return type for these would have been void??

History. Originally there was no such keyword as "void" so a function
returned a garbage integer instead of nothing.
They would be better off being void functions now, but that would break back
compatibility.

[Me]

ze**************@yahoo.com wrote:

Why do strcpy and strcat (and strupr and strlwr in some nonstandard
implementations) return a char*?
So you can compose functions without storing it in intermediate
variables.
Surely the logical (and DMA-safe) return type for these would have
been void??

If your compiler generates code that doesn't treat these basic
string/block of memory functions as if the return type was void when
the return value is not used (on a sufficient optimization level), get
a better compiler or write your own versions of these functions.

[Keith Thompson]

"Me" <an*****************@yahoo.com> writes:

ze**************@yahoo.com wrote:

Why do strcpy and strcat (and strupr and strlwr in some nonstandard
implementations) return a char*?
So you can compose functions without storing it in intermediate
variables.

And for backwards compatibility; as others have mentioned here, these
functions predate the existence of void.

Surely the logical (and DMA-safe) return type for these would have
been void??

I have no idea what "zeroDontSpamtype" meant by "DMA-safe". Perhaps
it's some off-topic implementation detail. (The most familiar
expansion of DMA is Direct Memory Access, but I don't see how that's
relevant here.)
If your compiler generates code that doesn't treat these basic
string/block of memory functions as if the return type was void when
the return value is not used (on a sufficient optimization level), get
a better compiler or write your own versions of these functions.

That's probably a useful optimization, but I don't see that it's a
critical one. The overhead of returning and discarding the result is
likely to be trivial. (Though if the call is inlined, it's likely
that the code to generate the result will be discarded anyway.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Kenneth Brody]

Keith Thompson wrote:
[...]

Surely the logical (and DMA-safe) return type for these would have
been void??

I have no idea what "zeroDontSpamtype" meant by "DMA-safe". Perhaps
it's some off-topic implementation detail. (The most familiar
expansion of DMA is Direct Memory Access, but I don't see how that's
relevant here.)

Perhaps strcpy() is on the do-not-call list?

[...]

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>

[zeroNeverNeverSpamtype]

Hi,

By DMA I meant "Dynamic Memory Allocation" although as strupr isn't in
the standard it's sort of do-not-call:-)

The fact that pointers are passed to these functions, so the result
returned has in a way already been returned - hence void being
logical.

I realise now that, unless the implementation is really bad, (ie if
malloc or calloc is used in the function to create a new variable for
the return data - often this is necessary, but not for these functions
which can use one of the input strings), DMA safety won't be an issue
- it's just I've had problems with * returning functions using
malloc/calloc/new (in C++) to create something to return which
couldn't subsequently be deleted in certain circumstances.

Thanks all,

James M.

[mike]

ze********************@yahoo.com wrote:

Hi,

By DMA I meant "Dynamic Memory Allocation" although as strupr isn't in
the standard it's sort of do-not-call:-)

The fact that pointers are passed to these functions, so the result
returned has in a way already been returned - hence void being
logical.

I realise now that, unless the implementation is really bad, (ie if
malloc or calloc is used in the function to create a new variable for
the return data - often this is necessary, but not for these functions
which can use one of the input strings), DMA safety won't be an issue
- it's just I've had problems with * returning functions using
malloc/calloc/new (in C++) to create something to return which
couldn't subsequently be deleted in certain circumstances.

Thanks all,

James M.

I thought DMA stood for "Direct Memory Access", as in - DMA chips... :o?

[Kenny McCormack]

In article <de**********@volcano1.grnet.gr>,
mike <po*************@yahoo.com> wrote:

ze********************@yahoo.com wrote:

Hi,

By DMA I meant "Dynamic Memory Allocation" although as strupr isn't in
the standard it's sort of do-not-call:-)

....I thought DMA stood for "Direct Memory Access", as in - DMA chips... :o?

Hmm... I always thought DMA stood for "David Michael Anderson". He's my
cousin.

[Joe Wright]

ze********************@yahoo.com wrote:

Hi,

By DMA I meant "Dynamic Memory Allocation" although as strupr isn't in
the standard it's sort of do-not-call:-)

The fact that pointers are passed to these functions, so the result
returned has in a way already been returned - hence void being
logical.

I realise now that, unless the implementation is really bad, (ie if
malloc or calloc is used in the function to create a new variable for
the return data - often this is necessary, but not for these functions
which can use one of the input strings), DMA safety won't be an issue
- it's just I've had problems with * returning functions using
malloc/calloc/new (in C++) to create something to return which
couldn't subsequently be deleted in certain circumstances.

Thanks all,

James M.

DMA is a standard computer hardware term Direct Memory Access. You don't
know what it means. I do. When you use DMA in some other way, it makes
my head hurt.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[Randy Howard]

Joe Wright wrote
(in article <-_********************@comcast.com>):

ze********************@yahoo.com wrote:

Hi,

By DMA I meant "Dynamic Memory Allocation" although as strupr isn't in
the standard it's sort of do-not-call:-)

The fact that pointers are passed to these functions, so the result
returned has in a way already been returned - hence void being
logical.

I realise now that, unless the implementation is really bad, (ie if
malloc or calloc is used in the function to create a new variable for
the return data - often this is necessary, but not for these functions
which can use one of the input strings), DMA safety won't be an issue
- it's just I've had problems with * returning functions using
malloc/calloc/new (in C++) to create something to return which
couldn't subsequently be deleted in certain circumstances.

Thanks all,

James M.

DMA is a standard computer hardware term Direct Memory Access. You don't
know what it means. I do. When you use DMA in some other way, it makes
my head hurt.

The problem is that people (even technical people in the
community that should know better) keep using existing acronyms
(and longer terms) over and over again for different meanings.
Perhaps they think that if it was invented while they were in
diapers then it is ripe for replacement.

Somebody once said "We have used up all the good TLAs and now
the FLAs are in jeopardy."
--
Randy Howard (2reply remove FOOBAR)

[Keith Thompson]

mike <po*************@yahoo.com> writes:

ze********************@yahoo.com wrote:

Hi,
By DMA I meant "Dynamic Memory Allocation"

[...] I thought DMA stood for "Direct Memory Access", as in - DMA chips... :o?

Mike, you're responding to month-old articles. We already went over
this.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Kenneth Brody]

Randy Howard wrote:
[...]

DMA is a standard computer hardware term Direct Memory Access. You don't
know what it means. I do. When you use DMA in some other way, it makes
my head hurt.

The problem is that people (even technical people in the
community that should know better) keep using existing acronyms
(and longer terms) over and over again for different meanings.
Perhaps they think that if it was invented while they were in
diapers then it is ripe for replacement.

Somebody once said "We have used up all the good TLAs and now
the FLAs are in jeopardy."

s/FLA/ETLA/

:-)

--
+-------------------------+--------------------+-----------------------------+
| Kenneth J. Brody | www.hvcomputer.com | |
| kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------------+
Don't e-mail me at: <mailto:Th*************@gmail.com>