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)

iD8DBQFC5ickagV FX4UWr64RAmWKAJ 9ymd+jL7wIqVGgr HNTo198BnxJDgCg rXyr
BGAvh0N9wubb8W9 NJLmfxIA=
=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(b uf, 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(b uf, 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 "zeroDontSpamty pe" 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_Keit h) 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 "zeroDontSpamty pe" 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.c om 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?