0000818: fmemopen should allow 0-size buffer - Austin Group Defect Tracker

Austin Group Defect Tracker

Aardvark Mark IV

Viewing Issue Simple Details [ Jump to Notes ]

[ Issue History ] [ Print ]

ID

Category

Severity

Type

Date Submitted

Last Update

0000818

[1003.1(2013)/Issue7+TC1] Shell and Utilities

Objection

Error

2014-01-30 04:04

2019-06-10 08:54

Reporter

eblake

View Status

public

Assigned To

Priority

normal

Resolution

Accepted As Marked

Status

Closed

Name

Eric Blake

Organization

Red Hat

User Reference

ebb.fmemopen

Section

fmemopen

Page Number

873

Line Number

29196

Interp Status

---

Final Accepted Text

See Note: 0002184

Summary

0000818: fmemopen should allow 0-size buffer

Description

The ERRORS section of fmemopen is clear that it shall fail for a buffer length of 0; however, the DESCRIPTION text does not describe this scenario, and a more useful behavior is to treat it as a valid file that reaches EOF on first read (similar to /dev/null). Furthermore, fmemopen was standardized based on the pre-existing behavior of glibc, and glibc originally implemented fmemopen to allow a 0-length buffer for reads (the fmemopen succeeds, and read() hits EOF immediately; rather than fmemopen failing) and for writes (if the buffer is growable, it will grow on first write; otherwise it behaves like a full device).

See this glibc bug for more details on pre-standardized behavior:
https://sourceware.org/bugzilla/show_bug.cgi?id=11216 [^]

Desired Action

Delete line 29196 [fmemopen ERRORS]:

[EINVAL] The size argument specifies a buffer size of zero.

Tags

Relationships

related to	0000657	Applied	ajosey	1003.1(2008)/Issue 7	Conditions under which fmemopen() write a NUL to the buffer are insufficiently specified
related to	0000587	Closed	ajosey	1003.1(2008)/Issue 7	fmemopen() initial buffer size for null pointer case

Notes
(0002119) jsm28 (reporter) 2014-01-30 15:10	Please note that the fmemopen interface is also included in ISO/IEC TR 24731-2:2010. Thus, any issues with that interface (including any others previously addressed or in the process of being addressed) should be coordinated with WG14 (presumably through the existing liaison) so that TR 24731-2 can remain consistent with POSIX, if not already coordinated. (That TR also has open_memstream, asprintf, vasprintf, scanf/wscanf %m, getdelim, getline, strdup, strndup, open_wmemstream, aswprintf, vaswprintf, getwdelim and getwline.)

(0002184) nick (manager) 2014-03-13 16:28	Delete line 29196. Add a new paragraph after 29200: [EINVAL] The size argument specifies a buffer size of zero and the implementation does not support this. Add to Future Directions after line 29235 A future revision of this standard may require support of zero length buffer streams explicitly.

Issue History
Date Modified	Username	Field	Change
2014-01-30 04:04	eblake	New Issue
2014-01-30 04:04	eblake	Name	=> Eric Blake
2014-01-30 04:04	eblake	Organization	=> Red Hat
2014-01-30 04:04	eblake	User Reference	=> ebb.fmemopen
2014-01-30 04:04	eblake	Section	=> fmemopen
2014-01-30 04:04	eblake	Page Number	=> (page or range of pages)
2014-01-30 04:04	eblake	Line Number	=> (Line or range of lines)
2014-01-30 04:04	eblake	Interp Status	=> ---
2014-01-30 04:06	eblake	Relationship added	related to 0000657
2014-01-30 04:06	eblake	Relationship added	related to 0000587
2014-01-30 15:10	jsm28	Note Added: 0002119
2014-03-13 16:14	nick	Tag Attached: C11
2014-03-13 16:28	nick	Page Number	(page or range of pages) => 873
2014-03-13 16:28	nick	Line Number	(Line or range of lines) => 29196
2014-03-13 16:28	nick	Note Added: 0002184
2014-03-13 16:28	nick	Status	New => Resolved
2014-03-13 16:28	nick	Resolution	Open => Accepted As Marked
2014-03-13 16:28	nick	Final Accepted Text	=> See Note: 0002184
2014-03-13 16:29	nick	Tag Attached: tc2-2008
2019-06-10 08:54	agadmin	Status	Resolved => Closed

Mantis 1.1.6[^]

Copyright © 2000 - 2008 Mantis Group