Warning regarding use of "%ld" vs "%lld"

480 views
Skip to first unread message

björn

unread,
Jun 6, 2010, 9:12:18 AM6/6/10
to vim...@googlegroups.com
Hi,

Lately I've been getting the following warning (on Mac OS X 10.6, 64 bit):

fileio.c: In function ‘msg_add_lines’:
fileio.c:5230: warning: format ‘%ld’ expects type ‘long int’, but
argument 6 has type ‘off_t’
fileio.c:5247: warning: format ‘%ld’ expects type ‘long int’, but
argument 5 has type ‘off_t’

Apparently, LONG_LONG_OFF_T is not getting defined which causes "%ld"
to be used instead of "%lld" inside 'msg_add_lines'. If I define it
(in vim.h) everything compiles fine.

The relevant lines in vim.h are:

#if defined(SIZEOF_OFF_T) && (SIZEOF_OFF_T > SIZEOF_LONG)
# define LONG_LONG_OFF_T
#endif

On my system neither SIZEOF_OFF_T nor SIZEOF_LONG are defined (in
auto/config.h). Not only that, I've checked and

sizeof(off_t) = 8
sizeof(long) = 8

I guess we need some other heuristic as to when LONG_LONG_OFF_T should
be defined, but I don't know which exactly. Does anybody else have
any ideas?

Björn

Tony Mechelynck

unread,
Jun 6, 2010, 12:23:54 PM6/6/10
to vim...@googlegroups.com, björn
On 06/06/10 15:12, bj�rn wrote:
> Hi,
>
> Lately I've been getting the following warning (on Mac OS X 10.6, 64 bit):
>
> fileio.c: In function �msg_add_lines�:
> fileio.c:5230: warning: format �%ld� expects type �long int�, but
> argument 6 has type �off_t�
> fileio.c:5247: warning: format �%ld� expects type �long int�, but
> argument 5 has type �off_t�

>
> Apparently, LONG_LONG_OFF_T is not getting defined which causes "%ld"
> to be used instead of "%lld" inside 'msg_add_lines'. If I define it
> (in vim.h) everything compiles fine.
>
> The relevant lines in vim.h are:
>
> #if defined(SIZEOF_OFF_T)&& (SIZEOF_OFF_T> SIZEOF_LONG)

> # define LONG_LONG_OFF_T
> #endif
>
> On my system neither SIZEOF_OFF_T nor SIZEOF_LONG are defined (in
> auto/config.h). Not only that, I've checked and
>
> sizeof(off_t) = 8
> sizeof(long) = 8
>
> I guess we need some other heuristic as to when LONG_LONG_OFF_T should
> be defined, but I don't know which exactly. Does anybody else have
> any ideas?
>
> Bj�rn
>

In src/auto/config.log I see the following which "ought" to (and, on my
system, do) give the right sizeof() values for long and off_t (and two
others); maybe you should try a "make reconfig"? (and NOT run
"configure" except through make because in some cases make may invoke
configure itself, which would override any parameters you gave on the
configure command-line -- see
http://users.skynet.be/antoine.mechelynck/compunix.htm about setting
configure arguments via environment variables given to make).

