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.

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.

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

-- 
-- 
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

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/vim_dev/202002252027.01PKRHGc006783%40masaka.moolenaar.net.

Raspunde prin e-mail lui