summaryrefslogtreecommitdiffstats
path: root/Objects/fileobject.c
Commit message (Collapse)AuthorAgeFilesLines
* 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.
* Rather gross workaround for a bug in the mac GUSI I/O library:Jack Jansen2001-10-101-1/+7
| | | | | | lseek(fp, 0L, SEEK_CUR) can make a filedescriptor unusable. This workaround is expected to last only a few weeks (until GUSI is fixed), but without it test_email fails.
* Enable GC for new-style instances. This touches lots of files, sinceGuido van Rossum2001-10-051-3/+3
| | | | | | | | | | | | | | | | | | | | | | many types were subclassable but had a xxx_dealloc function that called PyObject_DEL(self) directly instead of deferring to self->ob_type->tp_free(self). It is permissible to set tp_free in the type object directly to _PyObject_Del, for non-GC types, or to _PyObject_GC_Del, for GC types. Still, PyObject_DEL was a tad faster, so I'm fearing that our pystone rating is going down again. I'm not sure if doing something like void xxx_dealloc(PyObject *self) { if (PyXxxCheckExact(self)) PyObject_DEL(self); else self->ob_type->tp_free(self); } is any faster than always calling the else branch, so I haven't attempted that -- however those types whose own dealloc is fancier (int, float, unicode) do use this pattern.
* Generalize file.writelines() to allow iterable objects.Tim Peters2001-09-231-31/+31
|
* Add optional docstrings to getset descriptors. Fortunately, there'sGuido van Rossum2001-09-201-2/+2
| | | | | | | | | | no backwards compatibility to worry about, so I just pushed the 'closure' struct member to the back -- it's never used in the current code base (I may eliminate it, but that's more work because the getter and setter signatures would have to change.) As examples, I added actual docstrings to the getset attributes of a few types: file.closed, xxsubtype.spamdict.state.
* Add optional docstrings to member descriptors. For backwardsGuido van Rossum2001-09-201-4/+7
| | | | | | | | | | | | | | | compatibility, this required all places where an array of "struct memberlist" structures was declared that is referenced from a type's tp_members slot to change the type of the structure to PyMemberDef; "struct memberlist" is now only used by old code that still calls PyMember_Get/Set. The code in PyObject_GenericGetAttr/SetAttr now calls the new APIs PyMember_GetOne/SetOne, which take a PyMemberDef argument. As examples, I added actual docstrings to the attributes of a few types: file, complex, instance method, super, and xxsubtype.spamlist. Also converted the symtable to new style getattr.
* SF bug [#463093] File methods need doc strings.Tim Peters2001-09-201-14/+94
| | | | Now they don't.
* Patch #462849: Pass Unicode objects to file's .write method.Martin v. Löwis2001-09-191-3/+8
|
* The end of [#460467] file objects should be subclassable.Tim Peters2001-09-141-30/+63
| | | | | | | | A surprising number of changes to split tp_new into tp_new and tp_init. Turned out the older PyFile_FromFile() didn't initialize the memory it allocated in all (error) cases, which caused new sanity asserts elsewhere to fail left & right (and could have, e.g., caused file_dealloc to try decrefing random addresses).
* Get rid of builtin_open() entirely (the C code and docstring, not theTim Peters2001-09-131-2/+2
| | | | | builtin function); Guido pointed out that it could be just another name in the __builtin__ dict for the file constructor now.
* Now that file objects are subclassable, you can get at the file constructorTim Peters2001-09-131-0/+8
| | | | | | just by doing type(f) where f is any file object. This left a hole in restricted execution mode that rexec.py can't plug by itself (although it can plug part of it; the rest is plugged in fileobject.c now).
* SF bug [#460467] file objects should be subclassable.Tim Peters2001-09-131-23/+100
| | | | Preliminary support. What's here works, but needs fine-tuning.
* _portable_fseek():Guido van Rossum2001-09-101-0/+6
| | | | | | | | | | | | | | | | | | | | | Subtlety on Windows: if we change test_largefile.py to use a file > 4GB, it still fails. A debug session suggests this is because fseek(fp, 0, 2) refuses to seek to the end of the file when the file is > 4GB, because it uses the SetFilePointer() in 32-bit mode. But it only fails when we seek relative to the end of the file, because in the other seek modes only calls to fgetpos() and fsetpos() are made, which use Get/SetFilePointer() in 64-bit mode. Solution: #ifdef MS_WInDOWS, replace the call to fseek(fp, ...) with a call to _lseeki64(fileno(fp), ...). Make sure to call fflush(fp) first. (XXX Could also replace the entire branch with a call to _lseeki64(). Would that be more efficient? Certainly less generated code.) (XXX This needs more testing. I can't actually test that it works for files >4GB on my Win98 machine, because the filesystem here won't let me create files >=4GB at all. Tim should test this on his Win2K machine.)
* Enable large file support on Win32 systems.Tim Peters2001-09-061-1/+1
| | | | | | | | | Curious: the MS docs say stati64 etc are supported even on Win95, but Win95 doesn't support a filesystem that allows partitions > 2 Gb. test_largefile: This was opening its test file in text mode. I have no idea how that worked under Win64, but it sure needs binary mode on Win98. BTW, on Win98 test_largefile runs quickly (under a second).
* Changes to automatically enable large file support on some systems.Guido van Rossum2001-09-051-12/+20
| | | | | | | | | | | | | | | | | | | | | I believe this works on Linux (tested both on a system with large file support and one without it), and it may work on Solaris 2.7. The changes are twofold: (1) The configure script now boldly tries to set the two symbols that are recommended (for Solaris and Linux), and then tries a test script that does some simple seeking without writing. (2) The _portable_{fseek,ftell} functions are a little more systematic in how they try the different large file support options: first try fseeko/ftello, but only if off_t is large; then try fseek64/ftell64; then try hacking with fgetpos/fsetpos. I'm keeping my fingers crossed. The meaning of the HAVE_LARGEFILE_SUPPORT macro is not at all clear. I'll see if I can get it to work on Windows as well.
* repr's converted to using PyString_FromFormat() instead of sprintf'ingBarry Warsaw2001-08-241-7/+5
| | | | | | into a hardcoded char* buffer. Closes patch #454743.
* Patch #427190: Implement and use METH_NOARGS and METH_O.Martin v. Löwis2001-08-161-33/+20
|
* Apply anonymous SF patch #441229.Guido van Rossum2001-08-091-0/+6
| | | | | | | | | | | | Previously, f.read() and f.readlines() checked for errors on their file object and possibly raised an IOError, but f.readline() didn't. This patch makes f.readline() behave like the others. Note that I've added a call to clearerr() since the other calls to ferror() include that too. I have no way to test this code. :-)
* Remove spurious "closed" attribute definition from the memberlistGuido van Rossum2001-08-061-1/+0
| | | | table. (reported as an aside in SF #446049).
* Merge of descr-branch back into trunk.Tim Peters2001-08-021-27/+18
|
* Kill more warnings from the SGI compiler.Fred Drake2001-07-191-1/+1
| | | | Part of SF patch #434992.
* file_getiter(): make iter(file) be equivalent to file.xreadlines().Guido van Rossum2001-05-221-12/+3
| | | | | | | | | | | | | | This should be faster. This means: (1) "for line in file:" won't work if the xreadlines module can't be imported. (2) The body of "for line in file:" shouldn't use the file directly; the effects (e.g. of file.readline(), file.seek() or even file.tell()) would be undefined because of the buffering that goes on in the xreadlines module.
* Mondo changes to the iterator stuff, without changing how Python codeGuido van Rossum2001-04-231-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | sees it (test_iter.py is unchanged). - Added a tp_iternext slot, which calls the iterator's next() method; this is much faster for built-in iterators over built-in types such as lists and dicts, speeding up pybench's ForLoop with about 25% compared to Python 2.1. (Now there's a good argument for iterators. ;-) - Renamed the built-in sequence iterator SeqIter, affecting the C API functions for it. (This frees up the PyIter prefix for generic iterator operations.) - Added PyIter_Check(obj), which checks that obj's type has a tp_iternext slot and that the proper feature flag is set. - Added PyIter_Next(obj) which calls the tp_iternext slot. It has a somewhat complex return condition due to the need for speed: when it returns NULL, it may not have set an exception condition, meaning the iterator is exhausted; when the exception StopIteration is set (or a derived exception class), it means the same thing; any other exception means some other error occurred.
generated by cgit v0.12 at 2025-01-26 19:31:59 (GMT)