> configure:11390: checking size of int
> configure:11395: gcc -o conftest -O2 -fno-strength-reduce -Wall -D_FORTIFY_SOURCE=1 -L. -rdynamic -Wl,-export-dynamic -Wl,-E -Wl,-rpath,/usr/lib/perl5/5.10.0/i586-linux-thread-multi/CORE -L. -rdynamic -Wl,-export-dynamic -Wl,-E -Wl,-rpath,/usr/lib/perl5/5.10.0/i586-linux-thread-multi/CORE -L. -rdynamic -Wl,-export-dynamic -Wl,-E -Wl,-rpath,/usr/lib/perl5/5.10.0/i586-linux-thread-multi/CORE -L. -rdynamic -Wl,-export-dynamic -Wl,-E -Wl,-rpath,/usr/lib/perl5/5.10.0/i586-linux-thread-multi/CORE -L/usr/local/lib conftest.c -lm -lncurses -lnsl -lacl -lattr -lgpm >&5
> configure:11395: $? = 0
> configure:11395: ./conftest
> configure:11395: $? = 0
> configure:11410: result: 4
> configure:11424: checking size of long
> configure:11429: gcc -o conftest -O2 -fno-strength-reduce -Wall -D_FORTIFY_SOURCE=1 -L. -rdynamic -Wl,-export-dynamic -Wl,-E -Wl,-rpath,/usr/lib/perl5/5.10.0/i586-linux-thread-multi/CORE -L. -rdynamic -Wl,-export-dynamic -Wl,-E -Wl,-rpath,/usr/lib/perl5/5.10.0/i586-linux-thread-multi/CORE -L. -rdynamic -Wl,-export-dynamic -Wl,-E -Wl,-rpath,/usr/lib/perl5/5.10.0/i586-linux-thread-multi/CORE -L. -rdynamic -Wl,-export-dynamic -Wl,-E -Wl,-rpath,/usr/lib/perl5/5.10.0/i586-linux-thread-multi/CORE -L/usr/local/lib conftest.c -lm -lncurses -lnsl -lacl -lattr -lgpm >&5
> configure:11429: $? = 0
> configure:11429: ./conftest
> configure:11429: $? = 0
> configure:11444: result: 4
> configure:11458: checking size of time_t
> configure:11463: gcc -o conftest -O2 -fno-strength-reduce -Wall -D_FORTIFY_SOURCE=1 -L. -rdynamic -Wl,-export-dynamic -Wl,-E -Wl,-rpath,/usr/lib/perl5/5.10.0/i586-linux-thread-multi/CORE -L. -rdynamic -Wl,-export-dynamic -Wl,-E -Wl,-rpath,/usr/lib/perl5/5.10.0/i586-linux-thread-multi/CORE -L. -rdynamic -Wl,-export-dynamic -Wl,-E -Wl,-rpath,/usr/lib/perl5/5.10.0/i586-linux-thread-multi/CORE -L. -rdynamic -Wl,-export-dynamic -Wl,-E -Wl,-rpath,/usr/lib/perl5/5.10.0/i586-linux-thread-multi/CORE -L/usr/local/lib conftest.c -lm -lncurses -lnsl -lacl -lattr -lgpm >&5
> configure:11463: $? = 0
> configure:11463: ./conftest
> configure:11463: $? = 0
> configure:11478: result: 4
> configure:11492: checking size of off_t
> configure:11497: gcc -o conftest -O2 -fno-strength-reduce -Wall -D_FORTIFY_SOURCE=1 -L. -rdynamic -Wl,-export-dynamic -Wl,-E -Wl,-rpath,/usr/lib/perl5/5.10.0/i586-linux-thread-multi/CORE -L. -rdynamic -Wl,-export-dynamic -Wl,-E -Wl,-rpath,/usr/lib/perl5/5.10.0/i586-linux-thread-multi/CORE -L. -rdynamic -Wl,-export-dynamic -Wl,-E -Wl,-rpath,/usr/lib/perl5/5.10.0/i586-linux-thread-multi/CORE -L. -rdynamic -Wl,-export-dynamic -Wl,-E -Wl,-rpath,/usr/lib/perl5/5.10.0/i586-linux-thread-multi/CORE -L/usr/local/lib conftest.c -lm -lncurses -lnsl -lacl -lattr -lgpm >&5
> configure:11497: $? = 0
> configure:11497: ./conftest
> configure:11497: $? = 0
> configure:11512: result: 8

This results in the following src/auto/config.h lines 37-51:

> /* defined always when using configure */
> #define UNIX 1
>
> /* Defined to the size of an int */
> #define SIZEOF_INT 4
>
> /* Defined to the size of a long */
> #define SIZEOF_LONG 4
>
> /* Defined to the size of off_t */
> #define SIZEOF_OFF_T 8
>
> /* Defined to the size of time_t */
> #define SIZEOF_TIME_T 4
>

Best regards,
Tony.
--
"OK, now let's look at four dimensions on the blackboard."
-- Dr. Joy

björn

unread,
Jun 6, 2010, 1:42:17 PM6/6/10
to Tony Mechelynck, vim...@googlegroups.com
On 6 June 2010 18:23, Tony Mechelynck wrote:

