Missing prototype for strdup

[pointercrash()]

What's wrong with that?

Code: [Select]

#include <stdio.h>
#include <string.h>
#include <stdlib.h>

char *stringback(void);
char *stringback(void)
{
char *returnstring = NULL;

returnstring = strdup("Hello, world!\n");
return returnstring;
}

int main(int argc, char *argv[])
{
char *theoutput = NULL;

theoutput = stringback();
if (theoutput)
{
       printf(theoutput);
   free(theoutput);
}
    return 0;
}
causes
T:\strdup\main.c(10): warning #2027: Missing prototype for 'strdup'.
T:\strdup\main.c(10): error #2168: Operands of = have incompatible types 'char *' and 'int'.

It looks as if the prototype for "strdup" in <string.h> was simply forgotten - could that be true
Btw, strndup was a little bit more solid, but isn't implemented.

[JohnF]

strdup is not part of ANSI C - Pelle tends to make these non standard functions start with an underscore.

_strdup

John

[pointercrash()]

You're kidding 
The wizard (or whatever the name is) for completion of function arguments recognized the function with or without underscore. This enforces the impression that everything is fine.
"Pelle tends to" is no fixable rule, it competes with weather forecasts in april.

[JohnF]

No I'm not kidding.

If you define __POCC__OLDNAMES at the top of your code PellesC will use the name without the underscore.

EDIT: Personally if in doubt I look in the header file.

John

[Pelle]

The strdup() and strndup() functions are not part of standard C (C99), but exist as _strdup() and _strndup() extensions. The strdup() function is defined in Posix; this implementation is for Windows - and not Unix - so implementing the full Posix standard is pointless, but a certain amount of common Posix functions (and possibly from other standards) are defined for "compatibility" reasons - strdup() is one of them.

You can enable compatibility names with the /Go compiler option, and this option will define the __POCC__OLDNAMES symbol. This is the recommended way of defining the __POCC__OLDNAMES symbol.

The strdup() and strndup() functions happens to be special here since they are also defined by the standard C people in a technical report, ISO TR24731 part 2, as extensions to standard C - which may be part of a future C standard. As of version 6.0 most functions from ISO TR24731-2 are implemented. The IDE will color C runtime functions from a fixed table to indicate a link to the help file for the name (press F1 when the caret is on such a name).

All of this can be found in the help file. If more people bothered to read it, many "bug" reports could be avoided...

[Seltsamuel]

Hi,

sorry that i jump in but many "Bugreports" on this behavior indicate that pellesC is behaving in a uncommon manner ;-)

When i want to use one of the functions that pellesC includes and not belongs to the basic c99 standard why append a prefix?
I for my case include the header and assume that i can use the function (when i choosed the right header ^^) wouldnt it be enough to simply make a diference through different coloring inside the IDE ? why prefix _ ? this is uncommon and i know no other compiler behaving this way maybe this leads to wrong bug reports.

Greetings

Seltsamuel

[Pelle]

sorry that i jump in but many "Bugreports" on this behavior indicate that pellesC is behaving in a uncommon manner ;-)

No, it's an indication the user is completely ignorant - at least about C, and possibly about life in general. As a user you are expected to bring some intelligence to the party - a brain is not included in the download. The end result is that I will just ignore bogus "bug" reports, and ignorant users in general. Good bye.

[Robert]

Hi,
sorry that i jump in but many "Bugreports" on this behavior indicate that pellesC is behaving in a uncommon manner ;-)
....
why prefix _ ? this is uncommon and i know no other compiler behaving this way
Greetings
Seltsamuel

Yes I guess Microsoft is so uncommon that their C/C++ compiler functions prepended with an underscore, listed in their alphabetical reference to the routines in the Microsoft C Run-Time (CRT) Library, would not have been noticed by anyone.

Robert Wishlaw

[pointercrash()]

I don't want to bother,

but i made NO mistake. As i typed strdup( the little helper popped up with

"char * __cdecl strdup(const char *)"

, the missing part inverted.
I filled that gap, no error, no pain, usually, but not in this case.

I don't care as much as i can and as long as i have no hint what i might have done wrong, i can't correct anything at the "upper" level. If it's no bug it's an inconveniance at least to review the header files. Finally i found the __POCC__OLDNAMES switch, but that was rather hidden, in the helping files i found anything not yet now.
Might be a hint to make the next version better, less misunderstandable.

But spreading insults like brainless "ignorant users" posting bogus to be ignored will NOT lead to constructive solutions.

I simply told where some problems came up, sorry for asking ...

[Seltsamuel]

Hi,

@Pelle
I told inside some posts that im from the Unix side of the world and i only told that I know of no compiler behaving like this on a strdup()
even dev/c++ and derivates  / open watcom dont need this and as pointercrash()  confirmed its inside YOUR helpfile too without underscore.
I dont know about microsoft compilers behavior because i dont have one and especially avoid personal use of microsoft bloatware. Im Programmer since more than 20 years and yes my fault on posix systems Linux / Solaris / HP UX / SCO Open Server. When i would use microsoft compiler i had no need for pellesc so excuse my "Ignorance" because i want to learn something on the windows side in my spare time and together with it report bugs and uncommon behaviors to try to help you getting PellesC better. I not awaited to get flamed from the Admin so i wont do the mistake again to report something or tell my opinion.

Greetings

Seltsamuel