Searched hist:1.173 (Results 1 - 25 of 406) sorted by relevance

1234567891011>>

/src/sys/compat/linux/common/
H A Dlinux_mtio.c1.7 Fri Mar 21 21:54:58 GMT 2008 ad branches: 1.7.6; 1.7.84; 1.7.96;
Catch up with descriptor handling changes. See kern_descrip.c revision
1.173 for details.

H A Dlinux_sg.c1.13 Fri Mar 21 21:54:58 GMT 2008 ad branches: 1.13.6; 1.13.48; 1.13.84;
Catch up with descriptor handling changes. See kern_descrip.c revision
1.173 for details.

H A Dlinux_blkio.c1.17 Fri Mar 21 21:54:58 GMT 2008 ad branches: 1.17.6; 1.17.48; 1.17.68;
Catch up with descriptor handling changes. See kern_descrip.c revision
1.173 for details.

H A Dlinux_fcntl.h1.13 Fri Mar 21 21:54:58 GMT 2008 ad branches: 1.13.2; 1.13.4;
Catch up with descriptor handling changes. See kern_descrip.c revision
1.173 for details.

H A Dlinux_fdio.c1.13 Fri Mar 21 21:54:58 GMT 2008 ad branches: 1.13.6; 1.13.84; 1.13.96;
Catch up with descriptor handling changes. See kern_descrip.c revision
1.173 for details.

H A Dlinux_cdrom.c1.26 Fri Mar 21 21:54:58 GMT 2008 ad branches: 1.26.2; 1.26.4;
Catch up with descriptor handling changes. See kern_descrip.c revision
1.173 for details.

H A Dlinux_hdio.c1.16 Fri Mar 21 21:54:58 GMT 2008 ad branches: 1.16.6; 1.16.48; 1.16.68;
Catch up with descriptor handling changes. See kern_descrip.c revision
1.173 for details.

H A Dlinux_termios.c1.34 Fri Mar 21 21:54:58 GMT 2008 ad branches: 1.34.2; 1.34.4;
Catch up with descriptor handling changes. See kern_descrip.c revision
1.173 for details.

/src/sys/miscfs/procfs/
H A Dprocfs_fd.c1.13 Fri Mar 21 21:55:00 GMT 2008 ad branches: 1.13.2; 1.13.4;
Catch up with descriptor handling changes. See kern_descrip.c revision
1.173 for details.

/src/sys/compat/linux32/common/
H A Dlinux32_termios.c1.10 Fri Mar 21 21:54:58 GMT 2008 ad Catch up with descriptor handling changes. See kern_descrip.c revision
1.173 for details.

H A Dlinux32_stat.c1.11 Fri Mar 21 21:54:58 GMT 2008 ad branches: 1.11.4; 1.11.6; 1.11.10; 1.11.12; 1.11.14;
Catch up with descriptor handling changes. See kern_descrip.c revision
1.173 for details.

/src/sys/compat/netbsd32/
H A Dnetbsd32_event.c1.5 Fri Mar 21 21:54:58 GMT 2008 ad branches: 1.5.2; 1.5.4;
Catch up with descriptor handling changes. See kern_descrip.c revision
1.173 for details.

/src/sys/sys/
H A Dvfs_syscalls.h1.7 Fri Mar 21 21:55:01 GMT 2008 ad branches: 1.7.2; 1.7.6; 1.7.12; 1.7.14;
Catch up with descriptor handling changes. See kern_descrip.c revision
1.173 for details.

/src/sys/dev/
H A Dfirmload.c1.10 Fri Mar 21 21:54:59 GMT 2008 ad branches: 1.10.2; 1.10.4;
Catch up with descriptor handling changes. See kern_descrip.c revision
1.173 for details.

H A Dkloader.c1.16 Fri Mar 21 21:54:59 GMT 2008 ad branches: 1.16.2; 1.16.4;
Catch up with descriptor handling changes. See kern_descrip.c revision
1.173 for details.