> On 06/06/10 15:12, björn wrote:
>>
>> Hi,
>>
>> Lately I've been getting the following warning (on Mac OS X 10.6, 64 bit):
>>
>> fileio.c: In function ‘msg_add_lines’:
>> fileio.c:5230: warning: format ‘%ld’ expects type ‘long int’, but
>> argument 6 has type ‘off_t’
>> fileio.c:5247: warning: format ‘%ld’ expects type ‘long int’, but
>> argument 5 has type ‘off_t’

>>
>> Apparently, LONG_LONG_OFF_T is not getting defined which causes "%ld"
>> to be used instead of "%lld" inside 'msg_add_lines'.  If I define it
>> (in vim.h) everything compiles fine.
>>
>> The relevant lines in vim.h are:
>>
>> #if defined(SIZEOF_OFF_T)&&  (SIZEOF_OFF_T>  SIZEOF_LONG)
>> # define LONG_LONG_OFF_T
>> #endif
>>
>> On my system neither SIZEOF_OFF_T nor SIZEOF_LONG are defined (in
>> auto/config.h).  Not only that, I've checked and
>>
>> sizeof(off_t) = 8
>> sizeof(long) = 8
>>
>> I guess we need some other heuristic as to when LONG_LONG_OFF_T should
>> be defined, but I don't know which exactly.  Does anybody else have
>> any ideas?
>>
>> Björn

>>
>
> In src/auto/config.log I see the following which "ought" to (and, on my
> system, do) give the right sizeof() values for long and off_t (and two
> others);

Part of the problem is that the "right" values of long and off_t are
the same (both 8) on my machine, so even if SIZEOF_OFF_T and
SIZEOF_LONG were defined the test in vim.h would not define
LONG_LONG_OFF_T as it should.

> maybe you should try a "make reconfig"? (and NOT run "configure"
> except through make because in some cases make may invoke configure itself,
> which would override any parameters you gave on the configure command-line
> -- see http://users.skynet.be/antoine.mechelynck/compunix.htm about setting
> configure arguments via environment variables given to make).

No, it makes no difference.

>> configure:11492: checking size of off_t
>> configure:11497: gcc -o conftest -O2 -fno-strength-reduce -Wall
>> -D_FORTIFY_SOURCE=1  -L.  -rdynamic -Wl,-export-dynamic  -Wl,-E
>> -Wl,-rpath,/usr/lib/perl5/5.10.0/i586-linux-thread-multi/CORE  -L.
>>  -rdynamic -Wl,-export-dynamic  -Wl,-E
>> -Wl,-rpath,/usr/lib/perl5/5.10.0/i586-linux-thread-multi/CORE  -L.
>>  -rdynamic -Wl,-export-dynamic  -Wl,-E
>> -Wl,-rpath,/usr/lib/perl5/5.10.0/i586-linux-thread-multi/CORE  -L.
>>  -rdynamic -Wl,-export-dynamic  -Wl,-E
>> -Wl,-rpath,/usr/lib/perl5/5.10.0/i586-linux-thread-multi/CORE
>> -L/usr/local/lib conftest.c -lm -lncurses -lnsl   -lacl -lattr -lgpm >&5
>> configure:11497: $? = 0
>> configure:11497: ./conftest
>> configure:11497: $? = 0
>> configure:11512: result: 8

My config.log looks like this:

configure:11865: checking for off_t
configure:11895: gcc -c -O2 -fno-strength-reduce -Wall -DMACOS_X_UNIX
-no-cpp-precomp conftest.c >&5
configure:11901: $? = 0
configure:11916: result: yes

It seems that it never even tries to figure out the proper size.

> This results in the following src/auto/config.h lines 37-51:
>>

>> /* Defined to the size of a long */
>> #define SIZEOF_LONG 4
>>
>> /* Defined to the size of off_t */
>> #define SIZEOF_OFF_T 8

These two are always undefined for me.

To conclude; there are two problems:

