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 in this regard,

Thanks,
Andreas

andreas.luethi@gmx.net wrote:
> 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 in this regard,
>
> Thanks,
> Andreas
>

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

Thanks for your understanding.


--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

andreas.luethi@gmx.net wrote:
> 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 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 you
anyway.


--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

On Oct 17, 1:13 pm, jacob navia <ja...@nospam.org> wrote:
> andreas.lue...@gmx.net wrote:
> > 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 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 you
> anyway.
>
> --
> jacob navia
> jacob at jacob point remcomp point fr
> logiciels/informatiquehttp://www.cs.virginia.edu/~lcc-win32

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';
}

andreas.luethi@gmx.net wrote:
> On Oct 17, 1:13 pm, jacob navia <ja...@nospam.org> wrote:
>> andreas.lue...@gmx.net wrote:
>>> 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 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 you
>> anyway.
>>
>> --
>> jacob navia
>> jacob at jacob point remcomp point fr
>> logiciels/informatiquehttp://www.cs.virginia.edu/~lcc-win32
>
> 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.

--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

andreas.luethi@gmx.net wrote:
>> andreas.lue...@gmx.net wrote:
>> > ... 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.
>
>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?

--
Roberto Waltman

[ Please reply to the group,
return address is invalid ]

Roberto Waltman wrote:
>
> 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


--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

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..

andreas.luethi@gmx.net 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.
>
> 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.


--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>



--
Posted via a free Usenet account from http://www.teranews.com

andreas.luethi@gmx.net wrote:
> jacob navia <ja...@nospam.org> wrote:
>> andreas.lue...@gmx.net 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.
>
.... 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.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>



--
Posted via a free Usenet account from http://www.teranews.com

On 17 Oct 2007, vipvipvipvip.ru@gmail.com wrote:

> 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

--
D.a.v.i.d T.i.k.t.i.n
t.i.k.t.i.n [at] a.d.v.a.n.c.e.d.r.e.l.a.y [dot] c.o.m

On Oct 17, 11:43 am, andreas.lue...@gmx.net wrote:
> 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 in this regard,

What are you looking for 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.

jacob navia wrote:
> Roberto Waltman wrote:
>>
>> 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.

--
Eric Sosman
esosman@ieee-dot-org.invalid

On 2007-10-17, andreas.luethi@gmx.net <andreas.luethi@gmx.net> wrote:
> On Oct 17, 1:13 pm, jacob navia <ja...@nospam.org> wrote:
>> andreas.lue...@gmx.net wrote:
>> > 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.
[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?

andreas.luethi@gmx.net writes:
> On Oct 17, 1:13 pm, jacob navia <ja...@nospam.org> wrote:
>> andreas.lue...@gmx.net 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 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) kst-u@mib.org <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"

On Oct 17, 11:37 pm, Keith Thompson <ks...@mib.org> wrote:
> andreas.lue...@gmx.net writes:
> > On Oct 17, 1:13 pm, jacob navia <ja...@nospam.org> wrote:
> >> andreas.lue...@gmx.net 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 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) ks...@mib.org <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

andreas.luethi@gmx.net wrote:
> On Oct 17, 11:37 pm, Keith Thompson <ks...@mib.org> wrote:
>> andreas.lue...@gmx.net writes:
>>> On Oct 17, 1:13 pm, jacob navia <ja...@nospam.org> wrote:
>>>> andreas.lue...@gmx.net 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.

> 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.

"Eric Sosman" <esosman@ieee-dot-org.invalid> a écrit dans le message de
news: eZCdnRVM0ure54vanZ2dnUVZ_vCknZ2d@comcast.com...
> jacob navia wrote:
>> Roberto Waltman wrote:
>>>
>>> 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.

--
Chqrlie.

Charlie Gordon wrote:
> "Eric Sosman" <esosman@ieee-dot-org.invalid> a écrit:
>
.... snip ...
>
>> 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.

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.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>



--
Posted via a free Usenet account from http://www.teranews.com