/src/sys/compat/sunos32/
H A Dsunos32_ioctl.c1.28 Fri Mar 21 21:54:59 GMT 2008 ad branches: 1.28.2; 1.28.4; 1.28.6;
Catch up with descriptor handling changes. See kern_descrip.c revision
1.173 for details.

/src/sys/rump/fs/lib/libsyspuffs/
H A Dpuffs_rumpglue.c1.3 Fri Mar 21 21:55:01 GMT 2008 ad branches: 1.3.4; 1.3.6; 1.3.8; 1.3.10;
Catch up with descriptor handling changes. See kern_descrip.c revision
1.173 for details.

/src/sys/compat/common/
H A Dvfs_syscalls_12.c1.25 Fri Mar 21 21:54:58 GMT 2008 ad branches: 1.25.2; 1.25.6; 1.25.8; 1.25.10;
Catch up with descriptor handling changes. See kern_descrip.c revision
1.173 for details.

/src/sys/compat/ultrix/
H A Dultrix_ioctl.c1.35 Fri Mar 21 21:54:59 GMT 2008 ad branches: 1.35.4; 1.35.6; 1.35.22;
Catch up with descriptor handling changes. See kern_descrip.c revision
1.173 for details.

/src/sys/dev/putter/
H A Dputter.c1.9 Fri Mar 21 21:54:59 GMT 2008 ad branches: 1.9.2; 1.9.4; 1.9.6;
Catch up with descriptor handling changes. See kern_descrip.c revision
1.173 for details.

/src/sys/nfs/
H A Dnfs_kq.c1.21 Fri Mar 21 21:55:01 GMT 2008 ad branches: 1.21.2; 1.21.4;
Catch up with descriptor handling changes. See kern_descrip.c revision
1.173 for details.

/src/sys/rump/librump/rumpkern/
H A DMakefile1.32 Fri Mar 21 21:55:01 GMT 2008 ad branches: 1.32.2; 1.32.4;
Catch up with descriptor handling changes. See kern_descrip.c revision
1.173 for details.

/src/sys/compat/sunos/
H A Dsunos_misc.c1.173 Wed Jul 03 18:24:50 GMT 2019 dholland branches: 1.173.2;
Stack buffers mustn't escape their scope. PR 54326 from David Binderman

1.173 Wed Jul 03 18:24:50 GMT 2019 dholland branches: 1.173.2;
Stack buffers mustn't escape their scope. PR 54326 from David Binderman

1.159 Fri Mar 21 21:54:59 GMT 2008 ad branches: 1.159.4; 1.159.6; 1.159.8;
Catch up with descriptor handling changes. See kern_descrip.c revision
1.173 for details.

/src/sys/kern/
H A Dkern_core.c1.10 Fri Mar 21 21:55:00 GMT 2008 ad branches: 1.10.2; 1.10.4;
Catch up with descriptor handling changes. See kern_descrip.c revision
1.173 for details.

H A Dkern_ktrace.c1.173 Mon Sep 03 16:29:35 GMT 2018 riastradh branches: 1.173.4; 1.173.6;
Rename min/max -> uimin/uimax for better honesty.

These functions are defined on unsigned int. The generic name
min/max should not silently truncate to 32 bits on 64-bit systems.
This is purely a name change -- no functional change intended.

HOWEVER! Some subsystems have

#define min(a, b) ((a) < (b) ? (a) : (b))
#define max(a, b) ((a) > (b) ? (a) : (b))

even though our standard name for that is MIN/MAX. Although these
may invite multiple evaluation bugs, these do _not_ cause integer
truncation.

