AIX C compiler message unexplainable

[andreas.luethi]

Hi All

Compile a our source with BM XL C/C++ Enterprise Edition V8.0 for AIX
(Version: 08.00.0000.0000) produces a lot of Informational message
like this:

"aaalib.c", line 671.1: 1506-412 (I) Referenced variable "n", which
was not initialized in its declaration.

n is a variable in procedure an is assigned before used. Compiling the
same sources with other compiles such as AIX version 7.0, gcc on
linux etc do not display this information.

Appreciate your help in this regard,

Thanks,
Andreas

 

[jacob navia]

Hi All

Compile a our source with BM XL C/C++ Enterprise Edition V8.0 for AIX
(Version: 08.00.0000.0000) produces a lot of Informational message
like this:

"aaalib.c", line 671.1: 1506-412 (I) Referenced variable "n", which
was not initialized in its declaration.

n is a variable in procedure an is assigned before used. Compiling the
same sources with other compiles such as AIX version 7.0, gcc on
linux etc do not display this information.

Appreciate your help in this regard,

Thanks,
Andreas

Please go to IBM help desk. We are NOT IBM help desk.

Thanks for your understanding.

 

[jacob navia]

Hi All

Compile a our source with BM XL C/C++ Enterprise Edition V8.0 for AIX
(Version: 08.00.0000.0000) produces a lot of Informational message
like this:

"aaalib.c", line 671.1: 1506-412 (I) Referenced variable "n", which
was not initialized in its declaration.

n is a variable in procedure an is assigned before used. Compiling the
same sources with other compiles such as AIX version 7.0, gcc on
linux etc do not display this information.

Appreciate your help in this regard,

Thanks,
Andreas

P.S. It would be maybe better to SHOW where the compiler
complains, where you think it is wrong with
concrete examples, if not it is not possible to help you
anyway.

 

[andreas.luethi]

P.S. It would be maybe better to SHOW where the compiler
complains, where you think it is wrong with
concrete examples, if not it is not possible to help you
anyway.

here is the code snipped:

void aaalib_trim (char *in) {
int n;
for (n = (strlen(in)) - 1; n>= 0; n--)
if (!isspace(in[n]))
break;
in[n+1] = '\0';
}

 

[jacob navia]

P.S. It would be maybe better to SHOW where the compiler
complains, where you think it is wrong with
concrete examples, if not it is not possible to help you
anyway.

here is the code snipped:

void aaalib_trim (char *in) {
int n;
for (n = (strlen(in)) - 1; n>= 0; n--)
if (!isspace(in[n]))
break;
in[n+1] = '\0';
}

If the code is *exactly* as you posted then...
this looks like a bug in IBM's compiler. Note that version
Version: 08.00.0000.0000 is outdated. I have received a patch
after that one.

OR

The warning just says that you reference a variable
that was not initialized at its declaration... This could
be a very misleading warning. Try to do

> void aaalib_trim (char *in) {
> int n = 78887; // <<<<----- here
> for (n = (strlen(in)) - 1; n>= 0; n--)
> if (!isspace(in[n]))
> break;
> in[n+1] = '\0';
> }

If the warning disappears it means that this is the case.

 

[Roberto Waltman]

here is the code snipped:

void aaalib_trim (char *in) {
int n;
for (n = (strlen(in)) - 1; n>= 0; n--)
if (!isspace(in[n]))
break;
in[n+1] = '\0';
}

An uneducated guess: the compiler misses the initialization in the
for(..) statement. Try this:

void aaalib_trim (char *in) {
int n = strlen(in) - 1;
for ( ; n>= 0; n--)
if (!isspace(in[n]))
break;
in[n+1] = '\0';
}

strlen(in) is always greater than 1, right?

 

[jacob navia]

void aaalib_trim (char *in) {
int n = strlen(in) - 1;
for ( ; n>= 0; n--)
if (!isspace(in[n]))
break;
in[n+1] = '\0';
}

strlen(in) is always greater than 1, right?

strlen can be zero. Then, strlen(in)-1 is -1.
Since he tests for n>=0 the loop never gets
executed.
Then, in[n+1] == in[0] == 0 anyway since
strlen gave zero, so he overwrites a zero with a zero,
a harmless operation

 

[vipvipvipvip.ru]

void aaalib_trim(char *in) {
size_t n = strlen(in);
if(n != 0) {
while(isspace(in[--n]))
;
in[n+1] = 0;
}
return;
}

The compiler is probably buggy.
If the for loop is the issue, the above code will
compile with no errors.
But i wouldn't use a compiler that cannot properly
parse and check C code..

 

[CBFalconer]

Compile a our source with BM XL C/C++ Enterprise Edition V8.0 for
AIX (Version: 08.00.0000.0000) produces a lot of Informational
message like this:

"aaalib.c", line 671.1: 1506-412 (I) Referenced variable "n",
which was not initialized in its declaration.

