sys_types-h, sys_stat-h: Ensure blksize_t and blkcnt_t are defined

this type. These two patches guarantee that gnulib's 'sys_types-h' and 'sys_stat-h' modules define 'blksize_t' if the system does not have it. And, while we're at it, also 'blkcnt_t'. 2025-01-17 Bruno Haible sys_stat-h: Ensure blksize_t a

[PATCH] sys_stat: update comments for S_IRWXUGO, S_IXUGO

, 10 insertions(+), 2 deletions(-) diff --git a/ChangeLog b/ChangeLog index bb838bc88..4eb5bcb1d 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,11 @@ +2020-10-26 Paul Eggert + + sys_stat: update comments for S_IRWXUGO, S_IXUGO + * lib/sys_stat.in.h (S_IXUGO, S_IRWXUGO): Update

[PATCH] filemode, sys_stat: Handle MPX files a la AIX.

+++ 4 files changed, 27 insertions(+), 1 deletion(-) diff --git a/ChangeLog b/ChangeLog index e95e443..a2d2b23 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,10 @@ +2012-12-17 Paul Eggert + + filemode, sys_stat: Handle MPX files a la AIX. + * lib/filemode.c (ftypelet): Repo

Re: [PATCH 4/9] sockets, sys_stat: remove AC_C_INLINE in MSVC-only cases

Hi Paul, > Anyway, I reverted that change. Thanks. Bruno

Re: [PATCH 4/9] sockets, sys_stat: remove AC_C_INLINE in MSVC-only cases

On Sun, Sep 30, 2012 at 7:24 PM, Paul Eggert wrote: > On 09/30/2012 03:22 PM, Bruno Haible wrote: > > Nope. MSVC does *not* support 'inline' for functions. > > Thanks for catching that. Sorry, I thought they > supported it, it's been in the standard for what, > 12 years now? > Unfortunately, MS

Re: [PATCH 4/9] sockets, sys_stat: remove AC_C_INLINE in MSVC-only cases

On 09/30/2012 03:22 PM, Bruno Haible wrote: > Nope. MSVC does *not* support 'inline' for functions. Thanks for catching that. Sorry, I thought they supported it, it's been in the standard for what, 12 years now? Anyway, I reverted that change.

Re: [PATCH 4/9] sockets, sys_stat: remove AC_C_INLINE in MSVC-only cases

Hi Paul, > * m4/sockets.m4 (gl_SOCKETS): > * m4/sys_stat_h.m4 (gl_HEADER_SYS_STAT_H): > Remove AC_C_INLINE. Here, 'inline' is used only in MSVC > environments where it's already guaranteed to work Nope. MSVC does *not* support 'inline' for functions. Quoting

[PATCH 4/9] sockets, sys_stat: remove AC_C_INLINE in MSVC-only cases

m4/sockets.m4| 3 +-- m4/sys_stat_h.m4 | 5 + 3 files changed, 11 insertions(+), 6 deletions(-) diff --git a/ChangeLog b/ChangeLog index 5f8f5c7..3124aa3 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,12 @@ +2012-08-29 Paul Eggert + + sockets, sys_stat: remove AC_C_INLINE i

[PATCH 12/16] sys_stat: avoid 'static inline'

