On Feb 4, 3:11 am, Bruno Desthuilliers <bruno.
42.desthuilli...@websiteburo.invalid> wrote:
> thmpsn....@gmail.com a écrit :
>
>
>
> > On Feb 3, 1:14 am, David Cournapeau <courn...@gmail.com> wrote:
> (snip)
> >> after all, we have used FILE* for years and I have no idea about the FILE
> >> structure.
>
> > Your lack of knowledge about it doesn't mean that it has somehow
> > magically "private" members. The only reason that most of us don't
> > know what a FILE is is that it's definition is implementation-defined
> > (i.e., every compiler may define it differently).
>
> > That doesn't have anything to do with private members. For example, on
> > my system, <stdio.h> defines FILE as:
>
> > struct _iobuf {
> > char *_ptr;
> > int _cnt;
> > char *_base;
> > int _flag;
> > int _file;
> > int _charbuf;
> > int _bufsiz;
> > char *_tmpfname;
> > };
>
> Didn't you notice kind of a pattern here ?
You mean the leading underscores? I don't think they're used for the
same purpose as in Python. In C/C++, identifiers that begin with an
underscore are reserved (at least at the outer level). Thus, if the
member '_ptr' would instead be named 'ptr', something like this would
break things:
#define ptr // OOPS!!
#include <stdio.h>
That shouldn't happen with '_ptr', since programs are not supposed to
define those kinds of names (yeah, right).
> > typedef struct _iobuf FILE;
>
> > Given this information, nothing prevents me from writing things like:
>
> > FILE* fp = fopen("file.txt", "r");
> > if (!fp) { /* do something */ }
>
> > printf("fp->_cnt = %d\n", fp->cnt);
> > printf("fp->_flag = %d\n", fp->_flag);
> > printf("fp->_file = %d\n", fp->_file);
>
> > fp->_flag = 0x20; // OOPS!!
>
> Indeed - and that's exactly the point : nothing prevents you from
> accessing the implementation, *and yet, you don't*
I sure don't, but I still *can*.
CHAOS MAY ENSUE!!
--
http://mail.python.org/mailman/listinfo/python-list