(1) On Mac OS X 10.6 configure fails to check the size of "long" and
"off_t" (I'm guessing I'm not the only person having this problem, but
I don't know.)

(2) On Mac OS X 10.6 sizeof(long) == sizeof(off_t) so the test in
vim.h would never do anything even if (1) was ok. A new test is
needed as to when LONG_LONG_OFF_T should be defined in vim.h. I guess
this will need to be Mac OS X specific, but I don't know for sure
hence my first post asking for advice.

Björn

James Vega

unread,
Jun 8, 2010, 5:05:19 PM6/8/10
to vim...@googlegroups.com
On Sun, Jun 6, 2010 at 1:42 PM, björn <bjorn.w...@gmail.com> wrote:
> On 6 June 2010 18:23, Tony Mechelynck wrote:
> >[snip]

> Part of the problem is that the "right" values of long and off_t are
> the same (both 8) on my machine, so even if SIZEOF_OFF_T and
> SIZEOF_LONG were defined the test in vim.h would not define
> LONG_LONG_OFF_T as it should.

That's not a problem. That's exactly as it should be. LONG_LONG_OFF_T
is specifically for the case where off_t and long have different sizes.

> My config.log looks like this:
>
> configure:11865: checking for off_t
> configure:11895: gcc -c -O2 -fno-strength-reduce -Wall  -DMACOS_X_UNIX
> -no-cpp-precomp conftest.c >&5
> configure:11901: $? = 0
> configure:11916: result: yes
>
> It seems that it never even tries to figure out the proper size.

That's the only occurence of off_t? The size checking is performed much
later than checking for the existence of off_t.

>> This results in the following src/auto/config.h lines 37-51:
>>>
>>> /* Defined to the size of a long */
>>> #define SIZEOF_LONG 4
>>>
>>> /* Defined to the size of off_t */
>>> #define SIZEOF_OFF_T 8
>
> These two are always undefined for me.
>
> To conclude; there are two problems:
>
> (1) On Mac OS X 10.6 configure fails to check the size of "long" and
> "off_t" (I'm guessing I'm not the only person having this problem, but
> I don't know.)

It sounds like your configure script is not current. Either that or
you're checking src/auto/config.h before the configure script has been
run. src/auto/config.h is updated by the results of the configure
script, so make sure you're checking it at the end of a build.

> (2) On Mac OS X 10.6 sizeof(long) == sizeof(off_t) so the test in
> vim.h would never do anything even if (1) was ok.  A new test is
> needed as to when LONG_LONG_OFF_T should be defined in vim.h.  I guess
> this will need to be Mac OS X specific, but I don't know for sure
> hence my first post asking for advice.

The sole purpose of LONG_LONG_OFF_T is for systems where sizeof(long) !=
sizeof(off_t), since on those systems we can't simply print off_t as a
long. Since you've shown that the sizes are the same on your system,
and forcing use of "%lld" makes your compiler shut up, it looks like a
bug in your compiler.

--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega <jame...@jamessan.com>

Tony Mechelynck

unread,
Jun 8, 2010, 5:32:43 PM6/8/10
to björn, vim...@googlegroups.com
On 06/06/10 19:42, bj�rn wrote:

Sorry, your post just arrived; apparently it got held more than two days
between the first two gmail servers on its way.

> On 6 June 2010 18:23, Tony Mechelynck wrote:

>> On 06/06/10 15:12, bj�rn wrote:
>>>
>>> Hi,
>>>
>>> Lately I've been getting the following warning (on Mac OS X 10.6, 64 bit):
>>>

>>> fileio.c: In function �msg_add_lines�:
>>> fileio.c:5230: warning: format �%ld� expects type �long int�, but
>>> argument 6 has type �off_t�

>>> fileio.c:5247: warning: format �%ld� expects type �long int�, but
>>> argument 5 has type �off_t�


>>>
>>> Apparently, LONG_LONG_OFF_T is not getting defined which causes "%ld"
>>> to be used instead of "%lld" inside 'msg_add_lines'. If I define it
>>> (in vim.h) everything compiles fine.
>>>
>>> The relevant lines in vim.h are:
>>>
>>> #if defined(SIZEOF_OFF_T)&& (SIZEOF_OFF_T> SIZEOF_LONG)
>>> # define LONG_LONG_OFF_T
>>> #endif
>>>
>>> On my system neither SIZEOF_OFF_T nor SIZEOF_LONG are defined (in
>>> auto/config.h). Not only that, I've checked and
>>>
>>> sizeof(off_t) = 8
>>> sizeof(long) = 8
>>>
>>> I guess we need some other heuristic as to when LONG_LONG_OFF_T should
>>> be defined, but I don't know which exactly. Does anybody else have
>>> any ideas?
>>>

>>> Bj�rn

That's some 500 lines lower. Nothing near line 11492 of configure, just
after it defines SIZEOF_INT ? Maybe you should rerun "make autoconf", or
make sure you have the right src/auto/configure ? Oh, and since May 15
15:04:53 2010 +0200 both Vim 7.2 and Vim 7.3a use autoconv 2.65 rather
than 2.63, there was a changeset about that in both branches on the
Mercurial repo.

See also the comment at lines 1614-1632 of src/Makefile.

Here's what I see at src/configure.in lines 2977-2980:

AC_CHECK_SIZEOF([int])
AC_CHECK_SIZEOF([long])
AC_CHECK_SIZEOF([time_t])
AC_CHECK_SIZEOF([off_t])

It should generate similar checks in auto/configure for all four.

>
> It seems that it never even tries to figure out the proper size.
>
>> This results in the following src/auto/config.h lines 37-51:
>>>
>>> /* Defined to the size of a long */
>>> #define SIZEOF_LONG 4
>>>
>>> /* Defined to the size of off_t */
>>> #define SIZEOF_OFF_T 8
>
> These two are always undefined for me.
>
> To conclude; there are two problems:
>
> (1) On Mac OS X 10.6 configure fails to check the size of "long" and
> "off_t" (I'm guessing I'm not the only person having this problem, but
> I don't know.)
>
> (2) On Mac OS X 10.6 sizeof(long) == sizeof(off_t) so the test in
> vim.h would never do anything even if (1) was ok. A new test is
> needed as to when LONG_LONG_OFF_T should be defined in vim.h. I guess
> this will need to be Mac OS X specific, but I don't know for sure
> hence my first post asking for advice.

Do you mean on Mac Os X 10.6/64 a "long int" is shorter than a "long" ?

>
> Bj�rn
>

Best regards,
Tony.
--
APL is a mistake, carried through to perfection. It is the language of
the future for the problems of the past: it creates a new generation of
coding bums.

björn

unread,
Jun 9, 2010, 4:32:21 AM6/9/10
to vim...@googlegroups.com
On 8 June 2010 23:32, Tony Mechelynck wrote:

> On 06/06/10 19:42, björn wrote:
>
>> On 6 June 2010 18:23, Tony Mechelynck wrote:
>>>

The line discrepancy is due to the fact that I'm using the MacVim
configure.in which adds a few lines.

However, you seem to be onto something about the use of autoconf 2.65.
I just checked and the version of autoconf that comes with the OS X
10.6 dev tools is 2.61. Now, I don't quite get the comment near line
1614: I have to run autoconf manually in order to produce
src/configure (since I change configure.in for MacVim)...I'm guessing
this comment applies to people who do not modify configure.in?

At any rate, I checked out Vim without the MacVim modifications, made
sure _not_ to run (my outdated) autoconf, and now the SIZEOF_* get
defined properly in config.h. I assume the problem is that I'm using
an old autoconf.


>> (2) On Mac OS X 10.6 sizeof(long) == sizeof(off_t) so the test in
>> vim.h would never do anything even if (1) was ok. A new test is
>> needed as to when LONG_LONG_OFF_T should be defined in vim.h. I guess
>> this will need to be Mac OS X specific, but I don't know for sure
>> hence my first post asking for advice.
>
> Do you mean on Mac Os X 10.6/64 a "long int" is shorter than a "long" ?

No, "long int" is the same as "long". I'm only saying that my
compiler seems to insist that in order to print off_t values you need
to use "%lld", not "%ld".

Björn

björn

unread,
Jun 9, 2010, 4:41:56 AM6/9/10
to vim...@googlegroups.com
On 8 June 2010 23:05, James Vega wrote:

> On Sun, Jun 6, 2010 at 1:42 PM, björn wrote:
>
>> My config.log looks like this:
>>
>> configure:11865: checking for off_t
>> configure:11895: gcc -c -O2 -fno-strength-reduce -Wall  -DMACOS_X_UNIX
>> -no-cpp-precomp conftest.c >&5
>> configure:11901: $? = 0
>> configure:11916: result: yes
>>
>> It seems that it never even tries to figure out the proper size.
>
> That's the only occurence of off_t?  The size checking is performed much
> later than checking for the existence of off_t.

Yes, that is the only occurrence of off_t. But...it seems the problem
stems from the fact I use autoconf 2.61 to generate src/configure (I
have to generate this file since my configure.in contains
modifications for MacVim). See my previous post in reply to Tony.

>> (2) On Mac OS X 10.6 sizeof(long) == sizeof(off_t) so the test in
>> vim.h would never do anything even if (1) was ok.  A new test is
>> needed as to when LONG_LONG_OFF_T should be defined in vim.h.  I guess
>> this will need to be Mac OS X specific, but I don't know for sure
>> hence my first post asking for advice.
>
> The sole purpose of LONG_LONG_OFF_T is for systems where sizeof(long) !=
> sizeof(off_t), since on those systems we can't simply print off_t as a
> long.  Since you've shown that the sizes are the same on your system,
> and forcing use of "%lld" makes your compiler shut up, it looks like a
> bug in your compiler.

$ gcc --version
i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5659)

All I can say is that if you want to print an off_t value on OS X 10.6
then "%lld" must be used or that warning pops up.

Since those two lines in fileio.c are the only places where an off_t
is printed I may just go ahead and add some MacVim-specific #ifdefs to
get rid of the warning in the MacVim code, unless some other solution
presents itself. I might also try some Apple-specific mailing list to
see if I can get any answers there about this warning.

Thanks,
Björn

James Vega

unread,
Jun 9, 2010, 11:10:13 AM6/9/10
to vim...@googlegroups.com
On Wed, Jun 9, 2010 at 4:41 AM, björn <bjorn.w...@gmail.com> wrote:
> On 8 June 2010 23:05, James Vega wrote:
>> On Sun, Jun 6, 2010 at 1:42 PM, björn wrote:
>>
>>> My config.log looks like this:
>>>
>>> configure:11865: checking for off_t
>>> configure:11895: gcc -c -O2 -fno-strength-reduce -Wall  -DMACOS_X_UNIX
>>> -no-cpp-precomp conftest.c >&5
>>> configure:11901: $? = 0
>>> configure:11916: result: yes
>>>
>>> It seems that it never even tries to figure out the proper size.
>>
>> That's the only occurence of off_t?  The size checking is performed much
>> later than checking for the existence of off_t.
>
> Yes, that is the only occurrence of off_t.  But...it seems the problem
> stems from the fact I use autoconf 2.61 to generate src/configure (I
> have to generate this file since my configure.in contains
> modifications for MacVim).  See my previous post in reply to Tony.

That's odd. The AC_CHECK_SIZEOF macro has been in Autoconf since 2.50.
I just tested on Debian Etch (since that has Autoconf 2.61) and
running "make autoconf" generates a configure that detects off_t size.

>>> (2) On Mac OS X 10.6 sizeof(long) == sizeof(off_t) so the test in
>>> vim.h would never do anything even if (1) was ok.  A new test is
>>> needed as to when LONG_LONG_OFF_T should be defined in vim.h.  I guess
>>> this will need to be Mac OS X specific, but I don't know for sure
>>> hence my first post asking for advice.
>>
>> The sole purpose of LONG_LONG_OFF_T is for systems where sizeof(long) !=
>> sizeof(off_t), since on those systems we can't simply print off_t as a
>> long.  Since you've shown that the sizes are the same on your system,
>> and forcing use of "%lld" makes your compiler shut up, it looks like a
>> bug in your compiler.
>
> $ gcc --version
> i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5659)
>
> All I can say is that if you want to print an off_t value on OS X 10.6
> then "%lld" must be used or that warning pops up.

I don't currently have access to a 64-bit system to test if this is
Apple-specific, but I can check later tonight.

Dominique Pellé

unread,
Jun 9, 2010, 5:17:25 PM6/9/10
to vim...@googlegroups.com
björn wrote:

> $ gcc --version
> i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5659)
>
> All I can say is that if you want to print an off_t value on OS X 10.6
> then "%lld" must be used or that warning pops up.
>
> Since those two lines in fileio.c are the only places where an off_t
> is printed I may just go ahead and add some MacVim-specific #ifdefs to
> get rid of the warning in the MacVim code, unless some other solution
> presents itself.  I might also try some Apple-specific mailing list to
> see if I can get any answers there about this warning.

