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
0001152 [1003.1(2008)/Issue 7] System Interfaces Editorial Clarification Requested 2017-06-22 07:50 2018-12-13 16:35
Reporter Villemoes View Status public  
Assigned To ajosey
Priority normal Resolution Duplicate  
Status Closed  
Name Rasmus Villemoes
Organization
User Reference
Section fmemopen
Page Number
Line Number
Interp Status ---
Final Accepted Text
Summary 0001152: Effect of modifications to buffer underlying a memory stream
Description Consider this code:
    char a[4] = "xx", b[4];
    FILE *f = fmemopen(a, 2, "r");

    fread(&b[0], 1, 1, f);
    a[1] = 'y';
    fread(&b[1], 1, 1, f);
    b[2] = '\0';
    printf("b = %s\n", b);


What is the expected contents of b[1]? I'd assume 'y', but the first fread() is there to trigger the implementation's internal buffering if it happens to do so for memory streams. And sure enough, at least with glibc the above produces "b = xx".

A setvbuf(f, NULL, _IONBF, 0) after fmemopen does make the stream behave as I'd naively expect.

fopen has the text "When opened, a stream is fully buffered if and only if it can be determined not to refer to an interactive device.", but I cannot find anything similar for fmemopen, so it's unclear whether this applies to all streams or just those created by fopen().
Desired Action Clarify what one can expect when mixing fread() and direct modifications of the underlying buffer.

Clarify the effects of setvbuf() on memory streams, and in particular, the effect of _IONBF, which seems to be necessary to get the behaviour that I naively expected.

Clarify the initial buffering mode of a stream created by fmemopen().
Tags No tags attached.
Attached Files

- Relationships
duplicate of 0001144Closedajosey May fmemopen(buf, len, "r") modify the buffer 

-  Notes
(0004185)
geoffclare (manager)
2018-12-13 16:34

We believe the changes made in the resolution of 0001144 also resolve this issue. Therefore this is being closed as a duplicate of bug 1144.

- Issue History
Date Modified Username Field Change
2017-06-22 07:50 Villemoes New Issue
2017-06-22 07:50 Villemoes Status New => Under Review
2017-06-22 07:50 Villemoes Assigned To => ajosey
2017-06-22 07:50 Villemoes Name => Rasmus Villemoes
2017-06-22 07:50 Villemoes Section => fmemopen
2018-12-13 16:34 geoffclare Interp Status => ---
2018-12-13 16:34 geoffclare Note Added: 0004185
2018-12-13 16:34 geoffclare Status Under Review => Closed
2018-12-13 16:34 geoffclare Resolution Open => Duplicate
2018-12-13 16:35 geoffclare Relationship added duplicate of 0001144


Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker