Unix Programming - extern int VALUE vs int VALUE

Author

extern int VALUE vs int VALUE

Chad

2005-12-22, 7:50 am

I thought the following two program snippets where doing the same
thing. I think I'm wrong. On the second snippet, I get the following
error message: env.c:7: warning: unused variable `VALUE'.

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

extern char **environ;
extern int VALUE;

int main(void) {
char *s = getenv("VALUE");

if(s == NULL)
exit(1);
else
printf("The value of a ho is: %s \n", s);
return 0;
}

$gcc -Wall env.c -o env
$export VALUE=88
$./env
The value of a ho is: 88
$

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

extern char **environ;

int main(void) {
int VALUE = 0;
char *s = getenv("VALUE");

if(s == NULL)
exit(1);
else
printf("The value of a ho is: %s \n", s);
return 0;
}

$gcc -Wall env.c -o env
env.c: In function `main':
env.c:7: warning: unused variable `VALUE'
$export VALUE=88
$./env
The value of a ho is: 88
$

Can someone enlighten me as to what is going on?

Thanks in advance,
Chad

Maxim Yegorushkin

2005-12-22, 7:50 am

Chad wrote:

You should probably direct your question to comp.lang.c/c++ as it's not
directly related to unixes.

> I thought the following two program snippets where doing the same
> thing. I think I'm wrong. On the second snippet, I get the following
> error message: env.c:7: warning: unused variable `VALUE'.

The observable behaviour of the programs is indeed the same. The code,
however, is not.

[]

> Can someone enlighten me as to what is going on?

The compiler warns you that you have an unused variable. It might also
do that for the second snippet.

Hubble

2005-12-22, 7:50 am