How about putting a cast to long as follows? If LONG_LONG_OFF_T
is undefined, then casting off_t to long does not lose precision
and should fix the compilation warning:

diff -r 0e27866cea99 src/fileio.c
--- a/src/fileio.c Tue Jun 08 23:17:01 2010 +0200
+++ b/src/fileio.c Wed Jun 09 23:09:11 2010 +0200
@@ -5225,12 +5225,11 @@
if (shortmess(SHM_LINES))
sprintf((char *)p,
#ifdef LONG_LONG_OFF_T
- "%ldL, %lldC",
-#else
- "%ldL, %ldC",
-#endif
- lnum, nchars);
- else
+ "%ldL, %lldC", lnum, nchars);
+#else
+ "%ldL, %ldC", lnum, (long)nchars);
+#endif
+ else
{
if (lnum == 1)
STRCPY(p, _("1 line, "));
@@ -5242,11 +5241,10 @@
else
sprintf((char *)p,
#ifdef LONG_LONG_OFF_T
- _("%lld characters"),
-#else
- _("%ld characters"),
-#endif
- nchars);
+ _("%lld characters"), nchars);
+#else
+ _("%ld characters"), (long)nchars);
+#endif
}
}

björn

unread,
Jun 10, 2010, 12:27:04 PM6/10/10
to vim...@googlegroups.com, Bram Moolenaar
2010/6/9 Dominique Pellé:

