This matches the API of POSIX execv: https://pubs.opengroup.org/onlinepubs/9699919799/functions/exec.html
The example is correct. The first argument to the ipstream constructor is the name of the executable to run (which will be looked up in PATH). The argv strings are passed to the new process as its argv[] array. By convention, argv[0] is the name of the executable that was run, but it doesn't have to be. You can actually pass some other string in argv[0]. So it's correct that there are two "rm" strings. One is used by the OS to find the program to run, and the other is passed to that program as its...
Patch autoconf fragments for C99 compatibility
a more elegant approach would be storing the pointer directly and using the right free() function later. The memory returned from the libsecret API is in memory anyway, so I don't think doing that would make any difference. The approach in my patch seems consistent with the handling of keys from the macOS keychain, and all other approaches in ensure_password. I could add a comment to my new code, but it seems like a pre-existing problem with ensure_password and not introduced by my changes. the relatively...
Small bugfix, the error string on a failed lookup was missing a newline.
Oh, I just used the default milestone of 1.5.0 for this ticket, without realising there's also a 1.4.5 milestone. That would be better IMHO :-) If this gets merged upstream I'd like to package it for Fedora, so getting it in the next release would be nice. It's a new feature but it's a pure extension with no impact on any existing features, so would be nice to have ASAP.
Related: https://sourceforge.net/p/isync/mailman/isync-devel/thread/CAHaCNWJpjM86a2sWK6Q-NYNgEwLECeXONhUcLCSV7BRP%2B0v79Q%40mail.gmail.com/#msg36608784 I suppose I could/should have added something about this to src/mbsyncrc.sample but the man page seems like a better place to put it.
Obtain passwords from GNOME Keyring
It's true there is no accessor for this, and the use case makes sense. I'll add it.
I see it with 7.0.0 which includes the fixes for this issue (but only _stat and _wstat), did _wstat64 change for 8.0.0?
ping?
This seems to have been fixed for _stat and _wstat but not for _wstat64. Is that intentional?
Incorrect use of XOR operator
pstream::close() should return program exit status as pclose(3) does
Committed as d21afef311be496e6495a5e2103eec7a53ecb817 - thanks! Sorry it took so long, $DAYJOB has been very busy.
Makefile top-level target canonicalization
Committed as d7227d867284c6a4cae47fa1b691348394e85728 - thanks!
Squish warning about shadowed variable in GCC 4.1.2 (CentOS 5)
Fixed in 625d4a5caa71e0256947711568fb1005831dddb9 - thanks
I take it back, on Windows "regular_file/" is the same path as "regular_file" so stripping the slash is fine, and works consistently with the expected behaviour on the OS. I was foolishly expecting Windows to have sane pathname handling, but I was wrong.
This just seems to be how Windows works, and so is a feature not a bug. I was trying to make the MinGW version of std::filesystem::status behave similar to POSIX, but after comparing it to boost::filesystem::status I think I should just accept this behaviour as correct for Windows. Feel free to close this ticket.
This just seems to be how WIndows works, and so is a feature not a bug. I was trying to make the MinGW version of std::filesystem::status behave similar to POSIX, but after comparing it to boost::filesystem::status I think I should just accept this behaviour as correct for Windows. Feel free to close this ticket.
I forgot to say that I've only tested this under Wine, not on real Windows. I don't know if the same behaviour is seen on Windows.
The fix looks wrong, it means that _stat("regular_file/", &buf) will resolve to "regular_file" but a trailing slash should only be valid on a directory. Stripping the slash unconditionally is wrong. A better fix would be to append "." to the path, so that something ending in a slash is treated as a directory, but that won't work because of https://sourceforge.net/p/mingw-w64/bugs/782/
stat, _stat, _wstat etc. incorrectly resolve '..' components in path
You assume right. Thanks for the patch.
Looks good to me.
Thanks! I think I'll rename it to something else, as I'm using a trailing underscore for member variables. Maybe "istrm" or something like that.
Patch posted to https://sourceforge.net/p/vegastrike/patches/71/
Incorrect error handling of pthreads functions
And this patch fixes several more bugs, where functions that are supposed to return...
Fix compilation error in src/cmd/unit_collide.h
This seems to be a duplicate of https://sourceforge.net/p/vegastrike/bugs/678/
undefined behaviour in Pipe::signal
There are several serious problems with the code in dispatcher.h The typedefs MutexFreeFn...
Patch against current Git sources to replace abs(uint32_t) calls with inequality...
src/LV2/gx_amp_stereo.lv2/gxamp_stereo.cpp has exactly the same bug. and also sr...
std::abs used without including relevant header
Hence, to make things work correctly for GCC versions currently available in MinGW,...
What part of "It was fixed upstream in 2015 " says we don't care? that we may have...
none of which were supported by C++ prior to C++11; of course That's inaccurate,...
Right, it returns the same value as wait or waitpid so you need to use WIFEXITED,...
should rdbuf()->status() match exit() value?
Right, it returns the same value as wait or waitpid so you need to use WIFEXITED,...
The off-by-one error seems to have been already fixed when moving the code from CVS...
Updated patch with off-by-one fixed
This patch doesn't fix the off-by-one error in base64_decode_value that causes undefined...
See also https://bugzilla.redhat.com/show_bug.cgi?id=1307323
Fails to build with C++11 or later
On 19 January 2016 at 21:26, Robert Allen wrote: Hi! I have danced around lack of...
Patch: False --> True
test-onedrive fails with Boost 1.59.0
test-onedrive fails with Boost 1.59.0
Here's a patch to delete the existing members before setting the pointers to null....
Remove redundant dynamic_cast
Here's a patch to delete the existing members before setting the pointers to null....
Unsafe copy assignment operator in WSSession
potential memory leaks in cmis-client.cxx
Don't create exceptions on the heap
Not a compiler issue, C++11 removed the implicit conversion from streams to void*...
Actually, this is a compiler bug: No it isn't. The OP's fix is correct and requi...
Not a compiler issue, C++11 removed the implicit conversion from streams to void*...
Not a compiler issue, C++11 removed the implicit conversion from streams to void*...
OK, thanks for the follow-up
Exit status reporting seems to be unreliable
By calling one of the functions that call wait(), e.g. close() I see in your second...
http://pstreams.sourceforge.net/doc/classredi_1_1basic__pstreambuf.html#a6b8782afacf7c7f92617798499f46702...
Incorrect exit status for child process is returned by basic_pstreambuf::status()
This is by design, so users can use WIFEXITED, WIFSIGNALLED etc. (See the examples...
This is by design, so users can use WIFEXITED, WIFSIGNALLED etc.
-Wshadow warning
Fixed in Git.
-Wshadow warning