Buffer write message is incorrect (take 2)

[John Marriott]

Hi All,

I have just applied a bunch of patches to my HP-UX (non-gui) build to bring it up to 8.2.0292 and noticed that the message that is displayed when a buffer is written isn't right.

For example (note the number of chars):


My Win64 build looks ok:


Here is output of ':ver' of the HP-UX build:
:ver
VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Feb 21 2020 09:56:41)
Included patches: 1-292
Compiled by John
Normal version without GUI.  Features included (+) or not (-):
+acl               +cursorbind        +insert_expand +mouse_sgr         -ruby              -title
-arabic            -cursorshape       -job -mouse_sysmouse    +scrollbind        -toolbar
+autocmd           +dialog_con        +jumplist -mouse_urxvt       -signs             +user_commands
-autochdir         +diff              -keymap +mouse_xterm       -smartindent       -vartabs
-autoservername    -digraphs          +lambda +multi_byte        -sound             +vertsplit
-balloon_eval      -dnd               -langmap -multi_lang        -spell             +virtualedit
-balloon_eval_term -ebcdic            +libcall -mzscheme          -startuptime       +visual
-browse            -emacs_tags        +linebreak -netbeans_intg     +statusline        +visualextra
+builtin_terms     +eval              -lispindent +num64             -sun_workshop      -viminfo
+byte_offset       +ex_extra          +listcmds +packages          +syntax            +vreplace
-channel           +extra_search      +localmap -path_extra        +tag_binary        +wildignore
+cindent           -farsi             -lua -perl              -tag_old_static    +wildmenu
-clientserver      +file_in_path      -menu -persistent_undo   -tag_any_white     +windows
-clipboard         +find_in_path      -mksession -popupwin          -tcl               +writebackup
+cmdline_compl     -float             +modify_fname -printer           -termguicolors     -X11
+cmdline_hist      -folding           +mouse -profile           -terminal          -xfontset
+cmdline_info      -footer            -mouseshape -python            +terminfo          -xim
+comments          +fork()            -mouse_dec -python3           -termresponse      -xpm
-conceal           -gettext           -mouse_gpm -quickfix          +textobjects       -xsmp
-cryptv            -hangul_input      -mouse_jsbterm -reltime           -textprop          -xterm_clipboard
-cscope            -iconv             -mouse_netterm -rightleft         -timers            -xterm_save
   system vimrc file: "$VIM/vimrc"
     user vimrc file: "$HOME/.vimrc"
 2nd user vimrc file: "~/.vim/vimrc"
      user exrc file: "$HOME/.exrc"
       defaults file: "$VIMRUNTIME/defaults.vim"
  fall-back for $VIM: "/usr/local/share/vim"
Compilation: cc -c -I. -Iproto -DHAVE_CONFIG_H     -O2 -D_REENTRANT
Linking: cc   -L/usr/local/lib -o vim               -lm -ltermlib

I'm not sure which patch caused this.

Cheers
John

[Ken Takata]

Hi,

Maybe 8.2.0271 causes it.

Does the HP-UX compiler supports 64-bit integer?

Regards,

Ken Takata

[Bram Moolenaar]

John Marriott wrote:

> I have just applied a bunch of patches to my HP-UX (non-gui) build to
> bring it up to 8.2.0292 and noticed that the message that is displayed
> when a buffer is written isn't right.
>
> For example (note the number of chars):

Try changing the format in msg_add_lines().

Hmm, the problem may be in vim_strnprintf(), it uses "varnumber_T",
which is __int64, while the argument is "long long". But some systems
don't define "long long" and then it might go wrong.

Let's just use varnumber_T for "%lld", then we can drop long_long_T.
Hmm, but then the compiler complains for using "%lld" for an int64_t
argument.

Since we do want to use "%lld" and must have the type equal to
varnumber_T, the only sensible solution is to make varnumber_T "long
long". I assume this will be 64 bit in most places anyway.

--
From "know your smileys":
[:-) Frankenstein's monster

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[John Marriott]