> björn wrote:
>
>> $ gcc --version
>> i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5659)
>>
>> All I can say is that if you want to print an off_t value on OS X 10.6
>> then "%lld" must be used or that warning pops up.
>>
>> Since those two lines in fileio.c are the only places where an off_t
>> is printed I may just go ahead and add some MacVim-specific #ifdefs to
>> get rid of the warning in the MacVim code, unless some other solution
>> presents itself.  I might also try some Apple-specific mailing list to
>> see if I can get any answers there about this warning.
>
> How about putting a cast to long as follows?  If LONG_LONG_OFF_T
> is undefined, then casting off_t to long does not lose precision
> and should fix the compilation warning:

Thanks Dominique, that seems like a clever trick to me. I just tried
it and it works fine (the warning goes away).

I also made a little test program to print a 64 bit int using %ld as
well as %lld and both give the same result (so this patch works
properly).

I modified the patch slightly by moving the final parenthesis outside
the #ifdef and added a comment (see below). Bram: would you merge
this into the Vim code or would you rather I just apply it to the
MacVim code?

Björn


diff --git a/src/fileio.c b/src/fileio.c
index 3163a74..239a37c 100644
--- a/src/fileio.c
+++ b/src/fileio.c
@@ -5229,11 +5229,12 @@ msg_add_lines(insert_space, lnum, nchars)


