kern/169320: [libc] [patch] Enhancement to allow fopen() to set

Jukka A. Ukkonen jau at iki.fi
Thu Nov 8 08:00:02 UTC 2012


The following reply was made to PR kern/169320; it has been noted by GNATS.

From: jau at iki.fi (Jukka A. Ukkonen)
To: jilles at stack.nl (Jilles Tjoelker)
Cc: bug-followup at FreeBSD.org
Subject: Re: kern/169320: [libc] [patch] Enhancement to allow fopen() to set
Date: Thu, 8 Nov 2012 09:39:20 +0200 (EET)

 Quoting Jilles Tjoelker:
 > 
 > Although the new fopen() flag can be emulated via
 > open(O_CLOEXEC)/fdopen() as done in lib/libc/gen/fstab.c, I don't like
 > having that complication all over libc.
 
 Exactly.
 When I started hunting down all those places where O_CLOEXEC would be
 the proper approach I came to the same exact same conclusion.
 There would be a whole lot of pointless complexity due to open()+fdopen()
 being replicated all over the place.
 
 > I have written a patch almost entirely from scratch, though. I think
 > blindly accepting any order restricts future possibilities too much
 > (perhaps we want to put key/value pairs in the mode string at some
 > point, for example) and not necessary. C11 is very clear that the 'x'
 > option must come after any '+' or 'b' options. I decided that the 'e'
 > option must come after any '+, 'b' or 'x' options.
 
 Key value pairs have nothing to do with the order of the flags as
 long as the value always follows the key flag character(s).
 Proper free flow left to right parse would be much more flexible.
 So, I remain a bit suspicious about strict ordering of the flags.
 
 > I also added code to use the 'e' option for freopen() and fdopen().
 
 Splendid.
 
 
 	Cheers,
 		// jau
 .---  ..-  -.-  -.-  .-    .-  .-.-.-    ..-  -.-  -.-  ---  -.  .  -.
   /    Jukka A. Ukkonen,                             Oxit Ltd, Finland
  /__   M.Sc. (sw-eng & cs)                    (Phone) +358-500-606-671
    /   Internet: Jukka.Ukkonen(a)Oxit.Fi
   /    Internet: jau(a)iki.fi
  v
         .---  .-  ..-  ...-.-  ..  -.-  ..  .-.-.-  ..-.  ..
 + + + + My opinions are mine and mine alone, not my employers. + + + +


More information about the freebsd-bugs mailing list