Re: [PATCH] http: fix some printf format warnings on 32-bit builds

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 13 Nov 2015, at 21:02, Ramsay Jones <ramsay@xxxxxxxxxxxxxxxxxxxx> wrote:

> 
> 
> On 13/11/15 08:57, Eric Sunshine wrote:
>> On Fri, Nov 13, 2015 at 3:46 AM, Lars Schneider
>> <larsxschneider@xxxxxxxxx> wrote:
>>> On 11 Nov 2015, at 18:49, Ramsay Jones <ramsay@xxxxxxxxxxxxxxxxxxxx> wrote:
>>>> On 11/11/15 02:00, Stefan Beller wrote:
>>>>> On Tue, Nov 10, 2015 at 5:22 PM, Eric Sunshine <sunshine@xxxxxxxxxxxxxx> wrote:
>>>>>> On Tue, Nov 10, 2015 at 7:23 PM, Ramsay Jones
>>>>>> <ramsay@xxxxxxxxxxxxxxxxxxxx> wrote:
>>>>>>> Commit f8117f55 ("http: use off_t to store partial file size",
>>>>>>> 02-11-2015) changed the type of some variables from long to off_t.
>>>>>>> The 32-bit build, which enables the large filesystem interface
>>>>>>> (_FILE_OFFSET_BITS == 64), defines the off_t type as a 64-bit
>>>>>>> integer, whereas long is a 32-bit integer. This results in a couple
>>>>>>> of printf format warnings.
>>>>>> 
>>>>>> My machine is 64-bit, though, so perhaps it's misleading to
>>>>>> characterize this as a fix for 32-bit builds. In particular, off_t is
>>>>>> 'long long' on this machine, so it complains about the "long" format
>>>>>> specifier.
>>>>> 
>>>>> I wonder if 32 bit compilation can be part of travis.
>>>> 
>>>> Did this warning show up on the OS X build?
>>> 
>>> Yes, I added CFLAGS="-Werror=format" to the my experimental TravisCI
>>> build and it breaks the build on OS X.
>>> See here (you need to scroll all the way down):
>>> https://travis-ci.org/larsxschneider/git/jobs/90899656
>>> 
>>> BTW: I tried to set "-Werror" but then I got a bunch of macro redefined errors like this:
>>> ./git-compat-util.h:614:9: error: 'strlcpy' macro redefined [-Werror]
>>> 
>>> Is this a known issue? Is this an issue at all?
>> 
>> Odd. I don't experience anything like that on my Mac.
>> 
> 
> Hmm, from the output, it looks like the configure script is
> not detecting that 'strlcpy' is available (so setting
> NO_STRLCPY=YesPlease in the config.mak.autogen file).
> However, it seems to be a 'macro redirect' set in the
> /usr/include/secure/_string.h header file (presumably it
> redirects between a more or less secure version ;-)
> 
> Unfortunately, I don't have access to a mac - so I can't
> help you with the debugging. :(
> 

I don't have any experience with autotools at all. However, here is what I found out on OS X Mavericks (10.9.5):
1.) In config.mak.uname, line 103, "NO_STRLCPY = YesPlease" is set for some old OS X version. However, it looks like these settings have no impact at all.
2.) In configure.ac, line 1010, the AC_CHECK_FUNC macros (via GIT_CHECK_FUNC) is used to detect strlcpy. That detection fails on OS X Mavericks.
3.) I tried to use "AC_CHECK_DECLS" to detect strlcpy declarations on OS X and this works.

Can you give me a few hints how to debug this further? Why do have the values in config.mak.uname no impact? My idea was to detect OS X Mavericks there and unset NO_STRLCPY. Could that work?

Thanks,
Lars 

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]