if (shortmess(SHM_LINES))
sprintf((char *)p,
#ifdef LONG_LONG_OFF_T
- "%ldL, %lldC",

+ "%ldL, %lldC", lnum, nchars

#else
- "%ldL, %ldC",
+ /* Explicit typecast avoids warning on Mac OS X 10.6 */


+ "%ldL, %ldC", lnum, (long)nchars

#endif
- lnum, nchars);
+ );


else
{
if (lnum == 1)

@@ -5246,11 +5247,12 @@ msg_add_lines(insert_space, lnum, nchars)


else
sprintf((char *)p,
#ifdef LONG_LONG_OFF_T
- _("%lld characters"),

+ _("%lld characters"), nchars

#else
- _("%ld characters"),

+ /* Explicit typecast avoids warning on Mac OS X 10.6 */


+ _("%ld characters"), (long)nchars

#endif
- nchars);
+ );
}
}

björn

unread,
Jun 10, 2010, 12:40:29 PM6/10/10
to vim...@googlegroups.com
On 9 June 2010 17:10, James Vega wrote:

> On Wed, Jun 9, 2010 at 4:41 AM, björn wrote:
>> On 8 June 2010 23:05, James Vega wrote:
>>> On Sun, Jun 6, 2010 at 1:42 PM, björn wrote:
>>>
>>>> My config.log looks like this:
>>>>
>>>> configure:11865: checking for off_t
>>>> configure:11895: gcc -c -O2 -fno-strength-reduce -Wall  -DMACOS_X_UNIX
>>>> -no-cpp-precomp conftest.c >&5
>>>> configure:11901: $? = 0
>>>> configure:11916: result: yes
>>>>
>>>> It seems that it never even tries to figure out the proper size.
>>>
>>> That's the only occurence of off_t?  The size checking is performed much
>>> later than checking for the existence of off_t.
>>
>> Yes, that is the only occurrence of off_t.  But...it seems the problem
>> stems from the fact I use autoconf 2.61 to generate src/configure (I
>> have to generate this file since my configure.in contains
>> modifications for MacVim).  See my previous post in reply to Tony.
>
> That's odd.  The AC_CHECK_SIZEOF macro has been in Autoconf since 2.50.
> I just tested on Debian Etch (since that has Autoconf 2.61) and
> running "make autoconf" generates a configure that detects off_t size.

