From: Oliver Kiddle <okiddle@yahoo.co.uk>
To: Tomi.Vainio@Sun.COM
Cc: zsh-workers@sunsite.dk, Stephane CHAZELAS <Stephane_CHAZELAS@yahoo.fr>
Subject: Re: 4.1.1 doesn't compile
Date: Tue, 24 Jun 2003 17:29:08 +0200 [thread overview]
Message-ID: <13714.1056468548@gmcs3.local> (raw)
In-Reply-To: <16120.21181.974421.168422@ultrahot.finland.sun.com>
Tomi Vainio - Sun Finland wrote:
> Minor problem compiling latest zsh. 64bit compilation fails but 32bit
> still works.
Thanks for reporting this. I can reproduce it.
> ***64bit***
> cc -c -I. -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DHAVE_CONFIG_H -DMODULE -xO4 -xarch=v9 -KPIC -o terminfo..o terminfo.c
> "terminfo.c", line 110: warning: argument #3 is incompatible with prototype:
> prototype: pointer to function(char) returning int : "/usr/include/term.h", line 1205
> argument : pointer to function(int) returning int
This is only a warning but does anyone know if we could safely use
putp() instead of tputs() to avoid it (prototype for tputs seems to be
subtly different between Solaris and Linux)?
> "terminfo.c", line 113: prototype mismatch: 2 args passed, 10 expected
This is the error. The reason why it fails for 64-bit but not 32-bit
probably has something to do with this section of term.h:
#if defined(_XPG4_2) || defined(_LP64) || defined(__cplusplus)
extern char
*tparm(char *, long, long, long, long, long, long, long, long, long);
#else
/* this is wrong, but is needed for historical reasons */
extern char *tparm();
#endif
As you can see, Solaris' tparm() prototype wants there to be 9
parameters (10 arguments).
This is the same chunk of code that Stephane Chazelas was complaining
about in 18544. Reading back over that, what Stephane says makes a lot
of sense and the code is clearly badly broken. It only ever passes one
parameter. If you look at the output of `echoti cup 5 10|od -t c', the
second parameter is defaulting to something big.
On the question of how to determine if parameters should be integer or
string, it might work to just treat them all as strings. They are just
converted back to strings for the escape sequence anyway. It'll need a
bit of experimenting.
For the moment, the following quick patch will allow compilation on
Solaris to at least not fail.
Oliver
--- terminfo.c.bak 2003-06-24 15:17:22.333407000 +0000
+++ terminfo.c 2003-06-24 15:21:52.103550000 +0000
@@ -110,7 +110,7 @@
tputs(t, 1, putraw);
else {
num = (argv[1]) ? atoi(argv[1]) : atoi(*argv);
- tputs(tparm(t, atoi(*argv)), num, putraw);
+ tputs(tparm(t, atoi(*argv), 0, 0, 0, 0, 0, 0, 0, 0), num, putraw);
}
return 0;
________________________________________________________________________
This email has been scanned for all viruses by the MessageLabs Email
Security System. For more information on a proactive email security
service working around the clock, around the globe, visit
http://www.messagelabs.com
________________________________________________________________________
next prev parent reply other threads:[~2003-06-24 15:36 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-06-24 13:31 Tomi Vainio - Sun Finland
2003-06-24 15:29 ` Oliver Kiddle [this message]
2003-06-25 8:20 ` Tomi Vainio - Sun Finland
2003-06-25 9:48 ` Oliver Kiddle
2003-06-25 11:58 ` Tomi Vainio - Sun Finland
2003-06-25 13:04 ` Tomi Vainio - Sun Finland
2003-06-25 13:45 ` Oliver Kiddle
2003-06-25 16:32 ` Bart Schaefer
2003-06-26 11:23 ` Zefram
2003-06-27 11:08 ` Tomi Vainio - Sun Finland
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=13714.1056468548@gmcs3.local \
--to=okiddle@yahoo.co.uk \
--cc=Stephane_CHAZELAS@yahoo.fr \
--cc=Tomi.Vainio@Sun.COM \
--cc=zsh-workers@sunsite.dk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).