4.1.1 doesn't compile

4.1.1 doesn't compile

[Tomi Vainio - Sun Finland]

Hi,

Minor problem compiling latest zsh.  64bit compilation fails but 32bit
still works.

Compiler is Sun ONE Studio 8, Compiler Collection
	    cc: Sun C 5.5 Patch 112760-01 2003/05/18 

***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
"terminfo.c", line 113: prototype mismatch: 2 args passed, 10 expected
"terminfo.c", line 113: 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
cc: acomp failed for terminfo.c
*** Error code 2
make: Fatal error: Command failed for target `terminfo..o'

***32bit***
cc -c -I. -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DHAVE_CONFIG_H -DMODULE -xO4 -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
"terminfo.c", line 113: 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

-- 
SUN Microsystems Oy PL 112, Lars Sonckin kaari 12, 02601 ESPOO, Finland
Tomi Vainio (System Support Engineer)     +358 9 52556300 hotline
email: Tomi.Vainio@Sun.COM                +358 9 52556252 fax

Re: 4.1.1 doesn't compile

[Oliver Kiddle]

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
________________________________________________________________________

Re: 4.1.1 doesn't compile

[Tomi Vainio - Sun Finland]

I also found another problem but this time only when I try to compile
32bit binary.

Compiler is Sun ONE Studio 8, Compiler Collection
            cc: Sun C 5.5 Patch 112760-01 2003/05/18 

cc -c -I. -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DHAVE_CONFIG_H -xO4  -o compat.o compat.c
"compat.c", line 441: variable length array can not be declared with a static storage class: llbuf
cc: acomp failed for compat.c


  Tomppa

Re: 4.1.1 doesn't compile

[Oliver Kiddle]

Tomi Vainio - Sun Finland wrote:
> I also found another problem but this time only when I try to compile
> 32bit binary.
> 
> Compiler is Sun ONE Studio 8, Compiler Collection
>             cc: Sun C 5.5 Patch 112760-01 2003/05/18 
> 
> cc -c -I. -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DHAVE_CONFIG_H -xO4  -o compat.o compat.c
> "compat.c", line 441: variable length array can not be declared with a static storage class: llbuf
> cc: acomp failed for compat.c

This I can't reproduce. The compiler I have is older than that.

The line in question is:
     static char llbuf[DIGBUFSIZE];
and system.h defines:
     #define DIGBUFSIZE ((int)(((sizeof(zlong) * 8) - 1) * 0.30103) + 3)

So quite why the compiler thinks it has a variable length array I
don't understand. Could you perhaps try substituting that in directly
and see if you can tweak it to work. The int cast might be causing the
problem in which case the * 0.30103 could perhaps be changed to * 30103
/ 100000. But I don't understand what the calculation is doing. Anyone
else have any idea?

Oliver

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

Re: 4.1.1 doesn't compile

[Tomi Vainio - Sun Finland]

Oliver Kiddle writes:
 > Tomi Vainio - Sun Finland wrote:
 > > I also found another problem but this time only when I try to compile
 > > 32bit binary.
 > > 
 > > Compiler is Sun ONE Studio 8, Compiler Collection
 > >             cc: Sun C 5.5 Patch 112760-01 2003/05/18 
 > > 
 > > cc -c -I. -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DHAVE_CONFIG_H -xO4  -o compat.o compat.c
 > > "compat.c", line 441: variable length array can not be declared with a static storage class: llbuf
 > > cc: acomp failed for compat.c
 > 
 > This I can't reproduce. The compiler I have is older than that.
 > 
 > The line in question is:
 >      static char llbuf[DIGBUFSIZE];
 > and system.h defines:
 >      #define DIGBUFSIZE ((int)(((sizeof(zlong) * 8) - 1) * 0.30103) + 3)
 > 
 > So quite why the compiler thinks it has a variable length array I
 > don't understand. Could you perhaps try substituting that in directly
 > and see if you can tweak it to work. The int cast might be causing the
 > problem in which case the * 0.30103 could perhaps be changed to * 30103
 > / 100000. But I don't understand what the calculation is doing. Anyone
 > else have any idea?
 > 
I also tried with older compiler "cc: Forte Developer 7 C 5.4
2002/03/09" which doesn't give an error on this.

  Tomppa

Re: 4.1.1 doesn't compile

[Tomi Vainio - Sun Finland]

 > Oliver Kiddle writes:
 > Tomi Vainio - Sun Finland wrote:
 > > I also found another problem but this time only when I try to compile
 > > 32bit binary.
 > > 
 > > Compiler is Sun ONE Studio 8, Compiler Collection
 >           cc: Sun C 5.5 Patch 112760-01 2003/05/18 
 > > 
 > > cc -c -I. -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DHAVE_CONFIG_H -xO4  -o compat.o compat.c
 > > "compat.c", line 441: variable length array can not be declared with a static storage class: llbuf
 > > cc: acomp failed for compat.c
 > 
 > This I can't reproduce. The compiler I have is older than that.
 > 
 > The line in question is:
 >      static char llbuf[DIGBUFSIZE];
 > and system.h defines:
 >      #define DIGBUFSIZE ((int)(((sizeof(zlong) * 8) - 1) * 0.30103) + 3)
 > 
 > So quite why the compiler thinks it has a variable length array I
 > don't understand. Could you perhaps try substituting that in directly
 > and see if you can tweak it to work. The int cast might be causing the
 > problem in which case the * 0.30103 could perhaps be changed to * 30103
 > / 100000. But I don't understand what the calculation is doing. Anyone
 > else have any idea?
 > 
I found our bug report about this same thing.  There is a lot of talk
about C90 and C99 standards and how this should really work.

BugID 4800684 compiler treats a usual array as VLA
      4841119 zsh needs a minor fix to build with latest k2 compiler

Work Around
Use -xc99=%none options if C99 features are not required.

or

system.h line 421
- #define DIGBUFSIZE ((int)(((sizeof(zlong) * 8) - 1) * 0.30103) + 3)
+ #define DIGBUFSIZE ((int)(((sizeof(zlong) * 8) - 1) * 30103/100000) + 3)


  Tomppa

Re: 4.1.1 doesn't compile

[Oliver Kiddle]

Tomi Vainio - Sun Finland wrote:

> I found our bug report about this same thing.  There is a lot of talk
> about C90 and C99 standards and how this should really work.
> 
> BugID 4800684 compiler treats a usual array as VLA
>       4841119 zsh needs a minor fix to build with latest k2 compiler
> 
> Work Around
> Use -xc99=%none options if C99 features are not required.
> 
> or
> 
> system.h line 421
> - #define DIGBUFSIZE ((int)(((sizeof(zlong) * 8) - 1) * 0.30103) + 3)
> + #define DIGBUFSIZE ((int)(((sizeof(zlong) * 8) - 1) * 30103/100000) + 3)

I'll commit this system.h change to CVS then.

Thanks.

Oliver

Re: 4.1.1 doesn't compile

[Bart Schaefer]

On Jun 25, 11:48am, Oliver Kiddle wrote:
} Subject: Re: 4.1.1 doesn't compile
}
}      #define DIGBUFSIZE ((int)(((sizeof(zlong) * 8) - 1) * 0.30103) + 3)
} 
} But I don't understand what the calculation is doing. Anyone
} else have any idea?

It's computing the number of decimal digits necessary to represent the
largest number that can also be represented by the binary digits in a
variable of type zlong.  The -1 and +3 adjust for floating point rounding
errors, a leading "-" for negative numbers, and the trailing NUL byte.

Re: 4.1.1 doesn't compile

[Zefram]

Oliver Kiddle wrote:
>     #define DIGBUFSIZE ((int)(((sizeof(zlong) * 8) - 1) * 0.30103) + 3)

In C89, the definition of a constant expression excludes floating-point
operations.  Some compilers allow floating point operations in constants
as an extension.

-zefram

Re: 4.1.1 doesn't compile

[Tomi Vainio - Sun Finland]

Zefram writes:
 > Oliver Kiddle wrote:
 > >     #define DIGBUFSIZE ((int)(((sizeof(zlong) * 8) - 1) * 0.30103) + 3)
 > 
 > In C89, the definition of a constant expression excludes floating-point
 > operations.  Some compilers allow floating point operations in constants
 > as an extension.
 > 
Did you check what C99 says about this?  I didn't completely followed
what was said on bug report about differences on these standards.

  Tomppa