On 23-Feb-2020 00:19, Bram Moolenaar wrote:
> John Marriott wrote:
>
>> I have just applied a bunch of patches to my HP-UX (non-gui) build to
>> bring it up to 8.2.0292 and noticed that the message that is displayed
>> when a buffer is written isn't right.
>>
>> For example (note the number of chars):
> Try changing the format in msg_add_lines().
>
> Hmm, the problem may be in vim_strnprintf(), it uses "varnumber_T",
> which is __int64, while the argument is "long long". But some systems
> don't define "long long" and then it might go wrong.
>
> Let's just use varnumber_T for "%lld", then we can drop long_long_T.
> Hmm, but then the compiler complains for using "%lld" for an int64_t
> argument.
>
> Since we do want to use "%lld" and must have the type equal to
> varnumber_T, the only sensible solution is to make varnumber_T "long
> long". I assume this will be 64 bit in most places anyway.
>

I tried changing the message format for the number of chars in
msg_add_lines() to "%ld" and this corrected the problem.

I reverted that and applied the patches up to 8.2.0311 to my HP-UX build
which yielded this error:
<snip>
    cc -c -I. -Iproto -DHAVE_CONFIG_H     -O2       -D_REENTRANT -o
objects/eval.o eval.c
cc: "eval.c", line 76: error 1588: "LLONG_MIN" undefined.
cc: "eval.c", line 78: error 1588: "LLONG_MAX" undefined.
cc: "eval.c", line 78: error 1557: Unary minus takes an arithmetic operand.
*** Error exit code 1

Stop.
*** Error exit code 1

Stop.
*** Error exit code 1

Stop.
</snip>

It seems that HP-UX does not define LLONG_MAX and LLONG_MIN. However
both HP-UX and mingw define LONG_LONG_MIN/MAX which have the same value.
So the first patch (structs.h.8.2.0311.patch) changes them to that.

After that, I get this error:
<snip>
    cc -c -I. -Iproto -DHAVE_CONFIG_H     -O2       -D_REENTRANT -o
objects/json.o json.c
cc: "json.c", line 197: error 1654: Expression type is too large for
switch expression.
cc: "json.c", line 199: error 1653: Case label too big for the type of
the switch expression
cc: "json.c", line 200: error 1653: Case label too big for the type of
the switch expression
cc: "json.c", line 205: error 1654: Expression type is too large for
switch expression.
cc: "json.c", line 207: error 1653: Case label too big for the type of
the switch expression
cc: "json.c", line 212: error 1653: Case label too big for the type of
the switch expression
*** Error exit code 1

Stop.
*** Error exit code 1

Stop.
</snip>

The second patch (json.c.8.2.0311.patch) tries to fix that. This one I'm
not sure about. Perhaps it would be better as 'if' statements.

Anyhow, with these patches, it seems to work ok on HP-UX and mingw, and
the buffer write message problem is fixed as well.

Cheers
John

[Bram Moolenaar]

Other systems don't have the LONG_LONG ones, I'll add an #ifdef to use
one or the other.

> After that, I get this error:
> <snip>
>     cc -c -I. -Iproto -DHAVE_CONFIG_H     -O2       -D_REENTRANT -o
> objects/json.o json.c
> cc: "json.c", line 197: error 1654: Expression type is too large for
> switch expression.
> cc: "json.c", line 199: error 1653: Case label too big for the type of
> the switch expression
> cc: "json.c", line 200: error 1653: Case label too big for the type of
> the switch expression
> cc: "json.c", line 205: error 1654: Expression type is too large for
> switch expression.
> cc: "json.c", line 207: error 1653: Case label too big for the type of
> the switch expression
> cc: "json.c", line 212: error 1653: Case label too big for the type of
> the switch expression
> *** Error exit code 1
>
> Stop.
> *** Error exit code 1
>
> Stop.
> </snip>
>
> The second patch (json.c.8.2.0311.patch) tries to fix that. This one I'm
> not sure about. Perhaps it would be better as 'if' statements.

Should be OK, since the values are type long.

> Anyhow, with these patches, it seems to work ok on HP-UX and mingw, and
> the buffer write message problem is fixed as well.

I'll send out the patch.

--
Amnesia is one of my favorite words, but I forgot what it means.