[Patch] Use off_t for tracking buffer size

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

[Patch] Use off_t for tracking buffer size

James Vega-3
Since Vim can now open “largefiles” on 32-bit systems, there are some
changes necessary to properly store/access the size of those files.
This is easy to see as when you open a largefile, the status message
showing the number of lines and characters in the file will have a
negative number of characters for largefiles since the 32-bit long was
overflowed.

The attached patch (generated against 7d3cf4693a8f) changes the relevant
buffer size pieces of the code to use off_t instead of long.
Unfortunately, there isn't a standard way to format off_t for
printf-style functions, so that required some preprocessor checks for
what to use.  There may be a better way to do that, but it worked for
me.

I've tested this on Windows with VS Express 2008 and Linux (both 32-bit
and 64-bit environments).

--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega <[hidden email]>

largefile+off_t.diff (7K) Download Attachment
signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Patch] Use off_t for tracking buffer size

Bram Moolenaar

James -

> Since Vim can now open “largefiles† on 32-bit systems, there are some
> changes necessary to properly store/access the size of those files.
> This is easy to see as when you open a largefile, the status message
> showing the number of lines and characters in the file will have a
> negative number of characters for largefiles since the 32-bit long was
> overflowed.
>
> The attached patch (generated against 7d3cf4693a8f) changes the relevant
> buffer size pieces of the code to use off_t instead of long.
> Unfortunately, there isn't a standard way to format off_t for
> printf-style functions, so that required some preprocessor checks for
> what to use.  There may be a better way to do that, but it worked for
> me.
>
> I've tested this on Windows with VS Express 2008 and Linux (both 32-bit
> and 64-bit environments).

Thanks!  I'll put it on my 7.3 todo list.

- Bram

--
You can't have everything.  Where would you put it?
                -- Steven Wright

 /// Bram Moolenaar -- [hidden email] -- 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    ///

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: [Patch] Use off_t for tracking buffer size

Dominique Pellé
In reply to this post by James Vega-3
James Vega wrote:

> Since Vim can now open “largefiles” on 32-bit systems, there are some
> changes necessary to properly store/access the size of those files.
> This is easy to see as when you open a largefile, the status message
> showing the number of lines and characters in the file will have a
> negative number of characters for largefiles since the 32-bit long was
> overflowed.
>
> The attached patch (generated against 7d3cf4693a8f) changes the relevant
> buffer size pieces of the code to use off_t instead of long.
> Unfortunately, there isn't a standard way to format off_t for
> printf-style functions, so that required some preprocessor checks for
> what to use.  There may be a better way to do that, but it worked for
> me.
>
> I've tested this on Windows with VS Express 2008 and Linux (both 32-bit
> and 64-bit environments).


Hi James

This chunk...

@@ -5062,7 +5062,7 @@
        if (nchars == 1)
            STRCPY(p, _("1 character"));
        else
-           sprintf((char *)p, _("%ld characters"), nchars);
+           sprintf((char *)p, _(PRINTF_OFF_T" characters"), nchars);
     }
 }

Changes the translated string in src/po/??.po files from:

  #, c-format
  msgid "%ld characters"

... into:

  #, c-format
  msgid " characters"

Notice that the %ld has disappeared in the po file. Isn't it an issue?

Perhaps we should do it the less elegant way:

        if (nchars == 1)
            STRCPY(p, _("1 character"));
        else
            /* Can't use PRINTF_OFF_T here without confusing gettext */
#if defined(SIZEOF_OFF_T) && (SIZEOF_OFF_T > SIZEOF_LONG)
           sprintf((char *)p, _("%lld characters"), nchars);
#else
           sprintf((char *)p, _("%ld characters"), nchars);
#endif

-- Dominique

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: [Patch] Use off_t for tracking buffer size

Dominique Pellé
2010/5/23 Dominique Pellé <[hidden email]>:

