[Bug libc/188] New: st_atime define

[Bug libc/188] New: st_atime define

[redhat-bug at treblig dot org]

Hi,
  I've just had a few hours of pain dealing with the results of the line:

# define st_atime st_atim.tv_sec  /* Backward compatibility.  */

in sysdeps/unix/sysv/linux/bits/stat.h (and various other versions of the file)
when I came a structure in other source with a member st_atime (hardly uncommon
- especially if it is in something dealing with files).

Is there really no neater way of dealing with this?  #define'ing something like
this is pretty brutal.

If nothing else could we have st_atim as something more like
st_atim_this_is_an_evil_hack_in_the_c_library  (well ok, something obvious anyway).

Dave

-- 
           Summary: st_atime define
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: libc
        AssignedTo: gotom at debian dot or dot jp
        ReportedBy: redhat-bug at treblig dot org
                CC: glibc-bugs at sources dot redhat dot com


http://sources.redhat.com/bugzilla/show_bug.cgi?id=188

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/188] st_atime define

[schwab at suse dot de]

------- Additional Comments From schwab at suse dot de  2004-05-29 16:46 -------
Identifier starting with st_ are reserved for any use after including 
<sys/stat.h>.  See POSIX.1-2001 System Interfaces, 2.2.2 The Name Space. 

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID


http://sources.redhat.com/bugzilla/show_bug.cgi?id=188

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/188] st_atime define

[redhat-bug at treblig dot org]

------- Additional Comments From redhat-bug at treblig dot org  2004-05-29 19:08 -------
(In reply to comment #1)
> Identifier starting with st_ are reserved for any use after including 
> <sys/stat.h>.  See POSIX.1-2001 System Interfaces, 2.2.2 The Name Space. 

I've just had a look at that and am not sure that is true - but I'm not a
standards expert - but please consider the following.  There are two tables;

The first table is immediately prefixed by some text that says 'Implementations
may add symbols to the headers shown in the following table....' and indeed that
includes st_ as a prefix for sys/stat.h

The second table is immediately prefixed by 'If any header in the following
table is included, macros with the prefixes shown may be defined......'; this
second table just defines S_ as a prefix for macros for sys/stat.h

So I'm not sure from my reading of it that adding a macro to define something
st_ is a valid thing to do in that header, and thus while I'm not safe adding a
variable/function with an st_ name to my own source, I should be able to have it
as a structure member.

Dave

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |


http://sources.redhat.com/bugzilla/show_bug.cgi?id=188

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.

[Bug libc/188] st_atime define

[schwab at suse dot de]

------- Additional Comments From schwab at suse dot de  2004-05-29 19:59 -------
"Symbols" is a superset of "macros". 

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |INVALID


http://sources.redhat.com/bugzilla/show_bug.cgi?id=188

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.