>I thought the following two program snippets where doing the same
>thing. I think I'm wrong. On the second snippet, I get the following
>error message: env.c:7: warning: unused variable `VALUE'.

> extern int VALUE;
> char * s=getenv("VALUE");

>vias

> int VALUE;
> char * s=getenv("VALUE");

Do not confuse environment variables with C program variables. In
either case, you do not use the variable VALUE at all. In the second,
the compiler can recognize this because VALUE is local to the text
file.

You have to do something like VALUE=atoi(s) to assign the desired value
from the environment getenv("VALUE");

Please do not write C-Variables in upper case. Upper case is reserved
for macros, so use "int value;" instead of "int VALUE;". Either one is
not connected to the environment.

In real code, be sure to check the return value of getenv is not NULL.

Hubble.

ilko.k.v@gmail.com

2005-12-22, 7:50 am

One solution

#include<unistd.h>
#include<stdio.h>

int main()
{
unsigned value;

sscanf(getenv("VALUE")? :"0","%d",&value);
printf("===> %d\n",value);

return 0;
}

Chad

2005-12-22, 7:50 am

Hubble wrote:
>
>
>
>
> Do not confuse environment variables with C program variables. In
> either case, you do not use the variable VALUE at all. In the second,
> the compiler can recognize this because VALUE is local to the text
> file.
>
> You have to do something like VALUE=atoi(s) to assign the desired value
> from the environment getenv("VALUE");
>
> Please do not write C-Variables in upper case. Upper case is reserved
> for macros, so use "int value;" instead of "int VALUE;". Either one is
> not connected to the environment.
>
> In real code, be sure to check the return value of getenv is not NULL.
>
> Hubble.

I've also seen the used in other places than macros. Like the
following:
NAME
efence - Electric Fence Malloc Debugger

SYNOPSIS
#include <stdlib.h>

void * malloc (size_t size);

void free (void *ptr);

void * realloc (void *ptr, size_t size);

void * calloc (size_t nelem, size_t elsize);

void * memalign (size_t alignment, size_t size);

void * valloc (size_t size);

extern int EF_ALIGNMENT;

extern int EF_PROTECT_BELOW;

extern int EF_PROTECT_FREE;

extern int EF_ALLOW_MALLOC_0;

extern int EF_FILL;

I guess that is where I picked up the caps thingies.

Chad

Hubble

2005-12-22, 5:57 pm

>I've also seen the used in other places than macros. Like the
>following:
>...
>#include <stdlib.h>
>...
>extern int EF_ALIGNMENT;
>...

Yes. These seem to have been macros once and are now replaced by
"extern int"s. They can be used like macros, and code formerly using
macros can safely use them instead, so a programmer won't notice the
difference.

However, to make your own code readable, you should follow the common
convenctions, and only deviate where appropriate. (Some of) These are
for the C language:
- macros usually in upper case
- variables in lower case
- procedure names lower case or mixed case

Sometimes, macros are replaced by variables and vice versa. A famous
example is the "errno" variable when using threads. It is then a macro
which dereferences the errno location for the current thread. Code
using "if (errno<0)" and such won't notice, but will continue to work
in a multithreaded program.

Hubble.

Chad

2005-12-22, 8:51 pm

So in other words, I could have something like this:

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

int main(void) {
int VALUE = 0;

char *s = getenv("VALUE");

if(s == NULL)
exit(1);
else{
printf("The value of a ho is: %d \n", atoi(s));
}
return 0;
}

And for whatever reasons, I don't want the user to know about the
variable 'VALUE'. However, this value still can be modified. Because
when I go something like:

$export VALUE=90
$./env
The value of a ho is: 90

Is there anykind of safeguard against this kind of scenario?

Chad

Erik Max Francis

2005-12-22, 8:51 pm

Chad wrote:

> And for whatever reasons, I don't want the user to know about the
> variable 'VALUE'. However, this value still can be modified. Because
> when I go something like:
>
> $export VALUE=90
> $./env
> The value of a ho is: 90
>
> Is there anykind of safeguard against this kind of scenario?

The variable VALUE is not used anywhere. You need to be clearer about
what it is you want to achieve, because so far what you're doing has no
effect on your program's behavior whatsoever (outside of harmless
compiler warnings).

--
Erik Max Francis && max@alcyone.com && http://www.alcyone.com/max/
San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis
I am become death, the destroyer of worlds.
-- J. Robert Oppenheimer (quoting Hindu legend)

Chad

2005-12-22, 8:51 pm

Erik Max Francis wrote:
> Chad wrote:
>
>
> The variable VALUE is not used anywhere. You need to be clearer about
> what it is you want to achieve, because so far what you're doing has no
> effect on your program's behavior whatsoever (outside of harmless
> compiler warnings).
>
> --
> Erik Max Francis && max@alcyone.com && http://www.alcyone.com/max/
> San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis
> I am become death, the destroyer of worlds.
> -- J. Robert Oppenheimer (quoting Hindu legend)

Okay, maybe I'm missing this. If doing something like
$export VALUE=90
has no effects on the programs behavior, then how come the program I
ran will print the value of 'VALUE' set at the bash shell?

Chad

Erik Max Francis

2005-12-23, 2:50 am

Chad wrote:

> Okay, maybe I'm missing this. If doing something like
> $export VALUE=90
> has no effects on the programs behavior, then how come the program I
> ran will print the value of 'VALUE' set at the bash shell?

Your declaration/definition of a variable called VALUE inside the
program is what is having no effect.

--
Erik Max Francis && max@alcyone.com && http://www.alcyone.com/max/
San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis
But when I reached the finished line / Young black male
-- Ice Cube

Chad

2005-12-23, 2:50 am

Erik Max Francis wrote:
> Chad wrote:
>
>
> Your declaration/definition of a variable called VALUE inside the
> program is what is having no effect.
>
> --
> Erik Max Francis && max@alcyone.com && http://www.alcyone.com/max/
> San Jose, CA, USA && 37 20 N 121 53 W && AIM erikmaxfrancis
> But when I reached the finished line / Young black male
> -- Ice Cube

Ahhhhhhhhh.......Okay. Now I understand.

Thanks
Chad

Daniel C. Bastos

2005-12-24, 8:48 pm

In article <1135253422.531901.25270@g47g2000cwa.googlegroups.com>,
Hubble wrote:

>
>
>

[...]
[vbcol=seagreen]
> In real code, be sure to check the return value of getenv is not NULL.

He made sure. You removed ``if(s == NULL) exit(1);'' from his post.