Re: Tcl 8.5 HP/UX Compiler warnings

From: Donal K. Fellows (donal.k.fellows_at_man.ac.uk)
Date: 01/13/04 

Date: 13 Jan 2004 02:12:03 -0800

R. T. Wurth wrote:
> 1.) After all the substitutions, stat64 struct pointers are being
> supplied to the stat and lstat system calls that should take regular
> stat struct pointers. The elementary types of the structure
> elements match, but there is one instance where the declared types
> differ (but they both eventually resolve through typedefs to the
> same elementary type), and there's another place where both declared
> type and name differ, but the eventual base type (after resolving
> all the typedefs) is the same.

Just commenting here that there is something deeply bizarre going on.
I have checked the core sources and tcl either uses 'struct
stat'/'stat()' or 'struct stat64'/'stat64'; they're controlled by the
same #def. That the compiler is complaining about feeding the
structure to the corresponding function is deeply lame, and indicates
a fault somewhere outside our control (probably in either the HP-UX
headers or the compiler itself. Or both.)

> 2.) Tcl, trying to be portable makes a TclFd (storage for a file
> pointer/descriptor) the biggest thing it could think of, a pointer.
[...]

Actually, that's because file descriptors really are pointers on some
OSes.

> I think I've come up with similarly reasonable arguments that the
> other warnings I cited are similarly harmless. Still, I'd think the
> fewer compiler warnings, the better off, so that new bugs don't get
> hidden amidst all the clutter of warnings.

I agree with the general principle of reducing error messages. One of
the most annoying things about building Tcl on Linux is that the
networking code *always* generates a few warnings because of an
idiotic compiler "feature". (Either you have those warnings which are
due to a function having the *correct* type signature (!) or you turn
down the warning level and might miss out on a whole set of other
potentially important ways in which things can go wrong.) OTOH, I'd
also like sometime to get Tcl's config output passed to the compiler
other than on the command-line; the invocation lines are so long that
they'd obscure warnings early in the build process due to running out
of lines of scrollback...

Anyway, enough gripeing... ;^)

Donal.

Relevant Pages

  • Re: Tcl 8.5 HP/UX Compiler warnings
    ... results and "the optional HP ANSI C compiler", ... stat64 struct pointers are being ... The elementary types of the structure ... other warnings I cited are similarly harmless. ...
    (comp.lang.tcl)
  • Re: Address ordering of compiled top-level definitions?
    ... point into the same array, or point one element behind the last valid entry of the same array. ... Off hands, I'm not sure whether you can safely compare pointers to elements in a struct, but even there the result is undefined since a compiler has the freedom to re-arrange the elements here. ...
    (comp.lang.c.moderated)
  • Re: Pointer problem when trying to abstract away an array type
    ... The situations is that I have a data type, ... passing pointers to this type somewhat difficult. ... Put the array in a struct. ... If you used `void*' the compiler ...
    (comp.lang.c)
  • Help - buried in compiler warnings.
    ... I have an app which compiles with no errors or warnings ... But a user reports that with gcc 4.0.2 there are pages ... whose prototype calls for pointers to signed char arrays. ... The compiler options used are -g -O -Wall ...
    (comp.os.linux.development.apps)
  • Re: Copying from one struct to another, simple assignment?
    ... members depending on the values of other members, ... I can give you real world examples where struct comparison is useful... ... for the reasons I've said it would be useful and the possibilities for easy compiler optimisations below. ... A straight structure comparison, on the other hand, it just has to check the definition of the struct to see if it has put in any padding or if there are floating point or pointer fields (some processors would not have to consider pointers). ...
    (comp.lang.c)