> James Vega wrote:
>
>> Since Vim can now open “largefiles” on 32-bit systems, there are some
>> changes necessary to properly store/access the size of those files.
>> This is easy to see as when you open a largefile, the status message
>> showing the number of lines and characters in the file will have a
>> negative number of characters for largefiles since the 32-bit long was
>> overflowed.
>>
>> The attached patch (generated against 7d3cf4693a8f) changes the relevant
>> buffer size pieces of the code to use off_t instead of long.
>> Unfortunately, there isn't a standard way to format off_t for
>> printf-style functions, so that required some preprocessor checks for
>> what to use.  There may be a better way to do that, but it worked for
>> me.
>>
>> I've tested this on Windows with VS Express 2008 and Linux (both 32-bit
>> and 64-bit environments).
>
>
> Hi James
>
> This chunk...
>
> @@ -5062,7 +5062,7 @@
>        if (nchars == 1)
>            STRCPY(p, _("1 character"));
>        else
> -           sprintf((char *)p, _("%ld characters"), nchars);
> +           sprintf((char *)p, _(PRINTF_OFF_T" characters"), nchars);
>     }
>  }
>
> Changes the translated string in src/po/??.po files from:
>
>  #, c-format
>  msgid "%ld characters"
>
> ... into:
>
>  #, c-format
>  msgid " characters"
>
> Notice that the %ld has disappeared in the po file. Isn't it an issue?
>
> Perhaps we should do it the less elegant way:
>
>        if (nchars == 1)
>            STRCPY(p, _("1 character"));
>        else
>            /* Can't use PRINTF_OFF_T here without confusing gettext */
> #if defined(SIZEOF_OFF_T) && (SIZEOF_OFF_T > SIZEOF_LONG)
>           sprintf((char *)p, _("%lld characters"), nchars);
> #else
>           sprintf((char *)p, _("%ld characters"), nchars);
> #endif
>
> -- Dominique


I notice that Vim translations do not use the plural forms of
gettext.  Distinguishing between singular and plural as in...

        if (nchars == 1)
            STRCPY(p, _("1 character"));
        else
            sprintf((char *)p, _("%ld characters"), nchars);

... works fine for English and for many other languages but not for
all languages.
For example:
- Polish has 5 different plural forms.
- Even French and English have slightly different rules for plurals: 0
is plural in
  English but singular in French.
- In Breton and Welsh, the first letter of a word may mutate
differently depending
  on the number on front of it.
- etc.

So is there any reason for not using gettext plural forms which would allow
better translations?  See:

http://www.gnu.org/software/gettext/manual/gettext.html#Plural-forms
http://www.gnu.org/software/gettext/manual/gettext.html#Translating-plural-forms

-- Dominique

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: [Patch] Use off_t for tracking buffer size

Lech Lorens
In reply to this post by Dominique Pellé
On 23-May-2010 Dominique Pellé <[hidden email]> wrote:

> James Vega wrote:
>
> > Since Vim can now open “largefiles” on 32-bit systems, there are some
> > changes necessary to properly store/access the size of those files.
> > This is easy to see as when you open a largefile, the status message
> > showing the number of lines and characters in the file will have a
> > negative number of characters for largefiles since the 32-bit long was
> > overflowed.
> >
> > The attached patch (generated against 7d3cf4693a8f) changes the relevant
> > buffer size pieces of the code to use off_t instead of long.
> > Unfortunately, there isn't a standard way to format off_t for
> > printf-style functions, so that required some preprocessor checks for
> > what to use.  There may be a better way to do that, but it worked for
> > me.
> >
> > I've tested this on Windows with VS Express 2008 and Linux (both 32-bit
> > and 64-bit environments).
>
>
> Hi James
>
> This chunk...
>
> @@ -5062,7 +5062,7 @@
>         if (nchars == 1)
>             STRCPY(p, _("1 character"));
>         else
> -           sprintf((char *)p, _("%ld characters"), nchars);
> +           sprintf((char *)p, _(PRINTF_OFF_T" characters"), nchars);
>      }
>  }
>
> Changes the translated string in src/po/??.po files from:
>
>   #, c-format
>   msgid "%ld characters"
>
> ... into:
>
>   #, c-format
>
> Notice that the %ld has disappeared in the po file. Isn't it an issue?
>   msgid " characters"

I don't think there is such a problem - «PRINTF_OFF_T" characters"»
becomes a single string before the call to _() takes place. This string
can either be:
- "%ld characters"
or
- "%lld characters"
This means, there are now two versions of the translated text possible
which should be taken into account.

The problem with this patch that I notice is a warning from gcc:

gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_ATHENA     -g -O2 -D_FORTIFY_SOURCE=1          -o objects/fileio.o fileio.c
fileio.c: In function ‘msg_add_lines’:
fileio.c:5054: warning: format ‘%ld’ expects type ‘long int’, but argument 4 has type ‘off_t’
fileio.c:5065: warning: format ‘%ld’ expects type ‘long int’, but argument 3 has type ‘off_t’

--
Cheers,
Lech

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: [Patch] Use off_t for tracking buffer size

