summaryrefslogtreecommitdiffstats
path: root/Objects/fileobject.c
Commit message (Collapse)AuthorAgeFilesLines
* Only release buffer after file has been closed. Fixes #800824.Martin v. Löwis2003-09-071-1/+1
| | | | Will backport to 2.2.
* SF bug 801631: file.truncate fault on windows.Tim Peters2003-09-071-74/+66
| | | | | | | | | | | | | | | | | file_truncate(): C doesn't define what fflush(fp) does if fp is open for update, and the preceding I/O operation on fp was input. On Windows, fflush() actually changes the current file position then. Because Windows doesn't support ftruncate() directly, this not only caused Python's file.truncate() to change the file position (contra our docs), it also caused the file not to change size. Repaired by getting the initial file position at the start, restoring it at the end, and tossing all the complicated micro-efficiency checks trying to avoid "provably unnecessary" seeks. file.truncate() can't be a frequent operation, and seeking to the current file position has got to be cheap anyway. Bugfix candidate.
* Patch #788249: Pass an explicit buffer to setvbuf in PyFile_SetBufSize().Martin v. Löwis2003-09-041-5/+19
| | | | Fixes #603724. Will backport to 2.3.
* Fix SF #789402, Memory leak on open()Neal Norwitz2003-08-151-0/+1
| | | | If opening a directory, the exception would leak.
* Only encode Unicode objects when printing them raw.Martin v. Löwis2003-05-181-1/+2
|
* Patch #612627: Add encoding attribute to file objects, and determineMartin v. Löwis2003-05-101-1/+41
| | | | the terminal encoding on Windows and Unix.
* Somewhere along the way, the softspace attr of file objects became read-Tim Peters2003-05-041-1/+2
| | | | only. Repaired, and added new tests to test_file.py.
* SF patch #683187, fix universal newline problems on errorNeal Norwitz2003-02-091-1/+4
|
* Allow PyFile_GetLine() to return Unicode objects. Fixes #660165.Martin v. Löwis2003-01-031-1/+24
|
* SF patch #659536: Use PyArg_UnpackTuple where possible.Raymond Hettinger2002-12-291-1/+1
| | | | | | | Obtain cleaner coding and a system wide performance boost by using the fast, pre-parsed PyArg_Unpack function instead of PyArg_ParseTuple function which is driven by a format string.
* * Objects/fileobject.cGustavo Niemeyer2002-12-171-1/+1
| | | | | (file_read): Replaced assertion with mixed sign operation by a simple comment (thank you Raymond). The algorithm is clear enough in that point.
* Fixed bugGustavo Niemeyer2002-12-161-3/+30
| | | | | | | | | | | | | | | | | [#521782] unreliable file.read() error handling * Objects/fileobject.c (file_read): Clear errors before leaving the loop in all situations, and also check if some data was read before exiting the loop with an EWOULDBLOCK exception. * Doc/lib/libstdtypes.tex * Objects/fileobject.c Document that sometimes a read() operation can return less data than what the user asked, if running in non-blocking mode. * Misc/NEWS Document the fix.
* Patch #650834: Document 'U' in file mode, remove stale variables.Martin v. Löwis2002-12-111-5/+1
|
* Fix --disable-unicode compilation problems.Martin v. Löwis2002-11-211-0/+4
|
* Patch 594001: PEP 277 - Unicode file name support for Windows NT.Mark Hammond2002-10-031-13/+83
|
* Reflow long lines.Jeremy Hylton2002-08-141-26/+32
|
* Make readahead functions staticNeal Norwitz2002-08-061-5/+8
|
* SF patch 580331 by Oren Tirosh: make file objects their own iterator.Guido van Rossum2002-08-061-31/+130
| | | | | | | | | | | | | | | | | | | | | | For a file f, iter(f) now returns f (unless f is closed), and f.next() is similar to f.readline() when EOF is not reached; however, f.next() uses a readahead buffer that messes up the file position, so mixing f.next() and f.readline() (or other methods) doesn't work right. Calling f.seek() drops the readahead buffer, but other operations don't. The real purpose of this change is to reduce the confusion between objects and their iterators. By making a file its own iterator, it's made clearer that using the iterator modifies the file object's state (in particular the current position). A nice side effect is that this speeds up "for line in f:" by not having to use the xreadlines module. The f.xreadlines() method is still supported for backwards compatibility, though it is the same as iter(f) now. (I made some cosmetic changes to Oren's code, and added a test for "file closed" to file_iternext() and file_iter().)
* WINDOWS_LEAN_AND_MEAN: There is no such symbol, although a very fewTim Peters2002-07-141-1/+1
| | | | | | | MSDN sample programs use it, apparently in error. The correct name is WIN32_LEAN_AND_MEAN. After switching to the correct name, in two cases more was needed because the code actually relied on things that disappear when WIN32_LEAN_AND_MEAN is defined.
* Patch #569753: Remove support for WIN16.Martin v. Löwis2002-06-301-3/+3
| | | | Rename all occurrences of MS_WIN32 to MS_WINDOWS.
* Patch #568124: Add doc string macros.Martin v. Löwis2002-06-131-30/+36
|
* file_doc: Add some description of the U mode character, but only whenBarry Warsaw2002-05-221-0/+10
| | | | WITH_UNIVERSAL_NEWLINES is enabled.
* Repair widespread misuse of _PyString_Resize. Since it's clear peopleTim Peters2002-04-271-3/+1
| | | | | | | | | | | | | | | | | | | | | | don't understand how this function works, also beefed up the docs. The most common usage error is of this form (often spread out across gotos): if (_PyString_Resize(&s, n) < 0) { Py_DECREF(s); s = NULL; goto outtahere; } The error is that if _PyString_Resize runs out of memory, it automatically decrefs the input string object s (which also deallocates it, since its refcount must be 1 upon entry), and sets s to NULL. So if the "if" branch ever triggers, it's an error to call Py_DECREF(s): s is already NULL! A correct way to write the above is the simpler (and intended) if (_PyString_Resize(&s, n) < 0) goto outtahere; Bugfix candidate.
* Py_UniversalNewlineFread(): small speed boost on non-Windows boxes.Tim Peters2002-04-211-3/+3
|
* Py_UniversalNewlineFread(): Many changes.Tim Peters2002-04-211-37/+47
| | | | | | | | | | | | | | | | | | | | + Continued looping until n bytes in the buffer have been filled, not just when n bytes have been read from the file. This repairs the bug that f.readlines() only sucked up the first 8192 bytes of the file on Windows when universal newlines was enabled and f was opened in U mode (see Python-Dev -- this was the ultimate cause of the test_inspect.py failure). + Changed prototye to take a char* buffer (void* doesn't make much sense). + Squashed size_t vs int mismatches (in particular, besides the unsigned vs signed distinction, size_t may be larger than int). + Gets out under all error conditions now (it's possible for fread() to suffer an error even if it returns a number larger than 0 -- any "short read" is an error or EOF condition). + Rearranged and simplified declarations.
* Mass checkin of universal newline support.Jack Jansen2002-04-141-17/+294
| | | | | | | | Highlights: import and friends will understand any of \r, \n and \r\n as end of line. Python file input will do the same if you use mode 'U'. Everything can be disabled by configuring with --without-universal-newlines. See PEP278 for details.
* PyObject_Del can now be used as a function designator.Neil Schemenauer2002-04-121-1/+1
|
* SF bug 538827: Python open w/ MSVC6: bad error msgs.Tim Peters2002-04-081-2/+15
| | | | | | | open_the_file: Some (not all) flavors of Windows set errno to EINVAL when passed a syntactically invalid filename. Python turned that into an incomprehensible complaint about the mode string. Fixed by special-casing MSVC.
* isatty() should return a bool.Guido van Rossum2002-04-071-1/+1
|
* Add the 'bool' type and its values 'False' and 'True', as described inGuido van Rossum2002-04-031-3/+3
| | | | | | | | | | | | | PEP 285. Everything described in the PEP is here, and there is even some documentation. I had to fix 12 unit tests; all but one of these were printing Boolean outcomes that changed from 0/1 to False/True. (The exception is test_unicode.py, which did a type(x) == type(y) style comparison. I could've fixed that with a single line using issubtype(x, type(y)), but instead chose to be explicit about those places where a bool is expected. Still to do: perhaps more documentation; change standard library modules to return False/True from predicates.
* Convert file.readinto() to stop using METH_OLDARGS & PyArg_Parse.Neal Norwitz2002-04-011-2/+2
| | | | Add test for file.readinto().
* Grow the string buffer at a mildly exponential rate for the getc versionNeil Schemenauer2002-03-231-13/+16
| | | | | | | | of get_line. This makes test_bufio finish in 1.7 seconds instead of 57 seconds on my machine (with Py_DEBUG defined). Also, rename the local variables n1 and n2 to used_v_size and total_v_size.
* Give Python a debug-mode pymalloc, much as sketched on Python-Dev.Tim Peters2002-03-231-8/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When WITH_PYMALLOC is defined, define PYMALLOC_DEBUG to enable the debug allocator. This can be done independent of build type (release or debug). A debug build automatically defines PYMALLOC_DEBUG when pymalloc is enabled. It's a detected error to define PYMALLOC_DEBUG when pymalloc isn't enabled. Two debugging entry points defined only under PYMALLOC_DEBUG: + _PyMalloc_DebugCheckAddress(const void *p) can be used (e.g., from gdb) to sanity-check a memory block obtained from pymalloc. It sprays info to stderr (see next) and dies via Py_FatalError if the block is detectably damaged. + _PyMalloc_DebugDumpAddress(const void *p) can be used to spray info about a debug memory block to stderr. A tiny start at implementing "API family" checks isn't good for anything yet. _PyMalloc_DebugRealloc() has been optimized to do little when the new size is <= old size. However, if the new size is larger, it really can't call the underlying realloc() routine without either violating its contract, or knowing something non-trivial about how the underlying realloc() works. A memcpy is always done in this case. This was a disaster for (and only) one of the std tests: test_bufio creates single text file lines up to a million characters long. On Windows, fileobject.c's get_line() uses the horridly funky getline_via_fgets(), which keeps growing and growing a string object hoping to find a newline. It grew the string object 1000 bytes each time, so for a million-character string it took approximately forever (I gave up after a few minutes). So, also: fileobject.c, getline_via_fgets(): When a single line is outrageously long, grow the string object at a mildly exponential rate, instead of just 1000 bytes at a time. That's enough so that a debug-build test_bufio finishes in about 5 seconds on my Win98SE box. I'm curious to try this on Win2K, because it has very different memory behavior than Win9X, and test_bufio always took a factor of 10 longer to complete on Win2K. It *could* be that the endless reallocs were simply killing it on Win2K even in the release build.
* Check in (hopefully) corrected version of last change.Neil Schemenauer2002-03-231-0/+29
|
* Undo last commit. It's causing the tests to file.Neil Schemenauer2002-03-221-28/+0
|
* Disallow open()ing of directories. Closes SF bug 487277.Neil Schemenauer2002-03-221-0/+28
|
* Patch #530105: Allow file object may to be subtypedMartin v. Löwis2002-03-151-11/+0
|
* Change Windows file.truncate() to (a) restore the original file position,Tim Peters2002-03-121-27/+40
| | | | | | | | | | | | and (b) stop trying to prevent file growth. Beef up the file.truncate() docs. Change test_largefile.py to stop assuming that f.truncate() moves the file pointer to the truncation point, and to verify instead that it leaves the file position alone. Remove the test for what happens when a specified size exceeds the original file size (it's ill-defined, according to the Single Unix Spec).
* file_truncate(): provide full "large file" support on Windows, byTim Peters2002-03-111-20/+55
| | | | | | | | | | | | | | | | | | | | dropping MS's inadequate _chsize() function. This was inspired by SF patch 498109 ("fileobject truncate support for win32"), which I rejected. libstdtypes.tex: Someone who knows should update the availability blurb. For example, if it's available on Linux, it would be good to say so. test_largefile: Uncommented the file.truncate() tests, and reworked to do more. The old comment about "permission errors" in the truncation tests under Windows was almost certainly due to that the file wasn't open for *write* access at this point, so of course MS wouldn't let you truncate it. I'd be appalled if a Unixish system did. CAUTION: Someone should run this test on Linux (etc) too. The truncation part was commented out before. Note that test_largefile isn't run by default.
* OS/2 EMX port changes (Objects part of patch #450267):Andrew MacIntyre2002-02-261-0/+4
| | | | | | | | | | | | Objects/ fileobject.c stringobject.c unicodeobject.c This commit doesn't include the cleanup patches for stringobject.c and unicodeobject.c which are shown separately in the patch manager. Those patches will be regenerated and applied in a subsequent commit, so as to preserve a fallback position (this commit to those files).
* Include <unistd.h> in Python.h. Fixes #500924.Martin v. Löwis2002-01-121-4/+0
|
* SF Patch #494863, file.xreadlines() should raise ValueError if file is closedNeal Norwitz2002-01-011-0/+2
| | | | | This makes xreadlines behave like all other file methods (other than close() which just returns).
* Merged changes made on r22b2-branch between r22b2 and r22b2-mac (theJack Jansen2001-11-301-2/+7
| | | | changes from start of branch upto r22b2 were already merged, of course).
* PyFile_WriteString(): change prototype so that the string arg isTim Peters2001-11-281-1/+1
| | | | | | const char* instead of char*. The change is conceptually correct, and indirectly fixes a compiler wng introduced when somebody else innocently passed a const char* to this function.
* open_the_file(): Explicitly set errno to 0 before calling fopen().Tim Peters2001-11-091-0/+1
|
* open_the_file(): this routine has a borrowed reference to the fileTim Peters2001-11-091-1/+0
| | | | | | object, so the "Metroworks only" section should not decref it in case of error (the caller is responsible for decref'ing in case of error -- and does).
* Fix SF buf #476953: Bad more for opening file gives bad msg.Jeremy Hylton2001-11-091-2/+6
| | | | | | If fopen() fails with EINVAL it means that the mode argument is invalid. Return the mode in the error message instead of the filename.
* fix forMichael W. Hudson2001-10-311-2/+2
| | | | | | [ #476557 ] Wrong error message for file.write(a, b) Makes file.write a METH_VARARGS function.
* SF patch #474175 (Jay T Miller): file.readinto arg parsing bugGuido van Rossum2001-10-231-1/+2
| | | | | | | | | | | | | | | | | | | | | | The C-code in fileobject.readinto(buffer) which parses the arguments assumes that size_t is interchangeable with int: size_t ntodo, ndone, nnow; if (f->f_fp == NULL) return err_closed(); if (!PyArg_Parse(args, "w#", &ptr, &ntodo)) return NULL; This causes a problem on Alpha / Tru64 / OSF1 v5.1 where size_t is a long and sizeof(long) != sizeof(int). The patch I'm proposing declares ntodo as an int. An alternative might be to redefine w# to expect size_t. [We can't change w# because there are probably third party modules relying on it. GvR]
* Band-aid solution to SF bug #470634: readlines() on linux requires 2 ^D's.Guido van Rossum2001-10-121-4/+11
| | | | | | | | | | | | | | | | The problem is that if fread() returns a short count, we attempt another fread() the next time through the loop, and apparently glibc clears or ignores the eof condition so the second fread() requires another ^D to make it see the eof condition. According to the man page (and the C std, I hope) fread() can only return a short count on error or eof. I'm using that in the band-aid solution to avoid calling fread() a second time after a short read. Note that xreadlines() still has this problem: it calls readlines(sizehint) until it gets a zero-length return. Since xreadlines() is mostly used for reading real files, I won't worry about this until we get a bug report.
generated by cgit v0.12 at 2024-11-30 01:13:35 (GMT)