Home > Archive > Tcl > March 2004 > TIP #183: Add a Binary Flag to [open]
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
TIP #183: Add a Binary Flag to [open]
|
|
| Andreas Leitgeb 2004-03-27, 12:27 am |
|
TIP #183: ADD A BINARY FLAG TO [OPEN]
=======================================
Version: $Revision: 1.1 $
Author: Andreas Leitgeb <avl_at_logic.at>
State: Draft
Type: Project
Tcl-Version: 8.5
Vote: Pending
Created: Wednesday, 24 March 2004
URL: http://purl.org/tcl/tip/183.html
WebEdit: http://purl.org/tcl/tip/edit/183
Post-History:
-------------------------------------------------------------------------
ABSTRACT
==========
To handle binary files, one currently has to open the file, and then in
a second step *fconfigure* it with *-translation binary*. This TIP
proposes to add a flag "b" to open's /access/-argument to set initial
translation to binary (rather than auto).
RATIONALE
===========
ANSI-C /fopen()/ supports an additional flag "b" in the mode- parameter
especially for non-POSIX platforms, where it makes sure that no
conversion takes place at reading or writing. The manual page for open
mentions that [fconfigure] should be used as a substitute for the
missing "b"-flag but I don't see anything wrong with a "b" flag as a
possible shortcut for this [fconfigure]-call, so this TIP proposes that
the /access/ argument to *open* should support *b* as an additional
letter (anywhere within the argument when used in the first form
documented on the manual page) which will cause the initial
configuration of the channel to be suitable for reading and/or writing
binary data.
Thus, for an expectedly very little implementation effort, we can
simplify:
set fd [open $fname "w"]; fconfigure $fd -translation binary
to:
set fd [open $fname "wb"]
which looks much more concise for such a common task.
This extra flag would only affect the initial translation state.
ENHANCEMENT
=============
Tcl's [open] also tries to adopt the POSIX /open()/ parameters (i.e.
the second form documented for the /access/ parameter on the manual
page.) POSIX's /open()/ doesn't know about binary or non-binary files,
but Tcl does, so a new keyword "BINARY" could be introduced to offer
this feature also to those who prefer list-of-flags syntax.
COPYRIGHT
===========
This document has been placed in the public domain.
-------------------------------------------------------------------------
TIP AutoGenerator - written by Donal K. Fellows
[[Send Tcl/Tk announcements to tcl-announce@mitchell.org
Announcements archived at http://groups.yahoo.com/group/tcl_announce/
Send administrivia to tcl-announce-request@mitchell.org
Tcl/Tk at http://tcl.tk/ ]]
| |
| Andreas Leitgeb 2004-03-27, 12:27 am |
| Andreas Leitgeb <avl@logic.at> wrote:
> TIP #183: ADD A BINARY FLAG TO [OPEN]
> To handle binary files, one currently has to open the file, and then in
> a second step *fconfigure* it with *-translation binary*. This TIP
> proposes to add a flag "b" to open's /access/-argument to set initial
> translation to binary (rather than auto).
I've received (by email) an opinion that I do not share, but also
do not want to be unheard. Here is the substantial quote:
" ... one should consider the slope one's on before starting the
" slippery slide. If we're going down this route, it seems natural
" to change [open] to accept *all* flags that are allowed in
" [fconfigure]. Why stop at -translation binary?
and:
" One should also not forget about [socket] and other commands that open
" communication channels, e.g. exec; if we allow flags to [open], it makes
" sense to have those flags also for those other commands.
If some shortcut is possible/reasonable just for a limited subset
of possible cases, this doesn't in my opinion mean that it is
necessarily bad. Take for example the $varname shortcut for
[set varname]: the former surely has some more or less severe
limitations, but still: without $varname, tcl would be far too
clumsy to use.
There is no other fconfigurable thing for files, that is even nearly
as common as setting binary-mode. Also, it's the only frequently used
fconf-action that can be represented by a on/off-flag.
For sockets, maybe at some later time someone may also suggest a
"-binary"-flag, but it's not part of this TIP, and it likely depends
on how common binary sockets are going to be perceived to be.
So this is, why I think the slope is not all that steep.
|
|
|
|
|