James Vega-3
On Sun, May 23, 2010 at 02:04:06PM +0200, Lech Lorens wrote:
> The problem with this patch that I notice is a warning from gcc:
>
> gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_ATHENA     -g -O2 -D_FORTIFY_SOURCE=1          -o objects/fileio.o fileio.c
> fileio.c: In function ‘msg_add_lines’:
> fileio.c:5054: warning: format ‘%ld’ expects type ‘long int’, but argument 4 has type ‘off_t’
> fileio.c:5065: warning: format ‘%ld’ expects type ‘long int’, but argument 3 has type ‘off_t’

I hadn't seen that on the systems I tested with.  What GCC version and
what does “grep SIZEOF_ src/auto/config.h” say?

--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega <[hidden email]>

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Patch] Use off_t for tracking buffer size

Lech Lorens
On 23-May-2010 James Vega <[hidden email]> wrote:
> I hadn't seen that on the systems I tested with.  What GCC version and
> what does “grep SIZEOF_ src/auto/config.h” say?

$ gcc --version
gcc (Ubuntu 4.4.1-4ubuntu9) 4.4.1
Copyright (C) 2009 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ grep SIZEOF_ src/auto/config.h
#define SIZEOF_INT 4
/* #undef SIZEOF_OFF_T */
/* #undef SIZEOF_LONG */

Thanks!

--
Cheers,
Lech

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: [Patch] Use off_t for tracking buffer size

James Vega-3
On Sun, May 23, 2010 at 03:16:13PM +0200, Lech Lorens wrote:

> On 23-May-2010 James Vega <[hidden email]> wrote:
> > I hadn't seen that on the systems I tested with.  What GCC version and
> > what does “grep SIZEOF_ src/auto/config.h” say?
>
> $ gcc --version
> gcc (Ubuntu 4.4.1-4ubuntu9) 4.4.1
> Copyright (C) 2009 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> $ grep SIZEOF_ src/auto/config.h
> #define SIZEOF_INT 4
> /* #undef SIZEOF_OFF_T */
> /* #undef SIZEOF_LONG */
Ok, that's what I thought.  My patch only updated src/configure.in since
src/auto/configure is a generated file.  You'll want to have autoconf
installed and run “make -C src autoconf” to generate a new configure
from the updated configure.in.  Then a new build should work.

--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega <[hidden email]>

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Patch] Use off_t for tracking buffer size

Lech Lorens
On 23-May-2010 James Vega <[hidden email]> wrote:
> > $ grep SIZEOF_ src/auto/config.h
> > #define SIZEOF_INT 4
> > /* #undef SIZEOF_OFF_T */
> > /* #undef SIZEOF_LONG */
>
> Ok, that's what I thought.  My patch only updated src/configure.in since
> src/auto/configure is a generated file.  You'll want to have autoconf
> installed and run “make -C src autoconf” to generate a new configure
> from the updated configure.in.  Then a new build should work.

Indeed, the warning disappears and now Vim compiles cleanly.
Thank you!

--
Cheers,
Lech

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: [Patch] Use off_t for tracking buffer size

Dominique Pellé
In reply to this post by Lech Lorens
Lech Lorens <[hidden email]>:

> On 23-May-2010 Dominique Pellé <[hidden email]> wrote:
>> James Vega wrote:
>>
>> > Since Vim can now open “largefiles” on 32-bit systems, there are some
>> > changes necessary to properly store/access the size of those files.
>> > This is easy to see as when you open a largefile, the status message
>> > showing the number of lines and characters in the file will have a
>> > negative number of characters for largefiles since the 32-bit long was
>> > overflowed.
>> >
>> > The attached patch (generated against 7d3cf4693a8f) changes the relevant
>> > buffer size pieces of the code to use off_t instead of long.
>> > Unfortunately, there isn't a standard way to format off_t for
>> > printf-style functions, so that required some preprocessor checks for
>> > what to use.  There may be a better way to do that, but it worked for
>> > me.
>> >
>> > I've tested this on Windows with VS Express 2008 and Linux (both 32-bit
>> > and 64-bit environments).
>>
>>
>> Hi James
>>
>> This chunk...
>>
>> @@ -5062,7 +5062,7 @@
>>         if (nchars == 1)
>>             STRCPY(p, _("1 character"));
>>         else
>> -           sprintf((char *)p, _("%ld characters"), nchars);
>> +           sprintf((char *)p, _(PRINTF_OFF_T" characters"), nchars);
>>      }
>>  }
>>
>> Changes the translated string in src/po/??.po files from:
>>
>>   #, c-format
>>   msgid "%ld characters"
>>
>> ... into:
>>
>>   #, c-format
>>
>> Notice that the %ld has disappeared in the po file. Isn't it an issue?
>>   msgid " characters"
>
> I don't think there is such a problem - «PRINTF_OFF_T" characters"»
> becomes a single string before the call to _() takes place. This string
> can either be:
> - "%ld characters"
> or
> - "%lld characters"
> This means, there are now two versions of the translated text possible
> which should be taken into account.

