Re: run(4) firmware update; please test
On Fri, May 16, 2014 at 02:38:49PM +, Alexey Suslikov wrote: Please take a look at my (unfinished) attempt to bring MediaTek/Ralink RT5370/RT5372 support to run(4). http://marc.info/?l=openbsd-techm=138903287819764w=2 I did take a look at this some time ago. After looking at FreeBSD's run driver, it became apparent that they've done so much work they've effectively become the new run(4) upstream. Instead of using your diff as a base I deviced to go over the entire diff between OpenBSD's and FreeBSD's run drivers and pluck all changes related to new hardware support. The result effectively includes your diff and much more. FreeBSD have done even more (IBSS and hostap support are particularly interesting), so there's still more work to do if you'd like to help. I've got run0: MAC/BBP RT5390 (rev 0x0502), RF RT5370 (MIMO 1T1R) working now (by switching to the correct firmware image ;), and will send my diff soon.
Re: support for newer run(4) devices
On Sat, May 17, 2014 at 03:50:46PM +0200, Stefan Sperling wrote: I still have to run this through make release to ensure it won't break the floppies on i386/amd64/sgi. So please don't put into release builds unless you're willing to help with that. If you can run an sgi release build, please do. I don't have sgi hardware. make release on loongson should also be tested. Can anyone help?
crypto/stack.c reallocarray
Should be a straigtforward conversion.
Index: stack.c
===
RCS file: /cvs/src/lib/libssl/src/crypto/stack/stack.c,v
retrieving revision 1.10
diff -u -p -r1.10 stack.c
--- stack.c 20 Apr 2014 13:54:10 - 1.10
+++ stack.c 17 May 2014 15:29:09 -
@@ -98,8 +98,7 @@ sk_dup(_STACK *sk)
if ((ret = sk_new(sk-comp)) == NULL)
goto err;
- s = (char **)realloc((char *)ret-data,
- (unsigned int)sizeof(char *) * sk-num_alloc);
+ s = reallocarray(ret-data, sk-num_alloc, sizeof(char *));
if (s == NULL)
goto err;
ret-data = s;
@@ -131,7 +130,7 @@ sk_new(int (*c)(const void *, const void
if ((ret = malloc(sizeof(_STACK))) == NULL)
goto err;
- if ((ret-data = malloc(sizeof(char *) * MIN_NODES)) == NULL)
+ if ((ret-data = reallocarray(NULL, MIN_NODES, sizeof(char *))) == NULL)
goto err;
for (i = 0; i MIN_NODES; i++)
ret-data[i] = NULL;
@@ -155,8 +154,7 @@ sk_insert(_STACK *st, void *data, int lo
if (st == NULL)
return 0;
if (st-num_alloc = st-num + 1) {
- s = realloc((char *)st-data,
- (unsigned int)sizeof(char *) * st-num_alloc * 2);
+ s = reallocarray(st-data, st-num_alloc, 2 * sizeof(char *));
if (s == NULL)
return (0);
st-data = s;
@@ -296,7 +294,7 @@ sk_zero(_STACK *st)
return;
if (st-num = 0)
return;
- memset((char *)st-data, 0, sizeof(st-data)*st-num);
+ memset(st-data, 0, sizeof(st-data)*st-num);
st-num = 0;
}
PATCH: ACPI_DEBUG - format fixes
Hi,
the following diff fixes kernel builds with ACPI_DEBUG defined.
Not sure if these are the right ones, but at least it
compiles again.
Cheers,
Fabian
Index: acpi.c
===
RCS file: /cvs/src/sys/dev/acpi/acpi.c,v
retrieving revision 1.257
diff -u -p -r1.257 acpi.c
--- acpi.c 25 Apr 2014 14:37:06 - 1.257
+++ acpi.c 16 May 2014 22:09:26 -
@@ -435,7 +435,7 @@ acpi_matchhids(struct acpi_attach_args *
if (aa-aaa_dev == NULL || aa-aaa_node == NULL)
return (0);
if (_acpi_matchhids(aa-aaa_dev, hids)) {
- dnprintf(5, driver %s matches %s\n, driver, hids);
+ dnprintf(5, driver %s matches %s\n, driver, (char *)hids);
return (1);
}
return (0);
@@ -1336,7 +1336,7 @@ acpi_map_pmregs(struct acpi_softc *sc)
break;
}
if (size addr) {
- dnprintf(50, mapping: %.4x %.4x %s\n,
+ dnprintf(50, mapping: %.4lx %.4lx %s\n,
addr, size, name);
/* Size and address exist; map register space */
Index: acpicpu.c
===
RCS file: /cvs/src/sys/dev/acpi/acpicpu.c,v
retrieving revision 1.57
diff -u -p -r1.57 acpicpu.c
--- acpicpu.c 21 Jul 2010 19:35:15 - 1.57
+++ acpicpu.c 16 May 2014 22:09:26 -
@@ -344,7 +344,7 @@ acpicpu_attach(struct device *parent, st
#ifdef ACPI_DEBUG
printf(: %s: , sc-sc_devnode-name);
printf(\n: hdr:%x pblk:%x,%x duty:%x,%x pstate:%x
- (%d throttling states)\n, sc-sc_acpi-sc_fadt-hdr_revision,
+ (%ld throttling states)\n, sc-sc_acpi-sc_fadt-hdr_revision,
sc-sc_pblk_addr, sc-sc_pblk_len, sc-sc_duty_off,
sc-sc_duty_wid, sc-sc_acpi-sc_fadt-pstate_cnt,
CPU_MAXSTATE(sc));
@@ -519,7 +519,7 @@ acpicpu_getpct(struct acpicpu_softc *sc)
goto ffh;
}
- dnprintf(10, _PCT(ctrl) : %02x %04x %02x %02x %02x %02x %016x\n,
+ dnprintf(10, _PCT(ctrl) : %02x %04x %02x %02x %02x %02x %016llx\n,
sc-sc_pct.pct_ctrl.grd_descriptor,
sc-sc_pct.pct_ctrl.grd_length,
sc-sc_pct.pct_ctrl.grd_gas.address_space_id,
@@ -528,7 +528,7 @@ acpicpu_getpct(struct acpicpu_softc *sc)
sc-sc_pct.pct_ctrl.grd_gas.access_size,
sc-sc_pct.pct_ctrl.grd_gas.address);
- dnprintf(10, _PCT(status): %02x %04x %02x %02x %02x %02x %016x\n,
+ dnprintf(10, _PCT(status): %02x %04x %02x %02x %02x %02x %016llx\n,
sc-sc_pct.pct_status.grd_descriptor,
sc-sc_pct.pct_status.grd_length,
sc-sc_pct.pct_status.grd_gas.address_space_id,
Index: acpiec.c
===
RCS file: /cvs/src/sys/dev/acpi/acpiec.c,v
retrieving revision 1.48
diff -u -p -r1.48 acpiec.c
--- acpiec.c2 Jul 2013 18:37:47 - 1.48
+++ acpiec.c16 May 2014 22:09:26 -
@@ -142,9 +142,10 @@ acpiec_read_data(struct acpiec_softc *sc
u_int8_tval;
acpiec_wait(sc, EC_STAT_OBF, EC_STAT_OBF);
- dnprintf(40, acpiec: read_data\n, (int)val);
val = bus_space_read_1(sc-sc_data_bt, sc-sc_data_bh, 0);
+ dnprintf(40, acpiec: read_data %d\n, (int)val);
+
return (val);
}
@@ -482,7 +483,7 @@ acpiec_getcrs(struct acpiec_softc *sc, s
/* XXX: todo - validate _CRS checksum? */
ecdtdone:
- dnprintf(10, %s: Data: 0x%x, S/C: 0x%x\n,
+ dnprintf(10, %s: Data: 0x%lx, S/C: 0x%lx\n,
DEVNAME(sc), ec_data, ec_sc);
if (ctype == GAS_SYSTEM_IOSPACE)
Index: atk0110.c
===
RCS file: /cvs/src/sys/dev/acpi/atk0110.c,v
retrieving revision 1.8
diff -u -p -r1.8 atk0110.c
--- atk0110.c 21 Feb 2014 16:25:57 - 1.8
+++ atk0110.c 16 May 2014 22:09:27 -
@@ -448,13 +448,13 @@ aibs_getvalue(struct aibs_softc *sc, int
}
if (aml_evalnode(sc-sc_acpi, n, 1, req, res)) {
- dprintf(%s: %s: %i: evaluation failed\n,
+ dprintf(%s: %s: %lld: evaluation failed\n,
DEVNAME(sc), n-name, i);
aml_freevalue(res);
return (-1);
}
if (res.type != type) {
- dprintf(%s: %s: %i: not an integer: type %i\n,
+ dprintf(%s: %s: %lld: not an integer: type %i\n,
DEVNAME(sc), n-name, i, res.type);
aml_freevalue(res);
return (-1);
@@ -462,14 +462,14 @@ aibs_getvalue(struct aibs_softc *sc, int
if (sc-sc_mode) {
if (res.length sizeof(ret)) {
- dprintf(%s: %s: %i: result buffer too small\n,
+ dprintf(%s: %s: %lld: result buffer too small\n,
PATCH: acpibat - expose capacity as sensor
Hi,
i want to expose capacity (full capacity design)
as a sensor like the rest.
This sensor will be used in an upcoming diff to upower to
expose energy-full-design and capacity properties if
this patch gets merged.
Both patches together will fix wrong notifications about
broken batteries in KDE4.
Cheers,
Fabian
Index: acpidev.h
===
RCS file: /cvs/src/sys/dev/acpi/acpidev.h,v
retrieving revision 1.33
diff -u -p -r1.33 acpidev.h
--- acpidev.h 13 Jul 2012 10:37:40 - 1.33
+++ acpidev.h 17 May 2014 15:51:29 -
@@ -278,7 +278,7 @@ struct acpibat_softc {
struct acpibat_bst sc_bst;
volatile intsc_bat_present;
- struct ksensor sc_sens[8];
+ struct ksensor sc_sens[9];
struct ksensordev sc_sensdev;
};
Index: acpibat.c
===
RCS file: /cvs/src/sys/dev/acpi/acpibat.c,v
retrieving revision 1.59
diff -u -p -r1.59 acpibat.c
--- acpibat.c 16 Oct 2011 11:59:21 - 1.59
+++ acpibat.c 17 May 2014 15:51:29 -
@@ -163,6 +163,12 @@ acpibat_monitor(struct acpibat_softc *sc
sensor_attach(sc-sc_sensdev, sc-sc_sens[7]);
sc-sc_sens[7].value = sc-sc_bst.bst_voltage * 1000;
+ strlcpy(sc-sc_sens[8].desc, capacity,
+ sizeof(sc-sc_sens[8].desc));
+ sc-sc_sens[8].type = type;
+ sensor_attach(sc-sc_sensdev, sc-sc_sens[8]);
+ sc-sc_sens[8].value = sc-sc_bif.bif_capacity * 1000;
+
sensordev_install(sc-sc_sensdev);
}
@@ -176,7 +182,7 @@ acpibat_refresh(void *arg)
sc-sc_devnode-name);
if (!sc-sc_bat_present) {
- for (i = 0; i 8; i++) {
+ for (i = 0; i 9; i++) {
sc-sc_sens[i].value = 0;
sc-sc_sens[i].status = SENSOR_S_UNSPEC;
sc-sc_sens[i].flags = SENSOR_FINVALID;
@@ -273,6 +279,16 @@ acpibat_refresh(void *arg)
sc-sc_sens[7].value = sc-sc_bst.bst_voltage * 1000;
sc-sc_sens[7].status = SENSOR_S_UNSPEC;
sc-sc_sens[7].flags = 0;
+ }
+
+ if (sc-sc_bif.bif_capacity == BIF_UNKNOWN) {
+ sc-sc_sens[8].value = 0;
+ sc-sc_sens[8].status = SENSOR_S_UNKNOWN;
+ sc-sc_sens[8].flags = SENSOR_FUNKNOWN;
+ } else {
+ sc-sc_sens[8].value = sc-sc_bif.bif_capacity * 1000;
+ sc-sc_sens[8].status = SENSOR_S_UNSPEC;
+ sc-sc_sens[8].flags = 0;
}
acpi_record_event(sc-sc_acpi, APM_POWER_CHANGE);
}
Re: run(4) firmware update; please test
On Sat, May 17, 2014 at 02:15:46PM +0200, Stefan Sperling wrote: On Fri, May 16, 2014 at 01:30:58PM +0200, Gerhard Roth wrote: He's using a model that requires a firmware-blob different from the one of all other testers (run-rt2870 vs. run-rt3071). That might explain, why he's the only one who got troubles with the new FW. Yes, and I just realized that in my previous diff, I accidentally used the rt2870 image as rt3071 image. $ md5 obj/run-rt* MD5 (obj/run-rt2870) = 039127f8c1acf7978a410ffcf563 MD5 (obj/run-rt3071) = 039127f8c1acf7978a410ffcf563 Here's a hopefully fixed version. Works for me on : run0 at uhub1 port 1 Ralink 11g Adapter rev 2.00/1.01 addr 3 run0: MAC/BBP RT3070 (rev 0x0201), RF RT2020 (MIMO 1T1R), address 1c:af:f7:11:9c:1b MD5 (/etc/firmware/run-rt3071) = 0e877b1acde54b05bef0bc0ca08478e7 -- Matthieu Herrb
Re: support for newer run(4) devices
On Sat, May 17, 2014 at 03:50:46PM +0200, Stefan Sperling wrote: This ports many of kevlo's changes in FreeBSD to support newer run(4) devices. Requires the firmware update at http://marc.info/?l=openbsd-techm=140032898325109w=2 I'm posting this version of the diff now for anyone who'd like to help by testing devices. I still have to run this through make release to ensure it won't break the floppies on i386/amd64/sgi. So please don't put into release builds unless you're willing to help with that. If you can run an sgi release build, please do. I don't have sgi hardware. Also no regression on my run: run0 at uhub1 port 1 Ralink 11g Adapter rev 2.00/1.01 addr 3 run0: MAC/BBP RT3070 (rev 0x0201), RF RT2020 (MIMO 1T1R), address 1c:af:f7:11:9c:1b
stack memmove
sunos doesn't have memmove? I guess sunos won't have libressl.
Index: stack.c
===
RCS file: /cvs/src/lib/libssl/src/crypto/stack/stack.c,v
retrieving revision 1.11
diff -u -p -r1.11 stack.c
--- stack.c 17 May 2014 17:35:04 - 1.11
+++ stack.c 17 May 2014 17:39:28 -
@@ -163,19 +163,9 @@ sk_insert(_STACK *st, void *data, int lo
if ((loc = (int)st-num) || (loc 0))
st-data[st-num] = data;
else {
- int i;
- char **f, **t;
-
- f = st-data;
- t = (st-data[1]);
- for (i = st-num; i = loc; i--)
- t[i] = f[i];
-
-#ifdef undef /* no memmove on sunos :-( */
memmove((st-data[loc + 1]),
(st-data[loc]),
sizeof(char *)*(st-num - loc));
-#endif
st-data[loc] = data;
}
st-num++;
@@ -198,21 +188,14 @@ void *
sk_delete(_STACK *st, int loc)
{
char *ret;
- int i, j;
if (!st || (loc 0) || (loc = st-num))
return NULL;
ret = st-data[loc];
if (loc != st-num - 1) {
- j = st-num - 1;
- for (i = loc; i j; i++)
- st-data[i] = st-data[i + 1];
- /* In theory memcpy is not safe for this
-* memcpy( (st-data[loc]),
-* (st-data[loc+1]),
-* sizeof(char *)*(st-num-loc-1));
-*/
+ memmove((st-data[loc]), (st-data[loc+1]),
+ sizeof(char *)*(st-num-loc-1));
}
st-num--;
return (ret);
s/REGRESS_DEPENDS/TEST_DEPENDS/ in packages-specs.7
Index: infrastructure/mk/README.internals === RCS file: /cvs/ports/infrastructure/mk/README.internals,v retrieving revision 1.11 diff -u -p -r1.11 README.internals --- infrastructure/mk/README.internals 11 Feb 2014 10:34:34 - 1.11 +++ infrastructure/mk/README.internals 17 May 2014 17:43:52 - @@ -302,7 +302,7 @@ Dependency variables Old legacy dependency styles are gone, so the compat code went away. The code has to deal with BUILD_DEPENDS, LIB_DEPENDS, RUN_DEPENDS, -REGRESS_DEPENDS, WANTLIB and RUN_DEPENDS-* LIB_DEPENDS-*, WANTLIB-* +TEST_DEPENDS, WANTLIB and RUN_DEPENDS-* LIB_DEPENDS-*, WANTLIB-* There is obviously completely different treatment for WANTLIB* and *DEPENDS*. Also, BUILD* stuff gets to inherit from LIB_DEPENDS* stripped
Re: s/REGRESS_DEPENDS/TEST_DEPENDS/ in packages-specs.7
On Sat, May 17, 2014 at 07:51:25PM +0200, Fabian Raetz wrote: Index: infrastructure/mk/README.internals === RCS file: /cvs/ports/infrastructure/mk/README.internals,v retrieving revision 1.11 diff -u -p -r1.11 README.internals --- infrastructure/mk/README.internals11 Feb 2014 10:34:34 - 1.11 +++ infrastructure/mk/README.internals17 May 2014 17:43:52 - @@ -302,7 +302,7 @@ Dependency variables Old legacy dependency styles are gone, so the compat code went away. The code has to deal with BUILD_DEPENDS, LIB_DEPENDS, RUN_DEPENDS, -REGRESS_DEPENDS, WANTLIB and RUN_DEPENDS-* LIB_DEPENDS-*, WANTLIB-* +TEST_DEPENDS, WANTLIB and RUN_DEPENDS-* LIB_DEPENDS-*, WANTLIB-* There is obviously completely different treatment for WANTLIB* and *DEPENDS*. Also, BUILD* stuff gets to inherit from LIB_DEPENDS* stripped This time with correct patch. Sorry! Index: packages-specs.7 === RCS file: /cvs/src/share/man/man7/packages-specs.7,v retrieving revision 1.24 diff -u -p -r1.24 packages-specs.7 --- packages-specs.712 Oct 2012 16:17:02 - 1.24 +++ packages-specs.717 May 2014 17:46:25 - @@ -197,7 +197,7 @@ Packages may depend on other packages, a Makefile, in a .Ev BUILD_DEPENDS , .Ev LIB_DEPENDS , -.Ev REGRESS_DEPENDS +.Ev TEST_DEPENDS or .Ev RUN_DEPENDS . All those conform to
Re: Proposal for changes to the event(3) documentation
On Sat, May 17, 2014 at 12:10:36PM -0600, Ted Bullock wrote: On Sat, May 17, 2014 at 12:08 PM, Ted Bullock tbull...@comlore.com wrote: On Sat, May 17, 2014 at 3:33 AM, Jason McIntyre j...@kerhand.co.uk wrote: On Sat, May 17, 2014 at 03:09:03AM -0600, Ted Bullock wrote: On Fri, May 16, 2014 at 1:10 AM, Nicholas Marriott nicholas.marri...@gmail.com wrote: Hi Yes, I think this would be nice to see. We use libevent quite a lot so it'd be nice to have good documentation. Little patch below with some clarification on how to setup the library and what it's good for. I'm hoping gmail doesn't eat the patch :/ first off, i don;t want to take on the commits for this. someone else up for it? Ok Thanks Jason, here is a revised patch with including your comments I've copied tech@ here too btw. it's ok by me. jmc Index: event.3 === RCS file: /cvs/src/lib/libevent/event.3,v retrieving revision 1.43 diff -u -3 -r1.43 event.3 --- event.33 Apr 2014 13:30:05 -1.43 +++ event.317 May 2014 17:40:30 - @@ -23,7 +23,7 @@ .\ OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF .\ ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. .\ -.Dd $Mdocdate: April 3 2014 $ +.Dd $Mdocdate: May 17 2014 $ .Dt EVENT 3 .Os .Sh NAME @@ -189,15 +189,45 @@ .Fn event_asr_abort struct event_asr *eva .Sh DESCRIPTION The -.Nm event -API provides a mechanism to execute a function when a specific event -on a file descriptor occurs or after a given time has passed. +.Nm libevent +library is an asynchronous notification mechanism intended to replace +the main program loop for network and event-driven processes. +The library API executes callback functions triggered by file descriptor +activity, timeouts and signals. +Notifications are supplied using the operating system's most efficient +notification subsystem; on +.Ox +this defaults to +.Xr kqueue 2 , +although +.Xr poll 2 +and +.Xr select 2 +are also supported. .Pp -The -.Nm event -API needs to be initialized with +A one-time initialization of the libevent library must be performed by +calling either +.Fn event_init +or +.Fn event_base_new , +both of which return +.Dv NULL +in case of an error, or upon success return a heap allocated +.Vt event_base +data structure that must be passed to +.Fn event_base_free +to free its memory. .Fn event_init -before it can be used. +is used to simplify the library API for processes that need a single +event loop by setting a global +.Vt event_base +for the whole process. +Since libevent is not directly thread-safe +.Fn event_base_new +is used for multi-threaded environments to create memory independent +event loops in each thread; in these circumstances the +.Nm event_base_* +set of calls must be used. .Pp In order to process events, an application needs to call .Fn event_dispatch .
Re: Proposal for changes to the event(3) documentation
On Sat, May 17, 2014 at 12:08 PM, Ted Bullock tbull...@comlore.com wrote: On Sat, May 17, 2014 at 3:33 AM, Jason McIntyre j...@kerhand.co.uk wrote: On Sat, May 17, 2014 at 03:09:03AM -0600, Ted Bullock wrote: On Fri, May 16, 2014 at 1:10 AM, Nicholas Marriott nicholas.marri...@gmail.com wrote: Hi Yes, I think this would be nice to see. We use libevent quite a lot so it'd be nice to have good documentation. Little patch below with some clarification on how to setup the library and what it's good for. I'm hoping gmail doesn't eat the patch :/ first off, i don;t want to take on the commits for this. someone else up for it? Ok Thanks Jason, here is a revised patch with including your comments I've copied tech@ here too btw. Index: event.3 === RCS file: /cvs/src/lib/libevent/event.3,v retrieving revision 1.43 diff -u -3 -r1.43 event.3 --- event.33 Apr 2014 13:30:05 -1.43 +++ event.317 May 2014 17:40:30 - @@ -23,7 +23,7 @@ .\ OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF .\ ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. .\ -.Dd $Mdocdate: April 3 2014 $ +.Dd $Mdocdate: May 17 2014 $ .Dt EVENT 3 .Os .Sh NAME @@ -189,15 +189,45 @@ .Fn event_asr_abort struct event_asr *eva .Sh DESCRIPTION The -.Nm event -API provides a mechanism to execute a function when a specific event -on a file descriptor occurs or after a given time has passed. +.Nm libevent +library is an asynchronous notification mechanism intended to replace +the main program loop for network and event-driven processes. +The library API executes callback functions triggered by file descriptor +activity, timeouts and signals. +Notifications are supplied using the operating system's most efficient +notification subsystem; on +.Ox +this defaults to +.Xr kqueue 2 , +although +.Xr poll 2 +and +.Xr select 2 +are also supported. .Pp -The -.Nm event -API needs to be initialized with +A one-time initialization of the libevent library must be performed by +calling either +.Fn event_init +or +.Fn event_base_new , +both of which return +.Dv NULL +in case of an error, or upon success return a heap allocated +.Vt event_base +data structure that must be passed to +.Fn event_base_free +to free its memory. .Fn event_init -before it can be used. +is used to simplify the library API for processes that need a single +event loop by setting a global +.Vt event_base +for the whole process. +Since libevent is not directly thread-safe +.Fn event_base_new +is used for multi-threaded environments to create memory independent +event loops in each thread; in these circumstances the +.Nm event_base_* +set of calls must be used. .Pp In order to process events, an application needs to call .Fn event_dispatch .
Re: buffer overflow in inet_ntop4
On Sat, May 17, 2014 at 11:00, enh wrote: inet_ntop4 incorrectly mixes a user-supplied size with a self-supplied buffer: inet_ntop4(const u_char *src, char *dst, size_t size) ... char tmp[sizeof 255.255.255.255]; ... l = snprintf(tmp, size, fmt, src[0], src[1], src[2], src[3]); so if i call inet_ntop(AF_INET, ... with a size larger than INET_ADDRSTRLEN it'll overflow. Thanks. I don't really understand the purpose of the tmp when it could just print into the buf directly, but I've left that alone for now.
Re: buffer overflow in inet_ntop4
On Sat, May 17, 2014 at 02:18:22PM -0400, Ted Unangst wrote: On Sat, May 17, 2014 at 11:00, enh wrote: inet_ntop4 incorrectly mixes a user-supplied size with a self-supplied buffer: inet_ntop4(const u_char *src, char *dst, size_t size) ... char tmp[sizeof 255.255.255.255]; ... l = snprintf(tmp, size, fmt, src[0], src[1], src[2], src[3]); so if i call inet_ntop(AF_INET, ... with a size larger than INET_ADDRSTRLEN it'll overflow. Thanks. I don't really understand the purpose of the tmp when it could just print into the buf directly, but I've left that alone for now. The code certainly doesn't conform to the snprintf(buf, sizeof(buf), ...) idiom. But the size argument for snprintf is a maximum and the format string is not user-supplied so I don't see how to make inet_ntop write more bytes than sizeof(tmp). Is it possible?
