strangeness with getenv()

[savage54]

Hello again.  HP-UX 11.31, running on PA-RISC.

I have a C program that executes a call to getenv(), and either I'm misreading/misunderstanding the docs, or something isn't working right.  The code I'm working with is:

int my_test_function(char *program)
{

    char *my_path_var;
    . . .
   my_path_var = getnenv("PATH");
    printf("The current path for my process it %s\n", my_path_var);
    . . .
}

If I compile it using 'cc -o my_pgm my_pgm.c', I get an error:

cc: "my_pgm.c", line 431: warning 527: Integral value implicitly converted to pointer in assignment. 

But if I cast the result of getenv():

int my_test_function(char *program)
{

    char *my_path_var;
    . . .
   my_path_var = (char *)getnenv("PATH");
    printf("The current path for my process it %s\n", my_path_var);
    . . .
}

the program compiles with no warnings.

The man page for getenv() states that the function returns a character pointer, and I'm trying to assign it to a variable that is defined as a character pointer.  So why do I have to explicitly cast the result to character pointer?

[Steven Schweda]

> [...] HP-UX 11.31, running on PA-RISC.

   Which C compiler?

>    my_path_var = getnenv("PATH");

   Have you tried spelling "getenv" correctly?

> cc: "my_pgm.c", line 431: warning 527: Integral value implicitly
> converted to pointer in assignment.

   Is that the only complaint that you get?  I'd expect something about
an implicit declaration of "getnenv()" (which, lacking an explicit
declaration, would be treated as type "int").

   I'd also expect a complaint at link time.

[savage54]

Sorry I didn't reply sooner.  I neglected to click the "Email me" box, so I wasn't notified that there was a response.  I've confirmed that I checked that box now.

Output from running 'cc -V -g -o my_pgm my_pgm.c':

cpp.ansi: HP92453-01 B.11.11.18 HP C Preprocessor (ANSI)
ccom: HP92453-01 B.11.11.18 HP C Compiler
cc: "my_pgm.c", line 431: warning 527: Integral value implicitly converted to pointer in assignment.
/usr/ccs/bin/ld: 92453-07 linker linker ld B.11.70 100609

On the typo, I'm not sure how that happened.  I clicked on the Insert code sample, but I must have inadvertently added that extra 'n' character.  Given that there is no 'getnenv' function anywhere in my program, there definitely would have been an error at link time.  I have confirmed that the code I am compiling is using the correct spelling:

    my_path_envvar = (char*)getenv("PATH");
    printf("Current PATH is %s\n", my_path_envvar);

[Steven Schweda · Accepted solution]

> [...] I've confirmed that I checked that box now.

   Some other-company Lithium forums are configured to pre-check that
box, but not these HPE ones, it seems.  Complain here:

      https://community.hpe.com/t5/x/bd-p/community-feedback-suggestions

> [...] I have confirmed that the code I am compiling is using the
> correct spelling: [...]

   Ok.

> The man page for getenv() states [...]

   I'd bet that it also mentions "#include <stdlib.h>".  If you omit
that, then you won't have a proper declaration of getenv(), and you'll
get the implicit type "int".

   I don't have a real-money HP[E] C compiler, only an old GCC (and on
IA64, too), but around here, without the <stdlib.h>, I get a similar
complaint:

dyi $ gcc -c getnenv.c
getnenv.c: In function 'my_test_function':
getnenv.c:8: warning: assignment makes pointer from integer without a cast
dyi $

_With_ "#include <stdlib.h>", all is quiet:

dyi $ gcc -c getnenv_d.c
dyi $

dyi $ diff getnenv.c getnenv_d.c
1a2
> #include <stdlib.h>
dyi $

dyi $ gcc -v
Using built-in specs.
Target: ia64-hp-hpux11.31
Configured with: ../gcc-4.3.3/configure
Thread model: posix
gcc version 4.3.3 (GCC)

   On a VMS system, you get more help (by default):

its $ cc getnenv

my_path_var = getenv("PATH");
.................^
%CC-I-IMPLICITFUNC, In this statement, the identifier "getenv" is implicitly dec
lared as a function.
at line number 8 in file ITS$DKA0:[SMS.itrc]getnenv.c;2

my_path_var = getenv("PATH");
...^

%CC-W-CVTDIFTYPES, In this statement, "getenv(...)" of type "int", is being conv
erted to "pointer to char".
at line number 8 in file ITS$DKA0:[SMS.itrc]getnenv.c;2
its $

   Or, on a Mac:

pro3$ cc -c getnenv.c
getnenv.c:8:18: warning: implicit declaration of function 'getenv' is invalid in
C99 [-Wimplicit-function-declaration]
my_path_var = getenv("PATH");
^
getnenv.c:8:16: warning: incompatible integer to pointer conversion assigning to
'char *' from 'int' [-Wint-conversion]
my_path_var = getenv("PATH");
^ ~~~~~~~~~~~~~~
2 warnings generated.
pro3$

   Of course, with "#include <stdlib.h>", everyone's happy:

its $ cc getnenv_d
its $

its $ cc /version
HP C V7.3-020 on OpenVMS IA64 V8.4

pro3$ cc -c getnenv_d.c
pro3$

pro3$ cc -v
Apple LLVM version 8.0.0 (clang-800.0.42.1)
Target: x86_64-apple-darwin15.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/
XcodeDefault.xctoolchain/usr/bin

   One of the problems with trying to debug a code fragment, is that
it's a code fragment, not an actual test case.

[savage54]

That was it!  I had omitted <stdlib.h> from the list of #includes.  I had 12 other #includes, but I missed that one.  After adding that, and removing the explicit cast, it compiles with no warnings.

Thank you for spotting that oversight.  

[Steven Schweda]

> That was it! [...]0

   Thanks for the report.  (What could go wrong?)

   If I were relying on a compiler which didn't have, by default, a
specific warning for implicit function declarations, then I'd be looking
for an option to enable one.  (Or for a better compiler.)  You might get
by (silently) for an integer-returning function, but you still won't get
the argument type-checking which an actual function prototype provides.

   Relying on yourself never to omit a required header file is a
technique which has been demonstrated to be inadequate.