I still think it is a problem: at runtime, gettext() will be called with:
- gettext("%ld characters")
- or gettext("%lld characters")

However, the generated po file (generated with for example  cd src/po ; make fr)
only contains the string " characters" after this patch.  So gettext()
won't find the
translation and the English message will be displayed instead.

To confirm it, I just tried this:

$ cd vim/src

# Re-generate French po file
$ (cd src/po ; make fr)

# Rebuild vim & reinstall it (to install the translations)
$  make
$  make install

# Configure to see French translation for example:
$ export LANG=fr_FR.UTF-8

Now when I save a file with  :saveas! foo  I see the message only
partially translated (bug!):

"foo" 1 ligne, 4 characters écrit(s)

Notice the English word *characters* which did not get translated.
Before patch, I could see:

"foo" 1 ligne, 4 caractères écrit(s)


> The problem with this patch that I notice is a warning from gcc:
>
> gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_ATHENA     -g -O2 -D_FORTIFY_SOURCE=1          -o objects/fileio.o fileio.c
> fileio.c: In function ‘msg_add_lines’:
> fileio.c:5054: warning: format ‘%ld’ expects type ‘long int’, but argument 4 has type ‘off_t’
> fileio.c:5065: warning: format ‘%ld’ expects type ‘long int’, but argument 3 has type ‘off_t’

Yes, that's another problem. The idea of PRINTF_OFF_T was precisely
to avoid this kind of warning. But I also see the same warning on my laptop
(Ubuntu-9.10, gcc-4.4.1).

When using gcc, PRINTF_OFF_T should be defined to %zd to print
a off_t or a size_t type without warning.  Configure script should check that
%zd works.

See:
http://stackoverflow.com/questions/586928/how-should-i-print-types-like-off-t-and-size-t

PRINTF_OFF_T is currently defined on my machine as %ld because
SIZEOF_OFF_T is not defined.

-- Dominique

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: [Patch] Use off_t for tracking buffer size

Lech Lorens
On 23-May-2010 Dominique Pellé <[hidden email]> wrote:

> I still think it is a problem: at runtime, gettext() will be called with:
> - gettext("%ld characters")
> - or gettext("%lld characters")
>
> However, the generated po file (generated with for example  cd src/po ; make fr)
> only contains the string " characters" after this patch.  So gettext()
> won't find the
> translation and the English message will be displayed instead.
>
> To confirm it, I just tried this:
>
> $ cd vim/src
>
> # Re-generate French po file
> $ (cd src/po ; make fr)
>
> # Rebuild vim & reinstall it (to install the translations)
> $  make
> $  make install
>
> # Configure to see French translation for example:
> $ export LANG=fr_FR.UTF-8
>
> Now when I save a file with  :saveas! foo  I see the message only
> partially translated (bug!):
>
> "foo" 1 ligne, 4 characters écrit(s)
>
> Notice the English word *characters* which did not get translated.
> Before patch, I could see:
>
> "foo" 1 ligne, 4 caractères écrit(s)

OK, I confirm the problem. I had no idea I should have rebuilt the po
files. Sorry!

I too get a partial translation in Polish:
"/tmp/foo" 112 wierszy, 3067 characters zapisano
versus
"/tmp/foo" 112 wierszy, 3067 znaków zapisano

--
Cheers,
Lech

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: [Patch] Use off_t for tracking buffer size

James Vega-3
In reply to this post by Dominique Pellé
On Sun, May 23, 2010 at 06:02:27PM +0200, Dominique Pellé wrote:

> Lech Lorens <[hidden email]>:
>
> > On 23-May-2010 Dominique Pellé <[hidden email]> wrote:
> >> This chunk...
> >>
> >> @@ -5062,7 +5062,7 @@
> >>         if (nchars == 1)
> >>             STRCPY(p, _("1 character"));
> >>         else
> >> -           sprintf((char *)p, _("%ld characters"), nchars);
> >> +           sprintf((char *)p, _(PRINTF_OFF_T" characters"), nchars);
> >>      }
> >>  }
> >>
> >> Changes the translated string in src/po/??.po files from:
> >>
> >>   #, c-format
> >>   msgid "%ld characters"
> >>
> >> ... into:
> >>
> >>   #, c-format
> >>
> >> Notice that the %ld has disappeared in the po file. Isn't it an issue?
> >>   msgid " characters"
Yes.  Attached patch fixes this, although updated translations will still be
needed for 32-bit systems using 64-bit off_t.