Reading this I decided to try running "autoconf" followed by "make
autoconf" and now off_t is detected properly(!). I have no idea why
it did not work earlier (I did run those two commands earlier, but
perhaps not one after the other in that order)...

This makes me wonder: What is the correct incantation for generating
the configure scripts after I've modified src/configure.in? Both
"autoconf" and "make autoconf"? (The Makefile makes it sound like the
latter should be enough but that does not pick up on changes to
configure.in.)

Björn

James Vega

unread,
Jun 10, 2010, 1:12:38 PM6/10/10
to vim...@googlegroups.com

"make autoconf" from the src directory has always worked for me. That's
how I tested recent patches I sent which did touch configure.in.

There's no need to run autoconf manually and doing so will cause some
files which configure generates to be placed in src/ instead of
src/auto/.

Bram Moolenaar

unread,
Jun 12, 2010, 12:43:55 AM6/12/10
to björn, vim...@googlegroups.com

Björn Winckler wrote:

> 2010/6/9 Dominique Pellé:
> > björn wrote:
> >
> >> $ gcc --version
> >> i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5659)
> >>
> >> All I can say is that if you want to print an off_t value on OS X 10.6
> >> then "%lld" must be used or that warning pops up.
> >>
> >> Since those two lines in fileio.c are the only places where an off_t
> >> is printed I may just go ahead and add some MacVim-specific #ifdefs to
> >> get rid of the warning in the MacVim code, unless some other solution
> >> presents itself. I might also try some Apple-specific mailing list to
> >> see if I can get any answers there about this warning.
> >
> > How about putting a cast to long as follows? If LONG_LONG_OFF_T
> > is undefined, then casting off_t to long does not lose precision
> > and should fix the compilation warning:
>
> Thanks Dominique, that seems like a clever trick to me. I just tried
> it and it works fine (the warning goes away).
>
> I also made a little test program to print a 64 bit int using %ld as
> well as %lld and both give the same result (so this patch works
> properly).
>
> I modified the patch slightly by moving the final parenthesis outside
> the #ifdef and added a comment (see below). Bram: would you merge
> this into the Vim code or would you rather I just apply it to the
> MacVim code?

I'll include it, thanks.

--
hundred-and-one symptoms of being an internet addict:
188. You purchase a laptop so you can surf while sitting on the can.

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ download, build and distribute -- http://www.A-A-P.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

Reply all
Reply to author
Forward
0 new messages