[sword-devel] SVN 3813 makes compilation of Sword fail
Troy A. Griffitts
scribe at crosswire.org
Mon Oct 19 05:25:13 EDT 2020
Thanks Jaak,
I think it is safe to assume that the count of open files for our
process will be less than the storage capacity of a pointer. I can't
imagine an implementation where that has ever not been true or might
ever become false, but your solution would certainly work as well. As
for my preference to keep things as they are, it is simply a preference:
I don't typically like sending pointers of stack varables off anywhere.
For me, it's a good habit to keep me from times it would be dangerous,
though, as you noted, your suggestion would work just fine here, as we
are sure FTPLib blocks and doesn't let our stack variable out of scope
or else our call to close at the end of the method would really mess us
up! Thank you for the suggestion, as always. I hope you've had a good
weekend.
Troy
On 10/19/20 9:55 AM, Jaak Ristioja wrote:
> On 19.10.20 10:22, Jaak Ristioja wrote:
>> Ah indeed, thanks for correcting my incorrect reasoning I did late
>> last night! But you are still relying on implementation-defined
>> behavior here which might not work for every platform, and there
>> might not even be an explicit guarantee it will continue to work for
>> your platform.
>>
>> As far as I can tell, the safest way is to pass to the callback the
>> pointer to int. I think it would be valid in
>> FTPLibFTPTransport::getURL() to pass &fd, e.g.:
>>
>> FtpOptions(FTPLIB_CALLBACK_WRITERARG, (long)fd, ftpConnection);
>
> Sorry, I meant:
>
> FtpOptions(FTPLIB_CALLBACK_WRITERARG, (long)&fd, ftpConnection);
>
> Although according to
> https://www.mbpfaus.net/~pfau/ftplib/FtpOptions.html "New programs
> should call FtpSetCallback() and FtpClearCallback() to change callback
> options."
>
>>
>> and in my_filewriter() just convert the (void*) argument to (int*)
>> and, and dereference the pointer:
>>
>> int output = *static_cast<int *>(fd);
>>
>> I believe this would avoid the implementation-defined behavior. As
>> far as I can tell, the my_filewriter() callback is only called when
>> inside the getURL() function, hence fd is always reachable and valid
>> when my_filewriter() is called by FTPLib.
>>
>> Best regards,
>> J
>>
>> On 19.10.20 09:32, Troy A. Griffitts wrote:
>>> Hi Jaak,
>>>
>>> We're not storing a pointer here. FTPLib gives us a void * we can do
>>> whatever we want with which we give them on initialization of a file
>>> transfer and they simply pass this back to us on write calls and
>>> status updates. We're storing the file handle there and we know it's
>>> an int and thus we explicitly cast it to an int. I don't mind a
>>> warning here, even with the explicit cast (which I assumed would,
>>> and I think should, skip the warning) but the compiler actually
>>> throws a compile error here, which is just stupid. I had to first
>>> cast the pointer to a size_t and then to an int to avoid the
>>> compiler error.
>>>
>>>
>>> On October 19, 2020 1:07:48 AM GMT+02:00, Jaak Ristioja
>>> <jaak at ristioja.ee> wrote:
>>>> "Added extra cast (int)(size_t) to avoid stupid clang error that
>>>> doesn't
>>>> like void * being cast (int) directly to an int."
>>>>
>>>> UH-OH!!!
>>>>
>>>> First of all, the build that failed for BibleTime was using GCC not
>>>> Clang.
>>>>
>>>> Secondly, the compiler is correct to warn, because a pointer does not
>>>> always fit into an int, e.g. for the LLP64 an LP64 data models [1]. So
>>>> it seems that you might be throwing away half of the bits and
>>>> expect it
>>>>
>>>> to always work. For those data models it might work if your OS only
>>>> gives you addresses in the range of [0, 2^32) but that is not always
>>>> guaranteed, leading to undefined behavior.
>>>>
>>>> In short, please don't store pointers in integers other than intptr_t
>>>> and uintptr_t and convert them using reinterpret_cast! See also:
>>>>
>>>> http://eel.is/c++draft/expr.reinterpret.cast#5
>>>> http://eel.is/c++draft/basic.stc.dynamic.safety
>>>>
>>>> Best regards,
>>>> J
>>>>
>>>> [1] https://en.wikipedia.org/wiki/64-bit_computing#64-bit_data_models
>>>>
>>>>
>>>>
>>>> On 19.10.20 01:23, Troy A. Griffitts wrote:
>>>>> Crapola. Should be fixed. This was intended to be a call to the new
>>>>
>>>>> FileMgr::write which hides the OS-specific impl, but I was configured
>>>> to
>>>>> use CURL instead of FTPLib, so I missed the compilation error. The
>>>>> Android port uses FTPLib and I just built there successfully with the
>>>>
>>>>> committed I just pushed. Thank you Jaak.
>>>>>
>>>>> Troy
>>>>>
>>>>>
>>>>> On 10/18/20 11:57 PM, Jaak Ristioja wrote:
>>>>>> Hello!
>>>>>>
>>>>>> The commit "A bit more work on making it easier to use SWORD in a
>>>>>> threadsafe manner." makes compilation of Sword fail:
>>>>>>
>>>>>> src/mgr/ftplibftpt.cpp: In function ‘int
>>>>>> sword::{anonymous}::my_filewriter(netbuf*, void*, size_t, void*)’:
>>>>>> src/mgr/ftplibftpt.cpp:52:21: error: cast from ‘void*’ to ‘int’
>>>> loses
>>>>>> precision [-fpermissive]
>>>>>> int output = (int)fd;
>>>>>> ^~
>>>>>> src/mgr/ftplibftpt.cpp: In function ‘int
>>>>>> sword::{anonymous}::my_filewriter(netbuf*, void*, size_t, void*)’:
>>>>>> src/mgr/ftplibftpt.cpp:52:21: error: cast from ‘void*’ to ‘int’
>>>> loses
>>>>>> precision [-fpermissive]
>>>>>> int output = (int)fd;
>>>>>> ^~
>>>>>> src/mgr/ftplibftpt.cpp:53:3: error: ‘write’ was not declared in this
>>>>
>>>>>> scope
>>>>>> write(output, buffer, size);
>>>>>> ^~~~~
>>>>>> src/mgr/ftplibftpt.cpp:53:3: error: ‘write’ was not declared in this
>>>>
>>>>>> scope
>>>>>> write(output, buffer, size);
>>>>>> ^~~~~
>>>>>> src/mgr/ftplibftpt.cpp:53:3: note: suggested alternative: ‘fwrite’
>>>>>> write(output, buffer, size);
>>>>>>
>>>>>> See https://github.com/bibletime/bibletime/runs/1272250545 for the
>>>>>> failing build run.
>>>>>>
>>>>>> Commit details in our git mirror of the Sword SVN repository:
>>>>>>
>>>> https://github.com/bibletime/crosswire-sword-mirror/commit/c52559ecae
>>>>
>>>>>>
>>>>>>
>>>>>> Best regards,
>>>>>> J
>>>>>> _______________________________________________
>>>>>> sword-devel mailing list: sword-devel at crosswire.org
>>>>>> http://crosswire.org/mailman/listinfo/sword-devel
>>>>>> Instructions to unsubscribe/change your settings at above page
>>>>> _______________________________________________
>>>>> sword-devel mailing list: sword-devel at crosswire.org
>>>>> http://crosswire.org/mailman/listinfo/sword-devel
>>>>> Instructions to unsubscribe/change your settings at above page
>>>>
>>>> _______________________________________________
>>>> sword-devel mailing list: sword-devel at crosswire.org
>>>> http://crosswire.org/mailman/listinfo/sword-devel
>>>> Instructions to unsubscribe/change your settings at above page
>>>
>>>
>>> _______________________________________________
>>> sword-devel mailing list: sword-devel at crosswire.org
>>> http://crosswire.org/mailman/listinfo/sword-devel
>>> Instructions to unsubscribe/change your settings at above page
>>>
>>
>> _______________________________________________
>> sword-devel mailing list: sword-devel at crosswire.org
>> http://crosswire.org/mailman/listinfo/sword-devel
>> Instructions to unsubscribe/change your settings at above page
>
> _______________________________________________
> sword-devel mailing list: sword-devel at crosswire.org
> http://crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
More information about the sword-devel
mailing list