strcpy and strcat's return type

G

Guest

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.
 
L

Lew Pitcher

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

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+jL7wIqVGgrHNTo198BnxJDgCgrXyr
BGAvh0N9wubb8W9NJLmfxIA=
=6TrQ
-----END PGP SIGNATURE-----
 
J

Jirka Klaue

Lew Pitcher:
(e-mail address removed): ....

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
 
K

Kenneth Brody

Jirka said:
Lew Pitcher:

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:[email protected]>
 
M

Malcolm

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.
 
M

Me

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.
 
K

Keith Thompson

Me said:
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.

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.)
 
K

Kenneth Brody

Keith Thompson wrote:
[...]
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:[email protected]>
 
G

Guest

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.
 
M

mike

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... :eek:?
 
K

Kenny McCormack

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

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

Joe Wright

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.
 
R

Randy Howard

Joe Wright wrote
(in article said:
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."
 
K

Kenneth Brody

Randy Howard wrote:
[...]
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:[email protected]>
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top