This is the mail archive of the libc-alpha@cygnus.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

[Various] struct stat



There's a discussion on linux-kernel about glibc's definition of field
st_dev in struct stat for compilers other than gcc.  Perhaps somebody
likes to comment.

Andreas



Topics:
   struct stat
   Re: struct stat
   Re: struct stat
   Re: struct stat


----------------------------------------------------------------------

Date:	Thu, 11 Mar 1999 17:18:25 -0500
From: "David A. Greene" <greened@eecs.umich.edu>
To: linux-kernel@vger.rutgers.edu
Subject: struct stat
Message-ID: <36E84131.DF09C579@eecs.umich.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

We've run into a problem with the definition of struct stat
that appears in kernel 2.0.36 and later (or maybe it's a libc6
problem).  Specifically, st_dev is declared as a __dev_t, which 
under gcc is a typedef of "long long."  However, under any 
other compiler (i.e. one that does not define __GNUC__), it is 
a typedef of a struct containing an array of two integers:

from <gnu/types.h>:

   #ifdef __GNUC__
   typedef unsigned long long int __u_quad_t;
   typedef long long int __quad_t;
   #else
   typedef struct
     {
       long int __val[2];
     } __quad_t;
   typedef struct
     {
       __u_long __val[2];
     } __u_quad_t;
   #endif
   typedef __u_quad_t __dev_t;     /* Type of device numbers.  */

Perhaps this is a libc6 problem, but it seems the kernel is
very closely connected in this case.  I saw hints to this 
problem in the linux-kernel archives (there was some discussion 
about coordination between the kernel and libc teams).

Our problem, though, I think is somewhat different.  When we
use lcc to compile, say, the Spec95 benchmark suite, it emits
compile-time errors in the builds of gcc and perl.  These
two benchmarks compare st_dev for equality, and we all know
that it is illegal in C to compare two structs.

If a 64-bit device number is desired, why not declare it
"long long" explicitly?  Why all this hiding behind __GNUC__?
Just say what you want and let the compiler implement the 
non-standard type.  Declaring it as a struct breaks code that
was written years ago.  At least with "long long," the compiler 
has a resonable chance of being updated to support it.

If there is a solution to this problem, please direct me to the
proper information.

Thanks!

                                         -Dave

- 
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/


------------------------------

Date:	11 Mar 1999 17:35:46 -0500
From: Ben Pfaff <pfaffben@pilot.msu.edu>
To: alan@lxorguk.ukuu.org.uk (Alan Cox)
Cc: greened@eecs.umich.edu (David A. Greene),
	linux-kernel@vger.rutgers.edu
Subject: Re: struct stat
Message-ID: <87r9qv8xj1.fsf@pfaffben.user.msu.edu>
References: <m10LEj2-0007U1C@the-village.bc.nu>

alan@lxorguk.ukuu.org.uk (Alan Cox) writes:

   > Our problem, though, I think is somewhat different.  When we
   > use lcc to compile, say, the Spec95 benchmark suite, it emits
   > compile-time errors in the builds of gcc and perl.  These
   > two benchmarks compare st_dev for equality, and we all know
   > that it is illegal in C to compare two structs.

   I was under the impression ANSI C mandated a bytewise comparison.

ANSI 6.3.9 says that the operands to == and != must be one of the
following (paraphrasing, somewhat simplified):
  - both of arithmetic type
  - both pointers to compatible types
  - one any type of pointer and the other a pointer to void
  - one a pointer and the other a null pointer constant
i.e., structs aren't allowed.

On the other hand, I don't see the gcc documentation listing
comparison of structs as one of its extensions.

- 
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/


------------------------------

Date:	Thu, 11 Mar 1999 17:45:50 -0500
From: "David A. Greene" <greened@eecs.umich.edu>
To: linux-kernel@vger.rutgers.edu
Subject: Re: struct stat
Message-ID: <36E8479E.B33C0605@eecs.umich.edu>
References: <m10LEj2-0007U1C@the-village.bc.nu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Alan Cox wrote:
> 
> > Our problem, though, I think is somewhat different.  When we
> > use lcc to compile, say, the Spec95 benchmark suite, it emits
> > compile-time errors in the builds of gcc and perl.  These
> > two benchmarks compare st_dev for equality, and we all know
> > that it is illegal in C to compare two structs.
> 
> I was under the impression ANSI C mandated a bytewise comparison.

I can't find anything about this in K&R II.  I don't have an
official standard at my disposal.  All I can say is that both
lcc and the Edison Design Group's C front-end reject the code.
The Edison front-end is an industry-standard piece of software,
and I'd be surprised if they got this wrong.

Ah, here's the relevant C FAQ entry:

2.8:    Why can't you compare structures?

A:      There is no single, good way for a compiler to implement
        structure comparison which is consistent with C's low-level
        flavor.  A simple byte-by-byte comparison could founder on
        random bits present in unused "holes" in the structure (such
        padding is used to keep the alignment of later fields correct;
        see question 2.12).  A field-by-field comparison might require
        unacceptable amounts of repetitive code for large structures.

        If you need to compare two structures, you'll have to write your
        own function to do so, field by field.

        References: K&R2 Sec. 6.2 p. 129; ANSI Sec. 4.11.4.1 footnote
        136; Rationale Sec. 3.3.9; H&S Sec. 5.6.2 p. 133.

> > If a 64-bit device number is desired, why not declare it
> > "long long" explicitly?  Why all this hiding behind __GNUC__?
> 
> Because long long isnt ansi

Clearly, but at least a compiler has a chance of implementing it
in a reasonable fashion.  Now, of course one could argue that the
software should be written to handle the various definitions of
__dev_t.  The problem is, the software was written back before this
was an issue.

This is a no-win situation, and I understand that.  I sent the
message more to point out the problem than anything else.  A
solution would be nice.  We can modify the Spec95 source, but
that's frowned upon by the research community.  :-/

                                          -Dave

- 
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/


------------------------------

Date:	Fri, 12 Mar 1999 02:35:19 +0100
From: Matthew Wilcox <Matthew.Wilcox@genedata.com>
To: linux-kernel@vger.rutgers.edu
Cc: greened@eecs.umich.edu
Subject: Re: struct stat
Message-ID: <19990312023519.E24922@mencheca.ch.genedata.com>
Content-Type: text/plain; charset=us-ascii


I looked up Single Unix and it says...

In sys/stat.h:

The structure stat contains at least the following members: 
dev_t	st_dev	ID of device containing file


In the definition for sys/types.h, it says:

The <sys/types.h> header includes definitions for at least the
following types: 
[...]
dev_t	Used for device IDs. 
[...]
All of the types are defined as arithmetic types of an appropriate length
(there are some exceptions and further clarifications, but they do not
relate to dev_t).

So it is quite clear that one can reasonably expect to compare st_dev
with the = operator, and therefore glibc is in error.

[I don't know the address for libc-hackers; can someone forward this
please?]

- - 
Matthew Wilcox <willy@bofh.ai>
"I decry the current tendency to seek patents on algorithms.  There are
better ways to earn a living than to prevent other people from making use of
one's contributions to computer science."  -- Donald E. Knuth, TAoCP vol 3

- 
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/


------------------------------

End of forward1NA4L1 Digest
***************************



-- 
 Andreas Jaeger   aj@arthur.rhein-neckar.de    jaeger@informatik.uni-kl.de
  for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]