The configure test for mktime (m4/mktime.m4) contains the following
code:
for (;;)
{
t = (time_t_max << 1) + 1;
if (t <= time_t_max)
break;
time_t_max = t;
}
This code has undefined behavior on signed integer overflow; at least
some versions of gcc, and any san
On Thu, Jan 27, 2011 at 08:14:56AM -0700, Eric Blake wrote:
> # define TYPE_MINIMUM(t) \
> ((t) (! TYPE_SIGNED (t) \
> ? (t) 0 \
> : TYPE_SIGNED_MAGNITUDE (t) \
> ? ~ (t) 0 \
> : ~ (t) 0 << (sizeof (t) * CHAR_BIT - 1)))
> # define TYPE_MAXIMUM(t) \
> ((t) (! TYPE
On Thu, Jan 27, 2011 at 07:42:10PM +0100, Bruno Haible wrote:
> Do you mean to say that GCC produces undefined behaviour for shifts of
> negative values, even those where the result is negative (no overflow)?
> I've never seen a sign of that.
I mean to say that left-shifting a negative value *at a
On Thu, Jan 27, 2011 at 11:42:25PM -0800, Paul Eggert wrote:
> On 01/27/2011 02:08 PM, Rich Felker wrote:
> > I mean to say that left-shifting a negative value *at all* is
> > undefined behavior. I doubt gcc will ever break it, but why not use my
> > version of the code that&
On Fri, Jan 28, 2011 at 06:57:22PM +0100, Bruno Haible wrote:
> Rich Felker wrote:
> > Testing which of the three allowable signed integer
> > representations is used is easy: compare ~(t)1 against and -(t)1 and
> > -(t)2.
>
> Testing which of the three signed intege
On Wed, Apr 09, 2014 at 02:49:37PM +0200, Steffen Nurpmeso wrote:
> Eric Blake wrote:
> |>> Dan Douglas wrote:
> |>>> ksh93 already has this feature using the "L" modifier:
> |>>>
> |>>> ksh -c "printf '%.3Ls\n' $'\u2605\u2605\u2605\u2605\u2605'"
> |>>> ★★★
> |>>
> |>> At least there is
cp (and perhaps other utilities) are treating EOPNOTSUPP from lchmod
as a hard error rather than an indication that the system does not
support modes for symlinks. This recently came up on
https://bugs.gentoo.org/687236#c17 where users are claiming recent
changes to gnulib made the problem go away,
On Wed, Jan 22, 2020 at 04:08:26PM +0100, Florian Weimer wrote:
> * Rich Felker:
>
> > On Wed, Jan 22, 2020 at 03:34:18PM +0100, Florian Weimer wrote:
> >> * Rich Felker:
> >>
> >> > coreutils should be opting to use the system-provided lchmod, which is
On Wed, Jan 22, 2020 at 03:34:18PM +0100, Florian Weimer wrote:
> * Rich Felker:
>
> > coreutils should be opting to use the system-provided lchmod, which is
> > safe, and correctly handling error returns (silently treating
> > EOPNOTSUPP as success) rather than as h
On Wed, Jan 22, 2020 at 04:32:45PM +0100, Florian Weimer wrote:
> * Rich Felker:
>
> > On Wed, Jan 22, 2020 at 04:08:26PM +0100, Florian Weimer wrote:
> >> * Rich Felker:
> >>
> >> > On Wed, Jan 22, 2020 at 03:34:18PM +0100, F
On Wed, Jan 22, 2020 at 05:19:05PM +0100, Florian Weimer wrote:
> * Rich Felker:
>
> > On Wed, Jan 22, 2020 at 04:32:45PM +0100, Florian Weimer wrote:
> >> * Rich Felker:
> >>
> >> > On Wed, Jan 22, 2020 at 04:08:26PM +0100, Florian Weimer wrote:
> &
On Wed, Jan 22, 2020 at 09:48:14PM +0100, Florian Weimer wrote:
> * Rich Felker:
>
> >> Hmm. The way I read the musl code, the O_PATH descriptor already
> >> exists. At this point, you can just chmod the O_PATH descriptor, and
> >> have the kernel report EOPNO
On Wed, Jan 22, 2020 at 01:55:57PM -0800, Paul Eggert wrote:
> On 1/22/20 7:08 AM, Florian Weimer wrote:
> >I think you misread what I wrote: lchmod*always* returns ENOSYS. Even
> >if the file is not a symbolic link. Likewise, fchmodat with
> >AT_SYMLINK_NOFOLLOW *always* returns ENOTSUP.
>
> T
On Wed, Feb 12, 2020 at 12:50:19PM +0100, Florian Weimer wrote:
> * Paul Eggert:
>
> > On 1/22/20 2:05 PM, Rich Felker wrote:
> >> I think we're approaching a consensus that glibc should fix this too,
> >> so then it would just be gnulib matching the fix.
> &
On Wed, Feb 12, 2020 at 08:05:55AM -0500, Rich Felker wrote:
> On Wed, Feb 12, 2020 at 12:50:19PM +0100, Florian Weimer wrote:
> > * Paul Eggert:
> >
> > > On 1/22/20 2:05 PM, Rich Felker wrote:
> > >> I think we're approaching a consensus that glibc sho
15 matches
Mail list logo
