Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to verify your details, confirm your email, resolve issues, making threats, or asking for money, are
spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the
password reset link.
Due to spam on this forum, all posts now need moderator approval.
Entire forum
➜ SMAUG
➜ SMAUG coding
➜ Declared variable not "in current context"
Declared variable not "in current context"
|
It is now over 60 days since the last post. This thread is closed.
Refresh page
Pages: 1
2 3
Posted by
| Darwin
USA (125 posts) Bio
|
Date
| Reply #15 on Sun 06 Apr 2008 06:53 AM (UTC) |
Message
| It appears that removing the -O flag did indeed "fix" the problem. I also don't get any <value optimized out> values for any variables. | Top |
|
Posted by
| Darwin
USA (125 posts) Bio
|
Date
| Reply #16 on Sun 06 Apr 2008 08:36 PM (UTC) |
Message
| A side effect of removing the -O flag has caused some code that previously worked to cause a crash (Segmentation fault.) Placing the -O flag back in and the code doesn't crash. This is something related to some Lua stuff I've added so I'm sure there's a way to remove the -O flag and still have it work correctly, just not sure what it is yet. | Top |
|
Posted by
| Nick Gammon
Australia (23,158 posts) Bio
Forum Administrator |
Date
| Reply #17 on Sun 06 Apr 2008 11:00 PM (UTC) |
Message
| It is likely you have used variables which were not initialized - the optimization may have caused the non-initialized value to be something that doesn't crash (eg. zero), whereas the non-initialized value in the un-optimized version may be something else (eg. -38328639764) which would cause a crash.
Make sure you have eliminated all compiler warnings, and check for that sort of thing around the part that crashes. Also use gdb to examine the core dump after the crash. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | Top |
|
Posted by
| David Haley
USA (3,881 posts) Bio
|
Date
| Reply #18 on Mon 07 Apr 2008 12:02 AM (UTC) |
Message
| I think that without optimization, variables on the stack get initialized to zero:
$ cat foo.c
#include <stdio.h>
int main(int argc, char** argv)
{
int i;
printf("%d", i);
return 0;
}
$ gcc foo.c -o foo
$ ./foo
0
$ gcc -O2 foo.c -o foo
$ ./foo
2139865432
$
|
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone
http://david.the-haleys.org | Top |
|
Posted by
| Nick Gammon
Australia (23,158 posts) Bio
Forum Administrator |
Date
| Reply #19 on Mon 07 Apr 2008 12:37 AM (UTC) |
Message
| Stick to saying they are undefined, I think. Under Linux I got this:
$ cat test.c
#include <stdio.h>
int main()
{
int i;
printf("%d", i);
return 0;
}
$ gcc test.c -Wall -o test
$ ./test
1073830176 $
|
- Nick Gammon
www.gammon.com.au, www.mushclient.com | Top |
|
Posted by
| Darwin
USA (125 posts) Bio
|
Date
| Reply #20 on Mon 07 Apr 2008 02:04 AM (UTC) |
Message
| Ok, I fixed most of all the compiler warnings. I have only a few left and am not sure how these are to be fixed.
Quote: comm.c: In function ‘new_descriptor’:
comm.c:894: warning: pointer targets in passing argument 3 of ‘accept’ differ in signedness
ident.c: In function ‘set_auth’:
ident.c:311: warning: pointer targets in passing argument 3 of ‘getsockname’ differ in signedness
ident.c:316: warning: pointer targets in passing argument 3 of ‘getpeername’ differ in signedness
lua_bits.c: In function ‘bit_tonumber’:
lua_bits.c:65: warning: pointer targets in initialization differ in signedness
The offending lines (in bold):
comm.c
size = sizeof(sock);
if ( check_bad_desc( new_desc ) )
{
set_alarm( 0 );
return;
}
set_alarm( 20 );
alarm_section = "new_descriptor::accept";
if ( ( desc = accept( new_desc, (struct sockaddr *) &sock, &size) ) < 0 )
{
perror( "New_descriptor: accept" );
sprintf(bugbuf, "[*****] BUG: New_descriptor: accept");
log_string_plus( bugbuf, LOG_COMM, sysdata.log_level );
set_alarm( 0 );
return;
}
if ( check_bad_desc( new_desc ) )
{
set_alarm( 0 );
return;
}
ident.c
if (getsockname(d->descriptor, (struct sockaddr *)&us, &ulen) < 0)
{
perror("set_auth: getsockname");
ENDRET("Set_auth: getsockname error for %s@%s.", "(getsockname error)");
}
if (getpeername(d->descriptor, (struct sockaddr *)&them, &tlen) < 0)
{
perror("set_auth: getpeername");
ENDRET("Set_auth: getpeername error for %s@%s.", "(getpeername error)");
}
lua_bits.c
static int bit_tonumber (lua_State *L)
{
Integer result = 0;
unsigned int base = luaL_optint(L, 2, 10);
// get text to convert
const unsigned char * text = luaL_checkstring (L, 1);
const unsigned char * p;
unsigned char c;
unsigned int digit;
Integer maxvalue;
int negative = 0;
| Top |
|
Posted by
| David Haley
USA (3,881 posts) Bio
|
Date
| Reply #21 on Mon 07 Apr 2008 05:08 AM (UTC) |
Message
|
Quote: Stick to saying they are undefined, I think. Under Linux I got this:
How odd. I get zero no matter what, and I'm also running Linux. Perhaps it is a compiler version issue: I have gcc 4.1.2.
EDIT: it is true though that one should never depend on anything whatsoever when it comes to unsigned variables. I noticed this initialize-to-zero feature a while ago and didn't like it at the time because it seems like it can introduce subtle bugs that you don't notice until optimizations are turned on. (end edit)
Quote: comm.c:894: warning: pointer targets in passing argument 3 of ‘accept’ differ in signedness
You took the address of an unsigned variable where the function expects a signed variable, or the other way around. Casting to the appropriate type would solve this although you might want to investigate why the signedness is different.
luaL_checkstring, for example, returns a const char*, not a const unsigned char*. Therefore the 'text' variable should not be 'unsigned' -- or, if you really mean 'unsigned' (perhaps it matters later on in the function), you need to cast the result of luaL_checkstring to const unsigned char*. |
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone
http://david.the-haleys.org | Top |
|
Posted by
| Isthiriel
(113 posts) Bio
|
Date
| Reply #22 on Mon 07 Apr 2008 05:42 AM (UTC) |
Message
| Huh.
kc@persephone:~/Desktop$ gcc --version
gcc (GCC) 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
kc@persephone:~/Desktop$ cat test.c
#include <stdio.h>
int main() {
int i;
printf("%d\n", i);
return 0;
}
kc@persephone:~/Desktop$ gcc test.c -Wall -o test
kc@persephone:~/Desktop$ ./test
-1209006080
kc@persephone:~/Desktop$ ./test
-1208350720
kc@persephone:~/Desktop$ ./test
-1209026560
kc@persephone:~/Desktop$ gcc -O2 test.c -Wall -o test
test.c: In function 'main':
test.c:5: warning: 'i' is used uninitialised in this function
kc@persephone:~/Desktop$ ./test
1
kc@persephone:~/Desktop$ ./test
1
kc@persephone:~/Desktop$ ./test
1
kc@persephone:~/Desktop$
Wouldn't it be a compiler/target option somewhere? | Top |
|
Posted by
| Nick Gammon
Australia (23,158 posts) Bio
Forum Administrator |
Date
| Reply #23 on Mon 07 Apr 2008 05:57 AM (UTC) |
Message
|
Quote:
it is true though that one should never depend on anything whatsoever when it comes to unsigned variables
You mean, "undefined variables". |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | Top |
|
Posted by
| Nick Gammon
Australia (23,158 posts) Bio
Forum Administrator |
Date
| Reply #24 on Mon 07 Apr 2008 06:04 AM (UTC) |
Message
|
Quote:
Wouldn't it be a compiler/target option somewhere?
I can't see one, and in any case I don't think the correctness of a C program should depend on the compile-time options.
Basically it is incorrect to assume that uninitialized automatic variables (those on the stack) have anything but undefined values.
As you can see from the various tests, you may well get consistent results from one test to the next, and under certain circumstances, the value may be zero, but you can't assume that.
See: http://c-faq.com/decl/initval.html
I quote (my emphasis):
Quote:
Variables with automatic duration (i.e. local variables without the static storage class) start out containing garbage, unless they are explicitly initialized. (Nothing useful can be predicted about the garbage.)
|
- Nick Gammon
www.gammon.com.au, www.mushclient.com | Top |
|
Posted by
| David Haley
USA (3,881 posts) Bio
|
Date
| Reply #25 on Mon 07 Apr 2008 06:26 AM (UTC) Amended on Mon 07 Apr 2008 06:29 AM (UTC) by Nick Gammon
|
Message
| What's interesting to me is that for as long as I can remember, developing on this and other similar Linux systems, every single time I've looked at uninitialized stack variables in the debugger, they've been zero. And when optimization was turned on, they were garbage.
This behavior shouldn't be depended upon (of course) but it's interesting that it was so consistent for me...
IIRC, the Visual Studio libraries have different initialization behavior for the debug and optimized versions, but I haven't played with those for quite a long time. |
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone
http://david.the-haleys.org | Top |
|
Posted by
| Isthiriel
(113 posts) Bio
|
Date
| Reply #26 on Mon 07 Apr 2008 09:33 AM (UTC) |
Message
|
Quote: I can't see one, and in any case I don't think the correctness of a C program should depend on the compile-time options.
It's not so much the correctness of the program as the dialect of C you are forcing the compiler to expect, which can be altered by compile time options (and pragmas &c..). For.ex. there are target options to control whether a 'long long' is 32 or 64 bits wide.
Quote: What's interesting to me is that for as long as I can remember, developing on this and other similar Linux systems, every single time I've looked at uninitialized stack variables in the debugger, they've been zero. And when optimization was turned on, they were garbage.
Debuggers are famous for 'fixing' problems that occur outside of the debugger by doing things like zeroing variables. | Top |
|
Posted by
| Darwin
USA (125 posts) Bio
|
Date
| Reply #27 on Tue 08 Apr 2008 12:25 AM (UTC) |
Message
|
Quote: You took the address of an unsigned variable where the function expects a signed variable, or the other way around. Casting to the appropriate type would solve this although you might want to investigate why the signedness is different. Well, actually, I didn't do any of those. They're all parts of stock code.
Quote: luaL_checkstring, for example, returns a const char*, not a const unsigned char*. Therefore the 'text' variable should not be 'unsigned' -- or, if you really mean 'unsigned' (perhaps it matters later on in the function), you need to cast the result of luaL_checkstring to const unsigned char*.
Changing the 'text' variable to const char * instead of const unsigned char * yields an error when compiling. That part is from Nick's Lua code
lua_bits.c: In function ‘bit_tonumber’:
lua_bits.c:79: warning: pointer targets in assignment differ in signedness
lua_bits.c:108: error: invalid operands to binary -
Line 108 is bolded.
static int bit_tonumber (lua_State *L)
{
Integer result = 0;
unsigned int base = luaL_optint(L, 2, 10);
// get text to convert
const char * text = luaL_checkstring (L, 1);
const unsigned char * p;
unsigned char c;
unsigned int digit;
Integer maxvalue;
int negative = 0;
if (base != 10)
luaL_argcheck(L, 2 <= base && base <= 36, 2, "base out of range");
// maximum value before multiply by the base
maxvalue = 4503599627370496 / base; // 2^52
// skip whitespace
for (p = text; isspace (*p); p++)
; // skip leading spaces
// look for sign
if (*p == '-')
{
negative = 1;
p++;
}
else if (*p == '+')
p++;
while ((c = *p++))
{
// The largest mantissa a double can have it 52 bits
if (result >= maxvalue)
luaL_error (L, "Number too big");
if (isdigit (c))
digit = c - '0';
else if (isalpha (c))
digit = toupper (c) - 'A' + 10;
else
digit = 999; // bad digit - force error in next line
if (digit >= base)
luaL_error (L, "Bad digit ('%c') at position %i",
c, (int) (p - text));
result = result * base + digit;
} // end while
if (negative)
result = -result;
lua_pushnumber (L, result);
return 1; // number of result fields
} // end of bit_tonumber
| Top |
|
Posted by
| David Haley
USA (3,881 posts) Bio
|
Date
| Reply #28 on Tue 08 Apr 2008 01:01 AM (UTC) |
Message
|
Quote: Well, actually, I didn't do any of those. They're all parts of stock code.
Well, by "you" I meant the code, not you personally. :-)
It's quite possible that this compiled fine for Nick when he wrote it but gives you warnings due to different compiler versions etc.
Quote: lua_bits.c:108: error: invalid operands to binary -
Well, since 'text' is now signed, you want 'p' to also be signed. I bet that is what the warning on line 79 is from:
for (p = text; isspace (*p); p++) |
David Haley aka Ksilyan
Head Programmer,
Legends of the Darkstone
http://david.the-haleys.org | Top |
|
Posted by
| Nick Gammon
Australia (23,158 posts) Bio
Forum Administrator |
Date
| Reply #29 on Tue 08 Apr 2008 06:29 AM (UTC) |
Message
| Did you search the forum for this error, about "differ in signedness"?
See this page:
http://www.gammon.com.au/forum/bbshowpost.php?id=8000&page=2
My response at the time was:
Anyway, the bits file is not really required yet - I didn't use it for the initial stuff, and so far have only used it in one place to "and" a room flag.
I would remove it from the makefile for now, and remove the reference to it in the lua_scripting.c file.
In other words, this function isn't required. I just copied it over from MUSHclient, and due to compiler differences you are getting the error.
Also see this post:
http://www.gammon.com.au/forum/bbshowpost.php?id=8343
I also suggested there simply removing the bit_tonumber function as it isn't required, and we are wasting time fixing something that isn't actually used. |
- Nick Gammon
www.gammon.com.au, www.mushclient.com | Top |
|
The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).
To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.
93,338 views.
This is page 2, subject is 3 pages long:
1
2 3
It is now over 60 days since the last post. This thread is closed.
Refresh page
top