n is a variable in procedure an is assigned before used. Compiling
the same sources with other compiles such as AIX version 7.0, gcc
on linux etc do not display this information.

After close examination of the detailed source provided, I conclude
that the error is in line 42.

 

[CBFalconer]

.... snip ...

here is the code snipped:

void aaalib_trim (char *in) {
int n;
for (n = (strlen(in)) - 1; n>= 0; n--)
if (!isspace(in[n]))
break;
in[n+1] = '\0';
}

strlen returns a size_t. An int is not necessarily able to hold a
size_t.

 

[David Tiktin]

void aaalib_trim(char *in) {
size_t n = strlen(in);
if(n != 0) {
while(isspace(in[--n]))
;

If the string "in" consists of all whitespace, what prevents this loop
from taking a walk in the weeds? What happens when n == 0 and in[0] is
a space? Probably not what you want ;-)

in[n+1] = 0;
}
return;
}

Dave

 

[J. J. Farrell]

Hi All

Compile a our source with BM XL C/C++ Enterprise Edition V8.0 for AIX
(Version: 08.00.0000.0000) produces a lot of Informational message
like this:

"aaalib.c", line 671.1: 1506-412 (I) Referenced variable "n", which
was not initialized in its declaration.

n is a variable in procedure an is assigned before used. Compiling the
same sources with other compiles such as AIX version 7.0, gcc on
linux etc do not display this information.

Appreciate your help in this regard,

What are you looking for help with exactly? The message is nonsense,
but if we replace "declaration" with "definition" (which I assume is
what they really meant) then it makes sense. It's a remarkably stupid
thing to inform you about unless you've explicitly asked it to do so,
but the compiler's free to inform you about whatever it likes. It's a
wrongly worded and remarkably silly piece of implementation; I'd
complain to the implementor.

 

[Eric Sosman]

void aaalib_trim (char *in) {
int n = strlen(in) - 1;
for ( ; n>= 0; n--)
if (!isspace(in[n]))
break;
in[n+1] = '\0';
}

strlen(in) is always greater than 1, right?

strlen can be zero. Then, strlen(in)-1 is -1.

