Comments (13)
@matejk Sure I'll check it out this week. It's sounding like that's the better long-term solution here. I do agree with Microsoft on this. As of a few days ago there's less than 14 years left to 32 bit time_t
and it shouldn't be used anymore.
Edit: 2038 - 2024 is 14 years, not 4. I've been sick for a few days and it's not helping my brain right now.
from poco.
You're right, it probably doesn't matter, and we have to do it.
Hoping to put together a PR this weekend. Through a lot of experimenting, I learned that we can't allocate an array of the struct, we need to allocate an array of bytes like before. GetAdaptersAddresses
creates a linked list structure and its size varies depending on the version of Windows. That shouldn't matter for Poco because the info nodeIdImpl
is interested in is in all versions.
from poco.
Can you send the length returned by the first GetAdaptersInfo
? It should be a multiple of the struct size from what I understood while making this change.
That'll be the value in len
after the call.
from poco.
len
is 3840, and sizeof(IP_ADAPTER_INFO)
is 648
from poco.
I believe this is some sort of packing issue. On the default packing the IP_ADAPTER_INFO
struct is 704 bytes for me, GetAdaptersInfo
returns 2816 (Win10 x64), which is a proper 4 multiple.
winnt.h contains the following assert, which verifies that the default packing option is used. Unfortunately it appears that this assert doesn't happen for other headers, such as iphlpapi.h
in this case.
static_assert(__alignof(LARGE_INTEGER) == 8, "Windows headers require the default packing option. Changing this can lead to memory corruption."
" This diagnostic can be disabled by building with WINDOWS_IGNORE_PACKING_MISMATCH defined.");
648 appears to be the correct size for x86. I can't find a way to get that size for x64. Even forcing #pragma pack(push, 1)
before including the header for IP_ADAPTER_INFO
results in a minimum of 676.
from poco.
Apologies, I've clarified the environment in my original comment - the project configuration is indeed x86
from poco.
According to this page on IP_ADAPTER_INFO
, there's an extra step to properly use it on 32 bit platforms.
To properly use the IP_ADAPTER_INFO structure on a 32-bit platform, define _USE_32BIT_TIME_T (use -D _USE_32BIT_TIME_T as an option, for example) when compiling the application to force the time_t datatype to a 4-byte datatype.
I'm not sure if _USE_32BIT_TIME_T
is something Poco could/should set. But if you set it in your program, I think it will fix the problem.
For me:
without _USE_32BIT_TIME_T
: IP_ADAPTER_INFO
size: 648, len: 2560, count: 3.95
with _USE_32BIT_TIME_T
: IP_ADAPTER_INFO
size: 640, len: 2560, count: 4
from poco.
I'm not sure if
_USE_32BIT_TIME_T
is something Poco could/should set. But if you set it in your program, I think it will fix the problem.
It should be set for this case only, and then unset (if it wasn't set to start with) to prevent it from causing some unforeseen problems elsewhere
from poco.
Page https://learn.microsoft.com/en-us/windows/win32/api/iptypes/ns-iptypes-ip_adapter_info contains remarks:
The IP_ADAPTER_INFO structure is limited to IPv4 information about a particular network adapter on the local computer. The IP_ADAPTER_INFO structure is retrieved by calling the GetAdaptersInfo function.
When using Visual Studio 2005 and later, the time_t datatype defaults to an 8-byte datatype, not the 4-byte datatype used for the LeaseObtained and LeaseExpires members on a 32-bit platform. To properly use the IP_ADAPTER_INFO structure on a 32-bit platform, define _USE_32BIT_TIME_T (use -D _USE_32BIT_TIME_T as an option, for example) when compiling the application to force the time_t datatype to a 4-byte datatype.
For use on Windows XP and later, the IP_ADAPTER_ADDRESSES structure contains both IPv4 and IPv6 information. The GetAdaptersAddresses function retrieves IPv4 and IPv6 adapter information.
Proper solution in the long term might be to use GetAdaptersAddresses
instead of GetAdaptersInfo
.
from poco.
I wanted to fix this problem in PR #4405 to set compile-time define to a single file when compiling on 32-bit Windows.
That solution is suboptimal and hacky. Function GetAdaptersInfo
can be replaced with newer function GetAdaptersAddresses
that does not have time_t size issues. (https://learn.microsoft.com/en-us/windows/win32/api/iphlpapi/nf-iphlpapi-getadaptersaddresses).
@andrewauclair, would you be willing to rewrite the function Windows variant of EnvironmentImpl::nodeIdImpl
to use GetAdaptersAddresses
?
from poco.
Is Environment::nodeId
something that might be called often? I've been experimenting with GetAdaptersAddresses
and it requests a nearly 20k byte buffer, compared to GetAdaptersInfo
which requests a buffer of 3,500 bytes.
from poco.
We don't really have an option, IMO. The temporary buffer is released each time anyway.
Are you concerned about memory usage?
20kB shall not be a problem on a Windows machine I think.
from poco.
Example on MS web site can be easily adapted, I think.
from poco.
Related Issues (20)
- ODBC Unicode wrappers do not check for null length pointers
- On Poco::Buffer<char> deallocation, free(): invalid next size (normal) HOT 2
- FAILED: bin/libPocoActiveRecord.dll lib/libPocoActiveRecord.dll.a HOT 1
- Upgrade bundled SQLite to 3.45.2
- HTTP cookie specification update HOT 2
- why ini file don't support write, is it difficult? HOT 1
- Checksum mismatch for release 1.13.3 HOT 6
- Issue with Websocket+TLS in Poco 1.13.3 HOT 7
- RecordSet issue since 1.10.0
- SocketStream messages doesn't send, and send after close socket.
- SQLChannel stops logging on LoggingSubsystem shutdown HOT 1
- Build Error in gcc 8 with POCO 1.13.0 Release. HOT 3
- decodeWord adds spaces at folding borders, when there are special characters encoded
- Serializable Isolation level for SQLite Databases
- Socket::available Causes Connection Reset by Peer on Windows UDP Sockets HOT 3
- SetSourceIP Error
- Postgres CMakeList.txt HOT 1
- Using passive mode, it seems that it has not been converted to data connection
- The load balancing issue in Poco::ActiveThreadPool HOT 5
- ServerApplication waitForTerminationRequest terminate HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from poco.