/ChangeLog b/ChangeLog index 03291cc..32a04a3 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,5 +1,9 @@ 2012-08-18 Paul Eggert + sys_stat: avoid 'static inline' + * lib/sys_stat.in.h (rpl_mkdir): Now static, not static inline. + * m4/sys_stat_h.m4 (gl_HEADER_SYS_STAT_

Re: sys_stat

Hi, Alexander V. Lukyanov wrote: > Here is a patch to allow proper linking of rpl_lstat in C++ programs. Nearly right. Since it's dangerous to have #includes inside extern "C" blocks, I shrinked the extern "C" block so that it contains only the function redeclarations: 2008-11-06 Alexander V.

sys_stat

Here is a patch to allow proper linking of rpl_lstat in C++ programs. diff --git a/lib/sys_stat.in.h b/lib/sys_stat.in.h index 234b527..50fb524 100644 --- a/lib/sys_stat.in.h +++ b/lib/sys_stat.in.h @@ -41,6 +41,10 @@ #ifndef _GL_SYS_STAT_H #define _GL_SYS_STAT_H +#ifdef __cplusplus +extern "C"

Re: sys_stat: define lstat properly

Bruno Haible <[EMAIL PROTECTED]> writes: >> The following patch fixes the lstat declaration in sys_stat.in.h. > > It is all right. Sorry, I should have tested a little better last week. I have pushed it. /Simon

Re: sys_stat: define lstat properly

> The following patch fixes the lstat declaration in sys_stat.in.h. It is all right. Sorry, I should have tested a little better last week. Bruno

sys_stat: define lstat properly

The lstat problem on mingw was because of the generated sys/stat.h containing: #if ! 0 # define lstat stat #endif #if 1 && 1 # undef lstat # define lstat rpl_lstat extern int rpl_lstat (const char *name, struct stat *buf); #endif That seems broken, and made lstat.c to call lstat, but there is no

Re: more #include_next patches for iconv_open, netinet_in, sys_stat, etc.

. > * modules/locale (locale.h): Likewise. > * modules/netinet_in (netinet/in.h): Likewise. > * modules/sys_select (sys_select.h): Likewise. > * modules/sys_socket (sys/socket.h): Likewise. > * modules/sys_stat (sys/stat.h): Likewise. > * modu

Re: more #include_next patches for iconv_open, netinet_in, sys_stat, etc.

Paul Eggert <[EMAIL PROTECTED]> writes: > Bruno Haible <[EMAIL PROTECTED]> writes: > >> If it triggers the "great confusion" that the gcc doc is talking about, we >> can always revert back to the "#pragma GCC system_header" approach. > > OK, thanks, I applied those extra patches. Simon, if you ha

Re: more #include_next patches for iconv_open, netinet_in, sys_stat, etc.

Paul Eggert asked: > Are the generated .h files intended to be useful by all compilers on a > platform, or just by the compiler and compiler options tested via > 'configure'? They are only for the particular compiler and compiler options that were used to generate them. It is not impossible to im

Re: more #include_next patches for iconv_open, netinet_in, sys_stat, etc.

Paul Eggert wrote: > This approach will require some minor rewrites, e.g. in string_.h we'd > replace this: > >#if @HAVE_INCLUDE_NEXT@ ># include_next >#endif > >#ifndef _GL_STRING_H >#define _GL_STRING_H > >#if ! @HAVE_INCLUDE_NEXT@ ># include @ABSOLUTE_STRING_H@ >

Re: more #include_next patches for iconv_open, netinet_in, sys_stat, etc.

Paul Eggert <[EMAIL PROTECTED]> wrote: > This is a followup to my previous message about using #include_next to > fix problems I'm having with GCC 4.2.0 on Debian stable. Hi Paul, Not a big deal, but this breaks the part of coreutils' "make distcheck" that compiles with -Werror -ansi -pedantic:

Re: more #include_next patches for iconv_open, netinet_in, sys_stat, etc.

Bruno Haible <[EMAIL PROTECTED]> writes: > Yes, the IRIX 6.5 compiler gives a warning about #include_next, even inside > #if 0: > > "foo.c", line 2: warning(1011): unrecognized preprocessing directive > #include_next >^ Thanks for checking that. > If we want to work around it, it's easy:

Re: more #include_next patches for iconv_open, netinet_in, sys_stat, etc.

Paul Eggert wrote: > My biggest worry wasn't confusion, but compilers that complain about > "#include_next" even in code that is ifdeffed out. The C standard > says such programs are OK but I vaguely recall some compilers from > decades ago that complained about such things. Yes, the IRIX 6.5 com

Re: more #include_next patches for iconv_open, netinet_in, sys_stat, etc.

Bruno Haible <[EMAIL PROTECTED]> writes: > If it triggers the "great confusion" that the gcc doc is talking about, we > can always revert back to the "#pragma GCC system_header" approach. OK, thanks, I applied those extra patches. Simon, if you have an objection to your part please let me know a

Re: more #include_next patches for iconv_open, netinet_in, sys_stat, etc.

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Paul Eggert on 5/17/2007 12:30 AM: > > Eric, are the following #include_next patches to sys_stat OK with you? Yes, please apply. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAI

Re: more #include_next patches for iconv_open, netinet_in, sys_stat, etc.

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Bruno Haible on 5/17/2007 3:33 AM: > > I prefer to avoid #include_next for the reasons mentioned in [1]. > [1] http://lists.gnu.org/archive/html/bug-gnulib/2007-02/msg00222.html However, that quote you listed said fix_includes "should b

Re: more #include_next patches for iconv_open, netinet_in, sys_stat, etc.

Paul Eggert wrote: > This is a followup to my previous message about using #include_next to > fix problems I'm having with GCC 4.2.0 on Debian stable. > > Bruno, are the following #include_next patches to fchdir, iconv_open, > and locale OK with you? I prefer to avoid #include_next for the reason

more #include_next patches for iconv_open, netinet_in, sys_stat, etc.

elect, sys_socket, sysexits, and unistd OK with you? Eric, are the following #include_next patches to sys_stat OK with you? 2007-05-16 Paul Eggert <[EMAIL PROTECTED]> * lib/dirent_.h: Prefer #include_next to #include @ABSOLUTE_FOO_H@ if @[EMAIL PROTECTED] This works

mkdir: depend on sys_stat

mkdir has two portability problems: one with the trailing slash, one with the declaration on mingw. The former is solved by the 'mkdir' module, the latter by the 'sys_stat' module. This is confusing. How can anyone remember this? If someone wants a working mkdir() function,

Re: mingw conflict between mkdtemp and sys_stat

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Eric Blake on 10/27/2006 9:09 AM: > Eric Blake byu.net> writes: > >> The second half, fixing mkdtemp to use the new tempname module and the >> existing sys_stat module, so that mkdtemp and mkstemp can coexist on

Re: mingw conflict between mkdtemp and sys_stat

Eric Blake <[EMAIL PROTECTED]> writes: > Also, is it worth changing other modules that depend on stat-macros to > instead depend on sys_stat, and delete the #include "stat-macros.h" line > from their implementation? Sure, but more generally I think it's better to mo

Re: mingw conflict between mkdtemp and sys_stat

Eric Blake byu.net> writes: > The second half, fixing mkdtemp to use the new tempname module and the > existing sys_stat module, so that mkdtemp and mkstemp can coexist on > mingw, still needs Bruno's approval; I'll post that patch later in light > of this commit.

Re: mingw conflict between mkdtemp and sys_stat

I'm going ahead and checking it in. The changes to tempname.c are not as drastic as in the original, so that it should now be easier to compare it to glibc. The second half, fixing mkdtemp to use the new tempname module and the existing sys_stat module, so that mkdtemp and mkstemp can coexi

Re: mingw conflict between mkdtemp and sys_stat

Eric Blake <[EMAIL PROTECTED]> writes: > It just looks nicer if we provide gnulib > modules with exported APIs that do not lie in the reserved namespace. Sure, but can't you do something like the following (taken from mktime.c)? This minimizes the changes from libc and packages it inside "#ifnde

Re: mingw conflict between mkdtemp and sys_stat

Is that do not lie in the reserved namespace. Bruno, is this patch idea acceptable? Without it, combining the mkstemp and mkdtemp modules fails to compile on mingw, because mkstemp pulls in the sys_stat module which provides a conflicting mkdir definition. - -- Life is short - so eat dessert firs

Re: mingw conflict between mkdtemp and sys_stat

Eric Blake <[EMAIL PROTECTED]> writes: > Best of all, this patch deletes more than twice as many lines than what it > adds > in new files :) I like that part! As for mkstemp, there is some desire to keep the sources as close to glibc as possible, with the idea of migrating our fixes back. So,

Re: mingw conflict between mkdtemp and sys_stat

for file in $files; do \ + echo $file \ + | sed -e "$sed_escape_dot" -e "$sed_escape_slash" \ + | sed -e "$sed_removal_prefix" - e "$sed_removal_suffix"; \ + do

Re: mingw conflict between mkdtemp and sys_stat

Eric Blake byu.net> writes: > > Any chance we can fix the mkdtemp module depend on the sys_stat module, which > already takes care of mkdir for mingw, rather than open-coding its own mkdir > replacement? And would this be any closer to the glibc implementation? For that matte

mingw conflict between mkdtemp and sys_stat

/mkdtemp.c ../../lib/mkdtemp.c:79:1: "mkdir" redefined In file included from ../../lib/mkdtemp.c:52: ./sys/stat.h:45:1: this is the location of the previous definition Any chance we can fix the mkdtemp module depend on the sys_stat module, which already takes care of mkdir for mingw, r