To avoid `fixing' these cases, I first changed the name in libkern,
and then compile-tested every file where min/max occurred in order to
confirm that it failed -- and thus confirm that nothing shadowed
min/max -- before changing it.

I have left a handful of bootloaders that are too annoying to
compile-test, and some dead code:

cobalt ews4800mips hp300 hppa ia64 luna68k vax
acorn32/if_ie.c (not included in any kernels)
macppc/if_gm.c (superseded by gem(4))

It should be easy to fix the fallout once identified -- this way of
doing things fails safe, and the goal here, after all, is to _avoid_
silent integer truncations, not introduce them.

Maybe one day we can reintroduce min/max as type-generic things that
never silently truncate. But we should avoid doing that for a while,
so that existing code has a chance to be detected by the compiler for
conversion to uimin/uimax without changing the semantics until we can
properly audit it all. (Who knows, maybe in some cases integer
truncation is actually intended!)

1.173 Mon Sep 03 16:29:35 GMT 2018 riastradh branches: 1.173.4; 1.173.6;
Rename min/max -> uimin/uimax for better honesty.

These functions are defined on unsigned int. The generic name
min/max should not silently truncate to 32 bits on 64-bit systems.
This is purely a name change -- no functional change intended.

HOWEVER! Some subsystems have

#define min(a, b) ((a) < (b) ? (a) : (b))
#define max(a, b) ((a) > (b) ? (a) : (b))

even though our standard name for that is MIN/MAX. Although these
may invite multiple evaluation bugs, these do _not_ cause integer
truncation.

To avoid `fixing' these cases, I first changed the name in libkern,
and then compile-tested every file where min/max occurred in order to
confirm that it failed -- and thus confirm that nothing shadowed
min/max -- before changing it.

I have left a handful of bootloaders that are too annoying to
compile-test, and some dead code:

cobalt ews4800mips hp300 hppa ia64 luna68k vax
acorn32/if_ie.c (not included in any kernels)
macppc/if_gm.c (superseded by gem(4))

It should be easy to fix the fallout once identified -- this way of
doing things fails safe, and the goal here, after all, is to _avoid_
silent integer truncations, not introduce them.

Maybe one day we can reintroduce min/max as type-generic things that
never silently truncate. But we should avoid doing that for a while,
so that existing code has a chance to be detected by the compiler for
conversion to uimin/uimax without changing the semantics until we can
properly audit it all. (Who knows, maybe in some cases integer
truncation is actually intended!)

1.173 Mon Sep 03 16:29:35 GMT 2018 riastradh branches: 1.173.4; 1.173.6;
Rename min/max -> uimin/uimax for better honesty.

These functions are defined on unsigned int. The generic name
min/max should not silently truncate to 32 bits on 64-bit systems.
This is purely a name change -- no functional change intended.

HOWEVER! Some subsystems have

#define min(a, b) ((a) < (b) ? (a) : (b))
#define max(a, b) ((a) > (b) ? (a) : (b))

even though our standard name for that is MIN/MAX. Although these
may invite multiple evaluation bugs, these do _not_ cause integer
truncation.

To avoid `fixing' these cases, I first changed the name in libkern,
and then compile-tested every file where min/max occurred in order to
confirm that it failed -- and thus confirm that nothing shadowed
min/max -- before changing it.

I have left a handful of bootloaders that are too annoying to
compile-test, and some dead code:

cobalt ews4800mips hp300 hppa ia64 luna68k vax
acorn32/if_ie.c (not included in any kernels)
macppc/if_gm.c (superseded by gem(4))

It should be easy to fix the fallout once identified -- this way of
doing things fails safe, and the goal here, after all, is to _avoid_
silent integer truncations, not introduce them.

Maybe one day we can reintroduce min/max as type-generic things that
never silently truncate. But we should avoid doing that for a while,
so that existing code has a chance to be detected by the compiler for
conversion to uimin/uimax without changing the semantics until we can
properly audit it all. (Who knows, maybe in some cases integer
truncation is actually intended!)

1.140 Fri Mar 21 21:55:00 GMT 2008 ad branches: 1.140.2; 1.140.4;
Catch up with descriptor handling changes. See kern_descrip.c revision
1.173 for details.

Completed in 138 milliseconds

1234567891011>>