1. Very strange problem - Eu bug?? (Eu 2.5)
- Posted by Pete Stoner <stoner.pete at gmail.com> Feb 26, 2006
- 711 views
I have an include file doing a dll call, the first call is done to get the buffer size required. Using the translator I was intermittantly getting '87' returned which is ERROR_INVALID_PARAMETER instead of the expected '111' (ERROR_BUFFER_OVERFLOW). The first odd thing was that it would fail when called from my main prog but would work if I used the include file on its own with the call tagged on the end.. Anyway to cut a long story of fiddling around short, I've cut things down as much as I can for now and I can recreate the failure, which I can 'fix' by a slight change in any of the include files i.e. removing a single character from a (now unused) variable name or even just removing one blank line!! Its very reliable - run cutdown program and get '87' returned, delete blank line from file and get the expected '111' returned!! If I bind the version that fails it then runs ok - probably because of the binder deleting unused routines etc. I'm lost here, if someone else would like to try this to see if they get the same results please let me know... As it seems so specific to number of lines/characters I will have to send you a zip of the include files used (only win32lib, my dll include file and whats left of my main prog). PeteS
2. Re: Very strange problem - Eu bug?? (Eu 2.5)
- Posted by Vincent <darkvincentdude at yahoo.com> Feb 26, 2006
- 661 views
Pete Stoner wrote: > > I have an include file doing a dll call, the first call is done to get the > buffer > size required. Using the translator I was intermittantly getting '87' returned > which is ERROR_INVALID_PARAMETER instead of the expected '111' > (ERROR_BUFFER_OVERFLOW). > The first odd thing was that it would fail when called from my main prog but > would work if I used the include file on its own with the call tagged on the > end.. > > Anyway to cut a long story of fiddling around short, I've cut things down as > much as I can for now and I can recreate the failure, which I can 'fix' by a > slight change in any of the include files i.e. removing a single character > from > a (now unused) variable name or even just removing one blank line!! > > Its very reliable - run cutdown program and get '87' returned, delete blank > line from file and get the expected '111' returned!! If I bind the version > that > fails it then runs ok - probably because of the binder deleting unused > routines > etc. > > I'm lost here, if someone else would like to try this to see if they get the > same results please let me know... As it seems so specific to number of > lines/characters > I will have to send you a zip of the include files used (only win32lib, my dll > include file and whats left of my main prog). > > PeteS Pete, Are you using Eu 2.5 or 2.5t3? If your using 2.5t3, does it fail with 2.5? Regards, Vincent
3. Re: Very strange problem - Eu bug?? (Eu 2.5)
- Posted by Pete Stoner <stoner.pete at gmail.com> Feb 26, 2006
- 651 views
Vincent wrote: > > Pete Stoner wrote: > > > > I have an include file doing a dll call, the first call is done to get the > > buffer > > size required. Using the translator I was intermittantly getting '87' > > returned > > which is ERROR_INVALID_PARAMETER instead of the expected '111' > > (ERROR_BUFFER_OVERFLOW). > > The first odd thing was that it would fail when called from my main prog but > > would work if I used the include file on its own with the call tagged on the > > end.. > > > > Anyway to cut a long story of fiddling around short, I've cut things down as > > much as I can for now and I can recreate the failure, which I can 'fix' by a > > slight change in any of the include files i.e. removing a single character > > from > > a (now unused) variable name or even just removing one blank line!! > > > > Its very reliable - run cutdown program and get '87' returned, delete blank > > line from file and get the expected '111' returned!! If I bind the version > > that > > fails it then runs ok - probably because of the binder deleting unused > > routines > > etc. > > > > I'm lost here, if someone else would like to try this to see if they get the > > same results please let me know... As it seems so specific to number of > > lines/characters > > I will have to send you a zip of the include files used (only win32lib, my > > dll > > include file and whats left of my main prog). > > > > PeteS > > Pete, > > Are you using Eu 2.5 or 2.5t3? If your using 2.5t3, does it fail with 2.5? > > > Regards, > Vincent Hi Vincent, I'm using 2.5 PeteS
4. Re: Very strange problem - Eu bug?? (Eu 2.5)
- Posted by Pete Stoner <stoner.pete at gmail.com> Feb 26, 2006
- 829 views
Pete Stoner wrote: > > I have an include file doing a dll call, the first call is done to get the > buffer > size required. Using the translator I was intermittantly getting '87' returned > which is ERROR_INVALID_PARAMETER instead of the expected '111' > (ERROR_BUFFER_OVERFLOW). > The first odd thing was that it would fail when called from my main prog but > would work if I used the include file on its own with the call tagged on the > end.. > > Anyway to cut a long story of fiddling around short, I've cut things down as > much as I can for now and I can recreate the failure, which I can 'fix' by a > slight change in any of the include files i.e. removing a single character > from > a (now unused) variable name or even just removing one blank line!! > > Its very reliable - run cutdown program and get '87' returned, delete blank > line from file and get the expected '111' returned!! If I bind the version > that > fails it then runs ok - probably because of the binder deleting unused > routines > etc. > > PeteS OK after a lot of trial and error, using registered 2.5 and Win32lib 60.6 and using this chopped down include file. file name - XGetAdaptersAddresses.ew
without warning include w32support.e -- from Win32Lib v0.60.6 global constant ADAPTER_TYPE =1, ADAPTER_NAME =2, ADAPTER_FRIENDLYNAME =3, ADAPTER_DESCRIPTION =4, ADAPTER_MAC_ADDRESS =5, ADAPTER_STATUS =6, DHCP_ENABLED =7, DYNAMIC_DNS =8 constant iphlpapi = open_dll( "iphlpapi.dll" ) constant xGetAdaptersAddresses = define_c_func( iphlpapi, "GetAdaptersAddresses", {C_ULONG, C_ULONG, C_POINTER, C_POINTER, C_ULONG}, C_INT) constant AF_INET = 2 constant AF_INET6 = 23 constant AF_UNSPEC = 0 -- flags returned constant IP_ADAPTER_DDNS_ENABLED = #0001, IP_ADAPTER_REGISTER_ADAPTER_SUFFIX = #0002, IP_ADAPTER_DHCP_ENABLED = #0004, IP_ADAPTER_RECEIVE_ONLY = #0008, IP_ADAPTER_NO_MULTICAST = #0010, IP_ADAPTER_IPV6_OTHER_STATEFUL_CONFIG = #0020 constant -- possible return values ERROR_SUCCESS = 0, ERROR_BUFFER_OVERFLOW = 111, ERROR_INVALID_PARAMETER = 87, ERROR_NO_DATA = 232, ERROR_NOT_SUPPORTED = 50 -- adapter type constants global constant IF_TYPE_OTHER = 1, IF_TYPE_ETHERNET = 6, IF_TYPE_TOKENRING = 9, IF_TYPE_FDDI = 15, IF_TYPE_PPP = 23, IF_TYPE_LOOPBACK = 24, IF_TYPE_SLIP = 28 global function GetAdaptersAddresses() atom struct, pOutBufLen, dwStatus, ptr, mac_len, flags, adapterInfo integer IF_type, operStatusret, dhcp, dDNS sequence AdapterName, FriendlyName, Description, macAddr, interface_type, operStatus atom num object data data = {} struct = allocate(4) pOutBufLen = allocate(4) poke4( pOutBufLen, 4 ) -- poke the wrong size for first call dwStatus = c_func( xGetAdaptersAddresses, {0, 0, NULL, struct, pOutBufLen} ) if dwStatus != ERROR_BUFFER_OVERFLOW then data = dwStatus else data = {} end if free(struct) free(pOutBufLen) return data end function object res
and calling it from file name - getAdaptersAddresse.exw
without warning without trace include Win32lib.ew include XGetAdaptersAddresses.ew ? GetAdaptersAddresses() ? GetAdaptersAddresses() ? GetAdaptersAddresses() ? 1/0
NOTE:- the file names are important.... I get the 87 (the error) on the first call and a sequence (good return) on the second 2 calls. if I rename the calling file to 'getAdaptersAddresses.exw' (one extra character) I get good returns from all 3 calls.. If I then delete the 'object res' at the end of the include file, the first call fails whatever the file name. The results of this changes as I delete more of the unused lines... The xGetAdaptersAddresses() is Windows XP only, earlier versions should return '50' instead of '111', but it would be interesting to confirm you don't get the '87' error.. I also tried the above with registered 2.4.. I could get a similar effect but with different number of lines/characters deleted. The above combinations that fail on 2.5 work on 2.4... Am I going crazy? PeteS
5. Re: Very strange problem - Eu bug?? (Eu 2.5)
- Posted by Vincent <darkvincentdude at yahoo.com> Feb 26, 2006
- 682 views
Pete Stoner wrote: > Hi Vincent, I'm using 2.5 > > PeteS Hi, Well that rules out any problem with the include system enhancement. This is like process of elimination here. Hmm... this issue sounds very strange. Perhaps Robert can tinker with your example and see what could be causing this. Regards, Vincent
6. Re: Very strange problem - Eu bug?? (Eu 2.5)
- Posted by Bernie Ryan <xotron at bluefrog.com> Feb 26, 2006
- 668 views
Pete: Let us see the formal "C" discripton of GetAdaptersAddresses() function. Bernie My files in archive: WMOTOR, XMOTOR, W32ENGIN, MIXEDLIB, EU_ENGIN, WIN32ERU, WIN32API Can be downloaded here: http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan
7. Re: Very strange problem - Eu bug?? (Eu 2.5)
- Posted by Pete Stoner <stoner.pete at gmail.com> Feb 26, 2006
- 689 views
Bernie Ryan wrote: > > > Pete: > > Let us see the formal "C" discripton of GetAdaptersAddresses() > function. > > Bernie > Hi Bernie, you can find the full details here.. http://windowssdk.msdn.microsoft.com/library/default.asp?url=/library/en-us/iphlp/iphlp/getadaptersaddresses.asp
8. Re: Very strange problem - Eu bug?? (Eu 2.5)
- Posted by Bernie Ryan <xotron at bluefrog.com> Feb 26, 2006
- 675 views
Pete Stoner wrote: > > Bernie Ryan wrote: > > > > > > Pete: > > > > Let us see the formal "C" discripton of GetAdaptersAddresses() > > function. > > > > Bernie > > > Hi Bernie, you can find the full details here.. > <a > href="http://windowssdk.msdn.microsoft.com/library/default.asp?url=/library/en-us/iphlp/iphlp/getadaptersaddresses.asp">http://windowssdk.msdn.microsoft.com/library/default.asp?url=/library/en-us/iphlp/iphlp/getadaptersaddresses.asp</a> Pete: First the structure has to have 64 bit alignment as shown below. This maybe why changing the program size may be Euphoria moving the structure memory alignment around. typedef struct _IP_ADAPTER_ADDRESSES { union { ULONGLONG Alignment; struct { ULONG Length; DWORD IfIndex; }; }; Also did you see this note in the example to be sure your buffer length is correct. // Make an initial call to GetAdaptersAddresses to get the // size needed into the outBufLen variable Bernie My files in archive: WMOTOR, XMOTOR, W32ENGIN, MIXEDLIB, EU_ENGIN, WIN32ERU, WIN32API Can be downloaded here: http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan // Make an initial call to GetAdaptersAddresses to get the // size needed into the outBufLen variable
9. Re: Very strange problem - Eu bug?? (Eu 2.5)
- Posted by Pete Stoner <stoner.pete at gmail.com> Feb 26, 2006
- 722 views
- Last edited Feb 27, 2006
Bernie Ryan wrote: > > Pete Stoner wrote: > > > > Bernie Ryan wrote: > > > > > > > > > Pete: > > > > > > Let us see the formal "C" discripton of GetAdaptersAddresses() > > > function. > > > > > > Bernie > > > > > Hi Bernie, you can find the full details here.. > > <a > > href="http://windowssdk.msdn.microsoft.com/library/default.asp?url=/library/en-us/iphlp/iphlp/getadaptersaddresses.asp">http://windowssdk.msdn.microsoft.com/library/default.asp?url=/library/en-us/iphlp/iphlp/getadaptersaddresses.asp</a> > > Pete: > > First the structure has to have 64 bit alignment as shown below. > This maybe why changing the program size may be Euphoria moving the > structure memory alignment around. > > typedef struct _IP_ADAPTER_ADDRESSES { > union { > ULONGLONG Alignment; > struct { > ULONG Length; > DWORD IfIndex; > }; > }; > > Also did you see this note in the example to be sure your buffer length > is correct. > > // Make an initial call to GetAdaptersAddresses to get the > // size needed into the outBufLen variable > > Bernie > > My files in archive: > WMOTOR, XMOTOR, W32ENGIN, MIXEDLIB, EU_ENGIN, WIN32ERU, WIN32API > > Can be downloaded here: > <a > href="http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan">http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan</a> > // Make an initial call to GetAdaptersAddresses to get the > // size needed into the outBufLen variable Bernie, I did say I had cut down the program to a minimum, if you have another look at my example you will see I'm not even building the structure as the only call I'm doing is the first one to get the buffer size, (I don't need a structure at that point, so I deleted it) and that's why I'm expecting a '111' (or ERROR_BUFFER_OVERFLOW), however my problem is I get the '87' (ERROR_INVALID_PARAMETER) returned. What I fail to understand is why should changing the name of my program make it work?? PeteS
10. Re: Very strange problem - Eu bug?? (Eu 2.5)
- Posted by jacques deschênes <desja at globetrotter.net> Feb 27, 2006
- 705 views
Hi Pete, I ran the following code on my machine without any problem, wathever the name I give to the file (using exwc.exe). NOTE: it doesn't use win32lib
without warning --include w32support.e -- from Win32Lib v0.60.6 include dll.e include machine.e global constant ADAPTER_TYPE=1, ADAPTER_NAME=2, ADAPTER_FRIENDLYNAME=3, ADAPTER_DESCRIPTION=4, ADAPTER_MAC_ADDRESS=5, ADAPTER_STATUS=6, DHCP_ENABLED=7, DYNAMIC_DNS=8 constant iphlpapi = open_dll( "iphlpapi.dll" ) constant xGetAdaptersAddresses = define_c_func( iphlpapi, "GetAdaptersAddresses", {C_ULONG, C_ULONG, C_POINTER, C_POINTER, C_ULONG},C_INT) constant AF_INET= 2 constant AF_INET6= 23 constant AF_UNSPEC= 0 -- flags returned constant IP_ADAPTER_DDNS_ENABLED = #0001, IP_ADAPTER_REGISTER_ADAPTER_SUFFIX = #0002, IP_ADAPTER_DHCP_ENABLED = #0004, IP_ADAPTER_RECEIVE_ONLY = #0008, IP_ADAPTER_NO_MULTICAST = #0010, IP_ADAPTER_IPV6_OTHER_STATEFUL_CONFIG = #0020 constant -- possible return values ERROR_SUCCESS = 0, ERROR_BUFFER_OVERFLOW = 111, ERROR_INVALID_PARAMETER = 87, ERROR_NO_DATA = 232, ERROR_NOT_SUPPORTED = 50 -- adapter type constants global constant IF_TYPE_OTHER = 1, IF_TYPE_ETHERNET = 6, IF_TYPE_TOKENRING = 9, IF_TYPE_FDDI = 15, IF_TYPE_PPP = 23, IF_TYPE_LOOPBACK = 24, IF_TYPE_SLIP = 28 function GetAdapterFriendlyName(atom pName) sequence name integer i,wc name = "" wc = peek(pName) + peek(pName+1)*256 i = 0 while wc do name &= wc i += 2 wc = peek(pName+i) + peek(pName+i+1)*256 end while return name end function function GetAdapterDescription(atom pDescription) sequence description integer i,wc description = {} i = 0 wc = peek(pDescription)+peek(pDescription+1)*256 -- wide char while wc do description &= wc i+= 2 wc = peek(pDescription+i)+peek(pDescription+i+1)*256 end while return description end function global function GetAdaptersAddresses() atom struct, pOutBufLen, dwStatus, ptr, mac_len, flags, adapterInfo integer IF_type, operStatusret, dhcp, dDNS sequence AdapterName, FriendlyName, Description, macAddr, interface_type,operStatus atom num,pAdapterName, pDescription, pNext object data data = {} struct = allocate(78) pOutBufLen = allocate(4) poke4( pOutBufLen,4 ) -- poke the wrong size for first call dwStatus = c_func( xGetAdaptersAddresses, {0, 0, NULL, struct, pOutBufLen} ) if dwStatus != ERROR_BUFFER_OVERFLOW then data = dwStatus else free(struct) struct = allocate(peek4u(pOutBufLen)) mem_set(struct,0,peek4u(pOutBufLen)) dwStatus = c_func(xGetAdaptersAddresses,{0,0,NULL,struct,pOutBufLen}) if dwStatus = ERROR_SUCCESS then pNext = struct data = {} while pNext do data &= {{GetAdapterFriendlyName(peek4u(pNext+40)),GetAdapterDescription(peek4u(pNext+36))}} pNext = peek4u(pNext+8) end while else data = dwStatus end if end if free(struct) free(pOutBufLen) return data end function object data data = GetAdaptersAddresses() if sequence(data) then for i = 1 to length(data) do printf(1,"name: %s, description: %s\n",data[i]) end for end if
regards, jacques Deschênes
11. Re: Very strange problem - Eu bug?? (Eu 2.5)
- Posted by Pete Stoner <stoner.pete at gmail.com> Feb 27, 2006
- 669 views
jacques deschênes wrote: > > > Hi Pete, > I ran the following code on my machine without any problem, wathever the >name > I give to the file (using exwc.exe). > NOTE: it doesn't use win32lib > > snipped > > regards, > jacques Deschênes Thanks Jacques, I have to say I also never seemed to have any failures when I run my own full include file 'stand alone' i.e. with the calls tagged on the end, I only seemed to get tha failure when calling it from my main program. I am using win32lib for the stucture handling stuff. I tried running your version a few different ways but cannot at the moment get it to fail, however as I could get odd effects on my failing version I'm not confident I won't see the same problem again at some stage (like I could get it to work by removing one character, then fail again by adding the character back *and* it would continue to fail as I added characters until the 17th character was added when it would work again - is this a clue?). My failures are always on the first call to get the buffer size and I don't see much difference between your version and mine (except the number of characters!?) in the code needed for that first call. Also now Vincent has recreated the same symptoms at least I feel it's not just me going mad! PeteS
12. Re: Very strange problem - Eu bug?? (Eu 2.5)
- Posted by Pete Stoner <stoner.pete at gmail.com> Feb 28, 2006
- 673 views
jacques deschênes wrote: > > > Hi Pete, > I ran the following code on my machine without any problem, wathever the name > > I give to the file (using exwc.exe). > NOTE: it doesn't use win32lib > > snipped > > regards, > jacques Deschênes Jacques, I've done some more testing and still couldn't get your version to fail, so I extended it to return all the fields I had in my win32lib version and a few other minor changes as below...
without warning include dll.e include machine.e global constant ADAPTER_TYPE=1, ADAPTER_NAME=2, ADAPTER_FRIENDLYNAME=3, ADAPTER_DESCRIPTION=4, ADAPTER_MAC_ADDRESS=5, ADAPTER_STATUS=6, DHCP_ENABLED=7, DYNAMIC_DNS=8, DNS_SUFFIX=9 constant iphlpapi = open_dll( "iphlpapi.dll" ) constant xGetAdaptersAddresses = define_c_func( iphlpapi, "GetAdaptersAddresses", {C_ULONG, -- Family, see constants below C_ULONG, -- Flags ([in] Type of addresses to retrieve, see constants below C_POINTER, -- Reserved [in] The calling application should pass NULL for this parameter. C_POINTER, -- [out] Pointer to a buffer. On successful return, this buffer contains the address information. C_ULONG}, -- pOutBufLen [in, out] Pointer to a variable that specifies the size of the buffer pointed to by pAdapterAddresses. C_INT) -- return code -- FAMILY constant AF_INET= 2 constant AF_INET6= 23 constant AF_UNSPEC= 0 -- flags returned constant IP_ADAPTER_DDNS_ENABLED = #0001, IP_ADAPTER_REGISTER_ADAPTER_SUFFIX = #0002, IP_ADAPTER_DHCP_ENABLED = #0004, IP_ADAPTER_RECEIVE_ONLY = #0008, IP_ADAPTER_NO_MULTICAST = #0010, IP_ADAPTER_IPV6_OTHER_STATEFUL_CONFIG = #0020 constant -- possible return values ERROR_SUCCESS = 0, ERROR_BUFFER_OVERFLOW = 111, ERROR_INVALID_PARAMETER = 87, ERROR_NO_DATA = 232, ERROR_NOT_SUPPORTED = 50 -- adapter type constants global constant IF_TYPE_OTHER = 1, IF_TYPE_ETHERNET = 6, IF_TYPE_TOKENRING = 9, IF_TYPE_FDDI = 15, IF_TYPE_PPP = 23, IF_TYPE_LOOPBACK = 24, IF_TYPE_SLIP = 28 -- Operational status of the interface constant IfoperStatusDesc = { "The interface is up and operational.", -- IfOperStatusUp = 1 "The interface is not operational.", -- IfOperStatusDown = 2 "The interface is being tested.", -- IfOperStatusTesting = 3 "The interface status is unknown.", -- IfOperStatusUnknown = 4 "The interface is dormant.", -- IfOperStatusDormant = 5 "The interface is not present.", -- IfOperStatusNotPresent = 6 "The interface is operational, but a networking layer " & "below the interface is not operational." --IfOperStatusLowerLayerDown = 7 } function GetAdapterName(atom pName) sequence name integer i,wc name = "" wc = peek(pName) i = 0 while wc do name &= wc i += 1 wc = peek(pName+i) end while return name end function function GetUnicodeData(atom ptr) sequence name integer i,wc name = "" wc = peek(ptr) + peek(ptr+1)*256 i = 0 while wc do name &= wc i += 2 wc = peek(ptr+i) + peek(ptr+i+1)*256 end while return name end function global function GetAdaptersAddresses() atom struct, pOutBufLen, dwStatus, flags, num, pNext integer dhcp, dDNS, interface_type sequence FriendlyName, Description, macAddr, DnsSuffix, operStatus object data data = {} struct = allocate(78) pOutBufLen = allocate(4) poke4( pOutBufLen,4 ) -- poke the wrong size for first call dwStatus = c_func( xGetAdaptersAddresses, {AF_INET, 0, NULL, struct, pOutBufLen} ) if dwStatus != ERROR_BUFFER_OVERFLOW then data = dwStatus else free(struct) struct = allocate(peek4u(pOutBufLen)) mem_set(struct,0,peek4u(pOutBufLen)) dwStatus = c_func(xGetAdaptersAddresses,{AF_INET, 0, NULL, struct, pOutBufLen}) if dwStatus = ERROR_SUCCESS then pNext = struct data = {} while pNext do FriendlyName = GetUnicodeData(peek4u(pNext+40)) Description = GetUnicodeData(peek4u(pNext+36)) DnsSuffix = GetUnicodeData(peek4u(pNext+32)) interface_type = peek4u(pNext+64) macAddr = peek({pNext+44, peek4u(pNext+52)}) operStatus = IfoperStatusDesc[peek4u(pNext+68)] flags = peek4u(pNext+56) if and_bits(IP_ADAPTER_DHCP_ENABLED, flags) then dhcp = 1 else dhcp = 0 end if if and_bits(IP_ADAPTER_DDNS_ENABLED, flags) then dDNS = 1 else dDNS = 0 end if data &= {{interface_type, GetAdapterName(peek4u(pNext+12)), FriendlyName, Description, macAddr, operStatus, dhcp, dDNS, DnsSuffix}} pNext = peek4u(pNext+8) end while else data = dwStatus end if end if free(struct) free(pOutBufLen) return data end function object data data = GetAdaptersAddresses() if sequence(data) then for i = 1 to length(data) do if data[i][ADAPTER_TYPE] != IF_TYPE_LOOPBACK then printf(1,"Type: %d,\n", data[i][ADAPTER_TYPE]) printf(1," Name: %s,\n", {data[i][ADAPTER_NAME]}) printf(1," Friendly name: %s,\n",{data[i][ADAPTER_FRIENDLYNAME]}) printf(1," description: %s,\n", {data[i][ADAPTER_DESCRIPTION]}) printf(1," Mac Addr: %02x-%02x-%02x-%02x-%02x-%02x,\n", data[i][ADAPTER_MAC_ADDRESS]) printf(1," Oper Status: %s,\n", {data[i][ADAPTER_STATUS]}) printf(1," DHCP Enabled: %d,\n", data[i][DHCP_ENABLED]) printf(1," DNS Enabled: %d,\n", data[i][DYNAMIC_DNS]) printf(1," DNS Suffix: %s,\n", {data[i][DNS_SUFFIX]}) end if end for end if
I would still like to know why the addition of one blank line can cause or fix my original failure, but I think Rob is the only man to answer that one. At least your code has shown me how to access a structure without Win32lib, and I wanted to be able to remove any win32lib dependencies on this anyway. Thanks! PeteS ps. I will let you know if I see any more failures using this version!
13. Re: Very strange problem - Eu bug?? (Eu 2.5)
- Posted by Robert Craig <rds at RapidEuphoria.com> Feb 28, 2006
- 684 views
Pete Stoner wrote: > I would still like to know why the addition of one blank line can cause or > fix my original failure, but I think Rob is the only man to answer that one. This rarely means there's a bug in the interpreter. It usually means that you are doing something that isn't "kosher". If you change a program in any way, the memory addresses of variables and other blocks of memory, as well as the contents of memory can change. In some cases you can instantly find your problem by copying euphoria\include\safe.e into the same directory as your main program file, and then renaming safe.e as machine.e in that directory. Now when you run your program, a whole bunch of extra memory checks will occur, and you might get an error message on the screen telling you, for example, that you are poking into some memory that doesn't belong to you. Regards, Rob Craig Rapid Deployment Software http://www.RapidEuphoria.com
14. Re: Very strange problem - Eu bug?? (Eu 2.5)
- Posted by Vincent <darkvincentdude at yahoo.com> Mar 01, 2006
- 678 views
Robert Craig wrote: > This rarely means there's a bug in the interpreter. It usually means > that you are doing something that isn't "kosher". > > If you change a program in any way, the memory addresses of variables > and other blocks of memory, as well as the contents of memory can change. > > In some cases you can instantly find your problem by copying > euphoria\include\safe.e into the same directory as your main > program file, and then renaming safe.e as machine.e in that directory. > Now when you run your program, a whole bunch of extra memory checks > will occur, and you might get an error message on the screen telling > you, for example, that you are poking into some memory that > doesn't belong to you. > > Regards, > Rob Craig > Rapid Deployment Software > <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a> Rob, Are you sure that is whats wrong? I don't know... I find it very awkward that simply adding or removing white space can adversely affect program operation. Regards, Vincent
15. Re: Very strange problem - Eu bug?? (Eu 2.5)
- Posted by Jason Gade <jaygade at yahoo.com> Mar 01, 2006
- 685 views
Vincent wrote: > > Robert Craig wrote: > > > This rarely means there's a bug in the interpreter. It usually means > > that you are doing something that isn't "kosher". > > > > If you change a program in any way, the memory addresses of variables > > and other blocks of memory, as well as the contents of memory can change. > > > > In some cases you can instantly find your problem by copying > > euphoria\include\safe.e into the same directory as your main > > program file, and then renaming safe.e as machine.e in that directory. > > Now when you run your program, a whole bunch of extra memory checks > > will occur, and you might get an error message on the screen telling > > you, for example, that you are poking into some memory that > > doesn't belong to you. > > > > Regards, > > Rob Craig > > Rapid Deployment Software > > <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a> > > Rob, > > Are you sure that is whats wrong? > > I don't know... I find it very awkward that simply adding or removing white > space can adversely affect program operation. > > > Regards, > Vincent It sounds to me like it is a memory error with Win32lib. See this post http://www.listfilter.com/EUforum/m6602.html and this post http://www.listfilter.com/EUforum/m6612.html It seems like Win32lib is the real variable here. Pete and Jacques seem to be able to avoid the error by not using Win32lib. Rob's suggestion of using safe.e might be able to catch the error. -- "Any programming problem can be solved by adding a level of indirection." --anonymous "Any performance problem can be solved by removing a level of indirection." --M. Haertel "Premature optimization is the root of all evil in programming." --C.A.R. Hoare j.
16. Re: Very strange problem - Eu bug?? (Eu 2.5)
- Posted by Robert Craig <rds at RapidEuphoria.com> Mar 01, 2006
- 692 views
Vincent wrote: > Are you sure that is whats wrong? > > I don't know... I find it very awkward that simply adding or removing white > space can adversely affect program operation. People are always amazed when this type of thing occurs, but believe me, it's not that uncommon. It has happened to me, and it has happened to many other people on EUforum over the years. If your program is making decisions based on random garbage in memory, it can sometimes work with certain garbage, and crash or malfunction with other garbage. Regards, Rob Craig Rapid Deployment Software http://www.RapidEuphoria.com
17. Re: Very strange problem - Eu bug?? (Eu 2.5)
- Posted by Derek Parnell <ddparnell at bigpond.com> Mar 01, 2006
- 657 views
Jason Gade wrote: > It sounds to me like it is a memory error with Win32lib. See this post <a > href="http://www.listfilter.com/EUforum/m6602.html">http://www.listfilter.com/EUforum/m6602.html</a> > and this post <a > href="http://www.listfilter.com/EUforum/m6612.html">http://www.listfilter.com/EUforum/m6612.html</a> > It seems like Win32lib is the real variable here. > > Pete and Jacques seem to be able to avoid the error by not using Win32lib. > Rob's > suggestion of using safe.e might be able to catch the error. You can use 'safe' memory access in Win32lib by adding these two lines to your program ... include w32support.e w32UsingSafeCode = 1 Try this and see if it makes a difference. -- Derek Parnell Melbourne, Australia Skype name: derek.j.parnell
18. Re: Very strange problem - Eu bug?? (Eu 2.5)
- Posted by Vincent <darkvincentdude at yahoo.com> Mar 01, 2006
- 665 views
Robert Craig wrote: > People are always amazed when this type of thing occurs, > but believe me, it's not that uncommon. It has happened to me, > and it has happened to many other people on EUforum over the > years. If your program is making decisions based on random > garbage in memory, it can sometimes work with certain garbage, > and crash or malfunction with other garbage. This hasn't happened to me, at least not yet anyway, but I suppose that could make a little sense. Perhaps it's just a bug in Win32Lib like Jason suggests. Regards, Vincent
19. Re: Very strange problem - Eu bug?? (Eu 2.5)
- Posted by Kat <darkvincentdude at yahoo.com> Mar 01, 2006
- 675 views
- Last edited Mar 02, 2006
Robert Craig wrote: > People are always amazed when this type of thing occurs, > but believe me, it's not that uncommon. It has happened to me, > and it has happened to many other people on EUforum over the > years. If your program is making decisions based on random > garbage in memory, it can sometimes work with certain garbage, > and crash or malfunction with other garbage. So the interpreter sees whitespace IN THE SOURCE CODE as something it should translate to .il code as pointers to various undefined garbage?!? And then attempt to run it? What part of the Eu syntax is defined as "...and this lack of keyword controls how whitespace is processed..."? It's not only whitespace, it's done it to me before with a "--" added to a program to comment out a trace(1) line. Kat, one of those who complained about this sort of bug before.
20. Re: Very strange problem - Eu bug?? (Eu 2.5)
- Posted by Al Getz <Xaxo at aol.com> Mar 01, 2006
- 699 views
- Last edited Mar 02, 2006
Kat wrote: > > Robert Craig wrote: > > > People are always amazed when this type of thing occurs, > > but believe me, it's not that uncommon. It has happened to me, > > and it has happened to many other people on EUforum over the > > years. If your program is making decisions based on random > > garbage in memory, it can sometimes work with certain garbage, > > and crash or malfunction with other garbage. > > So the interpreter sees whitespace IN THE SOURCE CODE as something it should > translate to .il code as pointers to various undefined garbage?!? And then > attempt > to run it? What part of the Eu syntax is defined as "...and this > lack of keyword controls how whitespace is processed..."? It's not only > whitespace, it's done it to me before with a "--" added to a program to > comment out a trace(1) line. > > > Kat, > one of those who complained about this sort of bug before. Hi Kat, Nice to see you posting to the list again. I've had this problem with v2.4 and earlier, but ALWAYS traced it back to some memory location that was being poked that wasnt supposed to be changed. I figured it was poking in where the interp resides, and that's why i'd get a *totally* different error complaint from Eu each time i changed one iddie biddie thing in the source file, even if it had *absolutely* nothing to do with the program such as whitespace, comments (add a few extra "--" in a line that was already commented), strings inclosed in quotes ("hello" to "hello1"), etc. Once the mem problem was found and corrected the error always cleared up. I dont know for sure if this is the same with v2.5 but i'd be sure to double check how pointers are allocated, free'd, and used in my program if i got these kinds of errors. Take care, Al And, good luck with your Euphoria programming! My bumper sticker: "I brake for LED's"
21. Re: Very strange problem - Eu bug?? (Eu 2.5)
- Posted by Ricardo M. Forno <rmforno at tutopia.com> Mar 01, 2006
- 666 views
- Last edited Mar 02, 2006
Kat wrote: > > Robert Craig wrote: > > > People are always amazed when this type of thing occurs, > > but believe me, it's not that uncommon. It has happened to me, > > and it has happened to many other people on EUforum over the > > years. If your program is making decisions based on random > > garbage in memory, it can sometimes work with certain garbage, > > and crash or malfunction with other garbage. > > So the interpreter sees whitespace IN THE SOURCE CODE as something it should > translate to .il code as pointers to various undefined garbage?!? And then > attempt > to run it? What part of the Eu syntax is defined as "...and this > lack of keyword controls how whitespace is processed..."? It's not only > whitespace, it's done it to me before with a "--" added to a program to > comment out a trace(1) line. > > > Kat, > one of those who complained about this sort of bug before. Hey, Kat, you forgot the "garbage" part. "Garbage" is what other programs had left in memory. But this "other program" might be the Euphoria interpreter itsekf, which had processed a different data set, because blank lines and comments exist, not withstanding they do not generate code. So, the important lesson is: do not access RAM locations you are not sure what kind of data contain, because you did not explicitly initialize them. Best wishes.