There are absolutely legitimate use cases this fails to accommodate, and if they are not clear to you, then probably not for you. As a network and security professional, if you don't know how to use it or don't, you are not worth your title. You may be surprised as to why anyone would but short of the kiddies playing around because they think it is cool, there are tons of valid professional reason for it's use. So, that being said, I can indeed expect that when they make the claim that it works in portable state, otherwise they should not be offering it. Unless they can make it work consistently ALL the time without special consideration, they should not be releasing a "portable" version. So that's not a difference between fopen() and fopen_s().Yes, clearly it only works sometimes and that inconsistency is not good for a professional tool. ![]() If execution is allowed to continue, these functions return NULL and set errno to EINVAL. If filename or mode is NULL or an empty string, these functions trigger the invalid parameter handler, which is described in Parameter Validation. ![]() (That is, in fact, how Wireshark works - dumpcap writes to the file and sends messages to the Wireshark/TShark process that's reading from the file it doesn't use libpcap to read or write capture files, but somebody else might want to do the same thing.)īut there is one other difference between the "safe" versions and standard fopen: parameters are checked to avoid NULL pointer dereferencesĮach of these functions returns a pointer to the open file. The only restrictive possibility I could see for _fsopen share flags was SH_DENYWR, since I would guess that having multiple processes write to the file would be problematic.īut one might have one process writing new packets to the file and sending "hey, I wrote some more packets" messages to another process reading from the file. Please file an issue for libpcap to track this, linking back to this issue I'll close that issue by fixing libpcap to go back to using fopen(). This probably isn't a C runtime issue, it's a libpcap issue. The last WinPcap release was created based on a version of libpcap that used fopen(), so it'd open the file with "deny none" Npcap currently is based on a version that uses fopen_s(), so it opens the file with "deny all". So I vote for reverting to the old code using Boring Old fopen(), and suppressing the warning with a pragma or a command-line option - doing so in a fashion that only suppresses the complaint about fopen(), not any of the other potential complaints, e.g. The only reasons to use fopen_s() rather than fopen() are:īecause you want the "Parameter Validation" discussed in the "Security Features in the CRT" document done - but the fopen() documentation appears to say it already does the parameter validation to check for a NULL file name argument īecause you want the "Enhanced error reporting" discussed in that document done - but the fopen() document indicates that fopen() sets errno for a parameter validation failure where the exception handler tells execution to continue, the _open() page says that _open() sets errno, and the _fileno() page indicates that a FILE has a file descriptor associated with it, at least suggesting that fopen() may end up calling _open() to open the file, so fopen() may well set errno, and the errno page says it's a wrapper around a call to _errno(), which returns a pointer to an error number value, suggesting that errno might be thread-specific data, just as it is on most if not all UN*Xes, so that you get only a tiny bit of convenience from fopen_s() directly returning an errno value īecause you want the "Filesystem security" discussed in that document done - but that's presumably referring to doing "deny all" sharing, and we don't want that done īecause you want the compiler to stop warning you that you should be using fopen_s(), which we do, but we can do that in ways other than using fopen_s(). So if Microsoft decided that 1) fopen() should do read/write sharing because fopen() originally came from UNIX, and UNIX had no notion of denying access because a file was open (well, other than ETXTBSY for shared-text executable files open for execution) and 2) fopen_s() should deny sharing for safety, because it's a Windows-ism not bound by UNIX convention, and denying read access if a file is being written and write access if a file is being read is a Good Thing, then switching to fopen_s() from fopen() in 853c9a01f838e0f94bb8f80e6fac11d76b4e0efa changed pcap_open_offline()'s sharing behavior. The page for fopen() says nothing about what Boring Old fopen() does about sharing modes. If you require that a file be sharable, use _fsopen, _wfsopen with the appropriate sharing mode constant-for example, _SH_DENYNO for read/write sharing." OK, the Visual Studio 2015 page for fopen_s() says "Files that are opened by fopen_s and _wfopen_s are not sharable.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |