what does strdup return

T

thomas

Hi,

It's known that strdup() returns a char* type, but sometimes the
following code generates warning messages.

char *x = ...
char *p = strdup(x);

You must change it to

char *p = (char*) strdup(x);

why?
 
N

Nick Keighley

It's known that strdup() returns a char* type,

strdup() isn't mentioned in the C Standard and it's in a reserved
namespace to boot; so you can't define it yourself.
So we don't really know anything about it.

but sometimes the
following code generates warning messages.

char *x = ...
char *p = strdup(x);

You must change it to

char *p = (char*) strdup(x);

why?

I suspect there is no prototype in scope for strdup().
string.h may not declare it (I'm not sure it's allowed to declare
it, in conmforming mode).

You need to ask the question of your implementation for more
certain guidance.


--
Nick Keighley

Server rooms should be unfriendly! They should look dangerous,
they should be uncomfortably cold, they should be inexplicably noisy.
If you can arrange for the smell of burning transistors, that's good
too.
If anything, I'd rather see rackmounted servers designed in dark
foreboding
colors with lots of metal spikes sticking out of them.
Mike Sphar (on news//alt.sysadmin.recovery)
 
R

Richard Tobin

thomas said:
It's known that strdup() returns a char* type, but sometimes the
following code generates warning messages.

char *x = ...
char *p = strdup(x);

You must change it to

char *p = (char*) strdup(x);

why?

Because you have not declared strdup(), and not included a header that
declares it. You have also apparently not run your compiler in a mode
where it complains about undeclared functions.

"Fixing" the problem by adding a cast won't work reliably on systems
where pointers are longer than integers, or where the return
conventions for pointers and integers are different.

-- Richard
 
V

vippstar

strdup() isn't mentioned in the C Standard and it's in a reserved
namespace to boot; so you can't define it yourself.

You can if you don't include said:
I suspect there is no prototype in scope for strdup().
string.h may not declare it (I'm not sure it's allowed to declare
it, in conmforming mode).

It is allowed, since as you said, strdup is implementation namespace.
 
V

vippstar

(e-mail address removed) wrote: [about using str* identifiers]
You can if you don't include <string.h>

No.
N869
7.26 Future library directions
[#1] The following names are grouped under individual
headers for convenience. All external names described below
are reserved no matter what headers are included by the
program.

7.26.10 General utilities <stdlib.h>
[#1] Function names that begin with str and a lowercase
letter

Ah, sorry for this. I remember reading what I've said in a previous
discussion...
I think it was you who said it? I don't remember very well.
 
H

Harald van Dijk

(e-mail address removed) wrote: [about using str* identifiers]
You can if you don't include <string.h>

No.
N869
7.26 Future library directions
[#1] The following names are grouped under individual
headers for convenience. All external names described below
are reserved no matter what headers are included by the
program.

7.26.10 General utilities <stdlib.h> [#1] Function names that
begin with str and a lowercase letter

Ah, sorry for this. I remember reading what I've said in a previous
discussion...
I think it was you who said it? I don't remember very well.

You had it half right the first time. You can define str* functions, but
you can't define str* external names. This is a correct program:

/* no headers */
static int strdup(void) { return 0; }
int main(void) { return strdup(); }
 
A

Antoninus Twink

strdup() isn't mentioned in the C Standard and it's in a reserved
namespace to boot; so you can't define it yourself.

What makes you think he's defining it himself?

strdup() *is* mentioned in the POSIX standard, and is declared in
string.h. It returns a pointer to a new string which is a duplicate of
the string s. Memory for the new string is obtained with malloc(), and
can be freed with free().
 
P

Peter Nilsson

Nick Keighley said:
strdup() isn't mentioned in the C Standard and it's
in a reserved namespace to boot;

It's precisely because it's in a reserved namespace that
implementations can (and many do) offer it as an extension.
 
C

CBFalconer

Peter said:
It's precisely because it's in a reserved namespace that
implementations can (and many do) offer it as an extension.

See the C standard. Note the last sentence of #1.

7.26 Future library directions

[#1] The following names are grouped under individual
headers for convenience. All external names described below
are reserved no matter what headers are included by the
program.

... snip ...

7.26.10 General utilities <stdlib.h>

[#1] Function names that begin with str and a lowercase
letter (possibly followed by any combination of digits,
letters, and underscore) may be added to the declarations in
the <stdlib.h> header.

7.26.11 String handling <string.h>

[#1] Function names that begin with str, mem, or wcs and a
lowercase letter (possibly followed by any combination of
digits, letters, and underscore) may be added to the
declarations in the <string.h> header.
 
T

Tinkertim

Hi,

It's known that strdup() returns a char* type, but sometimes the
following code generates warning messages.

char *x = ...
char *p = strdup(x);

You must change it to

char *p = (char*) strdup(x);

why?

If you have indeed included string.h , I'd be very curious to know
details about your compiler and C library. It would also help to post
your code up to the first call of strdup() as well as the compiler
flags being used.

Some symbol may be preventing string.h from exposing strdup() (some
strict mode) .. or another may need to explicitly turn it on.

For instance, in GNU C, you must define _GNU_SOURCE in order for
asprintf() to be exposed in stdio.h.

Is the warning talking about an implicit declaration?

Cheers,
--Tim
 
T

thomas

If you have indeed included string.h , I'd be very curious to know
details about your compiler and C library. It would also help to post
your code up to the first call of strdup() as well as the compiler
flags being used.

Some symbol may be preventing string.h from exposing strdup() (some
strict mode) .. or another may need to explicitly turn it on.

For instance, in GNU C, you must define _GNU_SOURCE in order for
asprintf() to be exposed in stdio.h.

Is the warning talking about an implicit declaration?

Cheers,
--Tim

Thanks to you all!
I didn't include the "string.h" file and it gets ok when the file
included.
If it's not included, the warning says that "don't try to assign an
integer to a pointer" something like that.
 
D

Default User

thomas wrote:

If it's not included, the warning says that "don't try to assign an
integer to a pointer" something like that.

That would have been a very useful thing to include in the original
problem description.




Brian
 

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

No members online now.

Forum statistics

Threads
474,432
Messages
2,571,680
Members
48,796
Latest member
Greg L.

Latest Threads

Top