Actually, `strlen("")-1' is `(size_t)-1', an unsigned
value that is at least 65535 and possibly larger. On most
systems, converting this large value to an `int' will yield
the value -1, but that's just dumb luck and not a feature
of the C language.

 

[A. Bolmarcich]

[snip]
here is the code snipped:

void aaalib_trim (char *in) {
int n;
for (n = (strlen(in)) - 1; n>= 0; n--)
if (!isspace(in[n]))
break;
in[n+1] = '\0';
}

Does the compiler write the message when you compile that snippet?
What compiler options are you using?

 

[Keith Thompson]

Compile a our source with BM XL C/C++ Enterprise Edition V8.0 for AIX
(Version: 08.00.0000.0000) produces a lot of Informational message
like this:

"aaalib.c", line 671.1: 1506-412 (I) Referenced variable "n", which
was not initialized in its declaration.

[...]
P.S. It would be maybe better to SHOW where the compiler
complains, where you think it is wrong with
concrete examples, if not it is not possible to help you
anyway.

here is the code snipped:

void aaalib_trim (char *in) {
int n;
for (n = (strlen(in)) - 1; n>= 0; n--)
if (!isspace(in[n]))
break;
in[n+1] = '\0';
}

Did you merely snip that from your program, or did you actually feed
that smaller chunk of code to the compiler? If the latter, you should
add #include directives for <string.h> and <ctype.h>.

I get that message when I use "xlc -qinfo=uni", which according to the
man page diagnoses "Possible problems with initialization". I also
get it with "-qinfo", which enables all such messages (and gives me
over 600 lines of messages for the standard headers).

I'm a little surprised that the message is produced, since n is never
actually used before a value is assigned to it.

The "(I)" denotes an informational message, which is even less severe
than a warning.

Either the "-qinfo=uni" option is slightly buggy, or it's intended to
encourage a programming style in which *all* variables are initialized
when they're defined. Such a style guarantees that all variables will
have defined values when they're accessed (though it doesn't guarantee
that they'll have *meaningful* values).

Determining that n is never actually accessed before a value has been
assigned to it requires dataflow analysis, which is more work for the
compiler.

As far as the standard is concerned, this is all perfectly legitimate.
A compiler is required to produce diagnostics only for syntax errors,
constraint violations, and the #error directive, none of which occur
in your code sample -- but it's allowed to produce any additional
diagnostics it likes.

See the man page for information on how to disable particular messages
(though I suspect that disabling this particular message might disable
messages about actual uses of uninitialized variables). Failing that,
comp.unix.aix is probably a better place to ask. There *might* be a
way to tell the compiler to warn more intelligently about possible use
of uninitialized variables.

 

[andreas.luethi]

(e-mail address removed) wrote:
Compile a our source with BM XL C/C++ Enterprise Edition V8.0 for AIX
(Version: 08.00.0000.0000) produces a lot of Informational message
like this:
"aaalib.c", line 671.1: 1506-412 (I) Referenced variable "n", which
was not initialized in its declaration. [...]
P.S. It would be maybe better to SHOW where the compiler
complains, where you think it is wrong with
concrete examples, if not it is not possible to help you
anyway.

here is the code snipped:

void aaalib_trim (char *in) {
int n;
for (n = (strlen(in)) - 1; n>= 0; n--)
if (!isspace(in[n]))
break;
in[n+1] = '\0';
}

Did you merely snip that from your program, or did you actually feed
that smaller chunk of code to the compiler? If the latter, you should
add #include directives for <string.h> and <ctype.h>.

I get that message when I use "xlc -qinfo=uni", which according to the
man page diagnoses "Possible problems with initialization". I also
get it with "-qinfo", which enables all such messages (and gives me
over 600 lines of messages for the standard headers).

I'm a little surprised that the message is produced, since n is never
actually used before a value is assigned to it.

The "(I)" denotes an informational message, which is even less severe
than a warning.

Either the "-qinfo=uni" option is slightly buggy, or it's intended to
encourage a programming style in which *all* variables are initialized
when they're defined. Such a style guarantees that all variables will
have defined values when they're accessed (though it doesn't guarantee
that they'll have *meaningful* values).

Determining that n is never actually accessed before a value has been
assigned to it requires dataflow analysis, which is more work for the
compiler.

As far as the standard is concerned, this is all perfectly legitimate.
A compiler is required to produce diagnostics only for syntax errors,
constraint violations, and the #error directive, none of which occur
in your code sample -- but it's allowed to produce any additional
diagnostics it likes.

See the man page for information on how to disable particular messages
(though I suspect that disabling this particular message might disable
messages about actual uses of uninitialized variables). Failing that,
comp.unix.aix is probably a better place to ask. There *might* be a
way to tell the compiler to warn more intelligently about possible use
of uninitialized variables.

--
Keith Thompson (The_Other_Keith) (e-mail address removed) <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

The code is only a small snip, the whole source has all the #include
directives.

The make file we use includes an other one from oracle (env_rdbms.mk)
which has a "-qinfo=uni" in it. I could compile with "-qflag=w:w",
that
seems to override the qinfo, but then I also miss all other "(I)"
messages
as well. An other solution is to change the qinfo from env_rdbms.mk in
my
makefile with: "CCFLAGS += -qnoinfo".

The compiler Information "...was not initialized in its declaration"
is of
course true, but as you mentioned n is never accessed before a value
has
been assigned. But this seem to me an unnecessary information unless I
use
such a uninitialized variable.

Andreas

 

[Mark Bluemel]

The make file we use includes an other one from oracle (env_rdbms.mk)
which has a "-qinfo=uni" in it.

http://tinyurl.com/26j5b6 suggests that everything is behaving as
designed. The make files request this warning, so the compiler provides it.

I suggest you try adding -qinfo=nouni to your options, after the oracle
make file has been included, if you don't want the information.

 

[Charlie Gordon]

void aaalib_trim (char *in) {
int n = strlen(in) - 1;
for ( ; n>= 0; n--)
if (!isspace(in[n]))
break;
in[n+1] = '\0';
}

strlen(in) is always greater than 1, right?

strlen can be zero. Then, strlen(in)-1 is -1.

Actually, `strlen("")-1' is `(size_t)-1', an unsigned
value that is at least 65535 and possibly larger. On most
systems, converting this large value to an `int' will yield
the value -1, but that's just dumb luck and not a feature
of the C language.

That is not dumb luck, it is a well-thought side-effect of 2s complement
representation and wrap-around arithmetics.
IMO, it *should* be made a feature of the language so conversions between
signed and unsigned types always have defined behaviour and be reversible.
Converting a signed type to unsigned and back to signed should produce the
same value, and vice-versa, and should not alter its representation. Most
current architectures have this behaviour (I know MMX/SSE instructions
implement saturated arithmetics, but that's a separate issue).

Mandating this behaviour would effectively retire ones-complement and
sign-magnitude representations, together with padding bits and
trap-representations for integers. Not a big loss, a welcome simplification
of the standard, and a more intuitive behaviour for most programmers.

It would also cut the amount of pedantic noob-bashing on this forum.

 

[CBFalconer]

"Eric Sosman" <[email protected]> a écrit:
.... snip ...


That is not dumb luck, it is a well-thought side-effect of 2s
complement representation and wrap-around arithmetics.

No, it is 'dumb luck'. The conversion to int will probably exceed
the value range of an int, and this always causes an implementation
defined action. Good 2's complementation implementaions (which are
rare) will probably cause a system error to occur.