Switching to ngettext for the plural forms looks a bit unwieldy given the way
Vim uses gettext.  See the #defines in src/vim.h for handling building without
gettext or with gettext as a noop.

> > The problem with this patch that I notice is a warning from gcc:
> >
> > gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_ATHENA     -g -O2 -D_FORTIFY_SOURCE=1          -o objects/fileio.o fileio.c
> > fileio.c: In function ‘msg_add_lines’:
> > fileio.c:5054: warning: format ‘%ld’ expects type ‘long int’, but argument 4 has type ‘off_t’
> > fileio.c:5065: warning: format ‘%ld’ expects type ‘long int’, but argument 3 has type ‘off_t’
>
> Yes, that's another problem. The idea of PRINTF_OFF_T was precisely
> to avoid this kind of warning. But I also see the same warning on my laptop
> (Ubuntu-9.10, gcc-4.4.1).
>
> When using gcc, PRINTF_OFF_T should be defined to %zd to print
> a off_t or a size_t type without warning.  Configure script should check that
> %zd works.
This is because you haven't regenerated configure, as I pointed out in a
reply to Lech.  %zd won't work because that's for size_t, which is not
the same as off_t.

  $ cat foo.c
  #include <unistd.h>
  #include <sys/types.h>
  #include <stdio.h>

  int main(int argc, char **argv)
  {
      printf("size_t: %d off_t: %d\n", sizeof(size_t), sizeof(off_t));
      return 0;
  }
  $ gcc -o foo foo.c
  $ ./foo
  size_t: 4 off_t: 4
  $ gcc -o foo -D_FILE_OFFSET_BITS=64 foo.c
  $ ./foo
  size_t: 4 off_t: 8

--
James
GPG Key: 1024D/61326D40 2003-09-02 James Vega <[hidden email]>

largefile+off_t.diff (7K) Download Attachment
signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Patch] Use off_t for tracking buffer size

Bram Moolenaar
In reply to this post by Lech Lorens

Lech Lorens wrote:

> On 23-May-2010 Dominique Pellé <[hidden email]> wrote:
> > James Vega wrote:
> >
> > > Since Vim can now open “largefiles† on 32-bit systems, there are some
> > > changes necessary to properly store/access the size of those files.
> > > This is easy to see as when you open a largefile, the status message
> > > showing the number of lines and characters in the file will have a
> > > negative number of characters for largefiles since the 32-bit long was
> > > overflowed.
> > >
> > > The attached patch (generated against 7d3cf4693a8f) changes the relevant
> > > buffer size pieces of the code to use off_t instead of long.
> > > Unfortunately, there isn't a standard way to format off_t for
> > > printf-style functions, so that required some preprocessor checks for
> > > what to use. Â There may be a better way to do that, but it worked for
> > > me.
> > >
> > > I've tested this on Windows with VS Express 2008 and Linux (both 32-bit
> > > and 64-bit environments).
> >
> >
> > Hi James
> >
> > This chunk...
> >
> > @@ -5062,7 +5062,7 @@
> >         if (nchars == 1)
> >             STRCPY(p, _("1 character"));
> >         else
> > -           sprintf((char *)p, _("%ld characters"), nchars);
> > +           sprintf((char *)p, _(PRINTF_OFF_T" characters"), nchars);
> >      }
> >  }
> >
> > Changes the translated string in src/po/??.po files from:
> >
> >   #, c-format
> >   msgid "%ld characters"
> >
> > ... into:
> >
> >   #, c-format
> >
> > Notice that the %ld has disappeared in the po file. Isn't it an issue?
> >   msgid " characters"
>
> I don't think there is such a problem - «PRINTF_OFF_T" characters"»
> becomes a single string before the call to _() takes place. This string
> can either be:
> - "%ld characters"
> or
> - "%lld characters"
> This means, there are now two versions of the translated text possible
> which should be taken into account.

This only works for modern compilers.  Older compilers don't have this
kind of compile-time string concatenation.  Therefore we don't use it in
the Vim source code.

--
From "know your smileys":
 :-X My lips are sealed

 /// Bram Moolenaar -- [hidden email] -- 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    ///

--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php