Jeremy Hylton wrote:
>>Perhaps there is some value in finding functions which ought to expect
>>const char*. For that, occasional checks should be sufficient; I cannot
>>see a point in having code permanently pass with that option. In
>>particular not if you are interfacing with C libraries.
>
>
On 2/14/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Jeremy Hylton wrote:
> > The compiler in question is gcc and the warning can be turned off with
> > -Wno-write-strings. I think we'd be better off leaving that option
> > on, though. This warning will help me find places where I'm passing
On 2/14/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> Martin v. Löwis wrote:
> > M.-A. Lemburg wrote:
> >>> It's the consequences: nobody complains about tacking "const" on to a
> >>> former honest-to-God "char *" argument that was in fact not modified,
> >>> because that's not only helpful for C
Thanks to all for a rather insightful discussion, it's always fun to
learn that after 28 years of C programming the language still has
little corners that I know absolutely nothing about:-)
Practically speaking, though, I've adopted MAL's solution for the
time being:
> /* The keyword array
Martin v. Löwis wrote:
> M.-A. Lemburg wrote:
>>> It's the consequences: nobody complains about tacking "const" on to a
>>> former honest-to-God "char *" argument that was in fact not modified,
>>> because that's not only helpful for C++ programmers, it's _harmless_
>>> for all programmers. For e
M.-A. Lemburg wrote:
>>It's the consequences: nobody complains about tacking "const" on to a
>>former honest-to-God "char *" argument that was in fact not modified,
>>because that's not only helpful for C++ programmers, it's _harmless_
>>for all programmers. For example, nobody could sanely objec
Jeremy Hylton wrote:
> The compiler in question is gcc and the warning can be turned off with
> -Wno-write-strings. I think we'd be better off leaving that option
> on, though. This warning will help me find places where I'm passing a
> string literal to a function that does not take a const char
Tim Peters wrote:
> [Jeremy]
I added some const to several API functions that take char* but
typically called by passing string literals.
>
> [Tim]
>>> If he had _stuck_ to that, we wouldn't be having this discussion :-)
>>> (that is, nobody passes string literals to
>>> PyArg_ParseTuple
On 2/10/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Jeremy Hylton wrote:
> > Ok. I reviewed the original problem and you're right, the problem was
> > not that it failed outright but that it produced a warning about the
> > deprecated conversion:
> > warning: deprecated conversion from stri
+1
On 2/13/06, Jeremy Hylton <[EMAIL PROTECTED]> wrote:
> It sounds like the right answer for Python is to change the signature
> of PyArg_ParseTupleAndKeywords() back. We'll fix it when C fixes its
> const rules .
>
> Jeremy
>
> On 2/13/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > On 2/12
It sounds like the right answer for Python is to change the signature
of PyArg_ParseTupleAndKeywords() back. We'll fix it when C fixes its
const rules .
Jeremy
On 2/13/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 2/12/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> > > [A large head-explodi
On 2/12/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> > [A large head-exploding set of rules]
>
> Blarg.
>
> Const - Just Say No.
+1
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http:/
Martin v. Löwis wrote:
> then, in C++, 4.4p4 [conv.qual] has a rather longish formula to
> decide that the assignment is well-formed. In essence, it goes
> like this:
>
> [A large head-exploding set of rules]
Blarg.
Const - Just Say No.
Greg
___
Pyt
Armin Rigo wrote:
> Alas, this doesn't make gcc happy either. (I'm trying gcc 3.4.4.) In
> theory, it prevents the const-bypassing trick showed by Martin, but
> apparently the C standard (or gcc) is not smart enough to realize that.
It appears to be language-defined. Looking at the assignment
Greg Ewing wrote:
> There are *already* differences which make C and C++
> annoyingly incompatible. One is the const char * const *
> issue that appeared here.
Of course there are differences. C++ has classes, C doesn't.
C++ has function overloading, C doesn't.
C++ has assignment from char** to c
Aahz wrote:
>>That future version might get published in 2270, when everybody has
>>switched to C++, and compatibility with C is no longer required.
>
>
> Just for the clarification of those of us who are not C/C++ programmers,
> are you saying that this is different from the meaning in Python, w
Martin v. Löwis wrote:
> That future version might get published in 2270,
There are *already* differences which make C and C++
annoyingly incompatible. One is the const char * const *
issue that appeared here. Another is that it no longer
seems to be permissible to forward-declare static things,
Hi Tim,
On Fri, Feb 10, 2006 at 12:19:01PM -0500, Tim Peters wrote:
> Oh, who cares? I predict "Jack's problem" would go away if we changed
> the declaration of PyArg_ParseTupleAndKeywords to what you intended
> to begin with:
>
> PyAPI_FUNC(int) PyArg_ParseTupleAndKeywords(PyObject *, PyObject
On Sat, 11 Feb 2006 14:14:00 +0100, =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=
<[EMAIL PROTECTED]> wrote:
>Bengt Richter wrote:
>> Will a typedef help?
>
>A typedef can never help. It is always possible to reformulate
>a program using typedefs to one that doesn't use typedefs.
I realize that's tr
On Sat, Feb 11, 2006, "Martin v. L?wis" wrote:
>
> Not at all. People appear to completely fail to grasp the notion of
> "deprecated" in this context. It just means "it may go away in a
> future version", implying that the rest of it may *not* go away in a
> future version.
>
> That future version
Bengt Richter wrote:
> Will a typedef help?
A typedef can never help. It is always possible to reformulate
a program using typedefs to one that doesn't use typedefs.
Compiling your program with the const modification line
removed gives
martin.c: In function 'int main()':
martin.c:18: error: inva
On Fri, 10 Feb 2006 18:02:03 +0100, =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=
<[EMAIL PROTECTED]> wrote:
>Jeremy Hylton wrote:
>> I admit that I'm also puzzled by Jack's specific question. I don't
>> understand why an array passed to PyArg_ParseTupleAndKeywords() would
>> need to be declared as
Bengt Richter wrote:
> Would it make sense to use a typedef for readability's sake? E.g.,
>
> typedef const char * p_text_literal;
>
> and then use
>
> p_text_literal, const p_text_literal *
>
> in the signature, for read-only access to the data? (hope I got that right).
>
> (also test
Greg Ewing wrote:
>>FWIW, Annex D also defines these features as deprecated:
>>- the use of "static" for objects in namespace scope (AFAICT
>> including C file-level static variables and functions)
>>- C library headers (i.e. )
>
>
> Things like this are really starting to get on my groat.
> It
On Fri, 10 Feb 2006 17:53:39 +0100, Thomas Wouters <[EMAIL PROTECTED]> wrote:
>On Fri, Feb 10, 2006 at 11:30:30AM -0500, Jeremy Hylton wrote:
>> On 2/10/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>> > OMG. Are we now adding 'const' modifiers to random places? I thought
>> > "const propagation
Martin v. Löwis wrote:
> FWIW, Annex D also defines these features as deprecated:
> - the use of "static" for objects in namespace scope (AFAICT
> including C file-level static variables and functions)
> - C library headers (i.e. )
Things like this are really starting to get on my groat.
It use
Tim Peters wrote:
>>Sigh. I don't see any way to avoid a warning in Jack's case.
>
>
> Martin's turn ;-)
I see two options:
1. Revert the change for the const char** keywords argument (but
leave the change for everything else). C++ users should only
see a problem if they have a const cha
Jeremy Hylton wrote:
> Ok. I reviewed the original problem and you're right, the problem was
> not that it failed outright but that it produced a warning about the
> deprecated conversion:
> warning: deprecated conversion from string constant to 'char*''
>
> I work at a place that takes the same
On 2/10/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 2/10/06, Tim Peters <[EMAIL PROTECTED]> wrote:
> > [Jeremy]
> > I added some const to several API functions that take char* but
> > typically called by passing string literals.
> >
> > If he had _stuck_ to that, we wouldn't be
[Jeremy]
>>> I added some const to several API functions that take char* but
>>> typically called by passing string literals.
[Tim]
>> If he had _stuck_ to that, we wouldn't be having this discussion :-)
>> (that is, nobody passes string literals to
>> PyArg_ParseTupleAndKeywords's kws argument).
On 2/10/06, Tim Peters <[EMAIL PROTECTED]> wrote:
> [Jeremy]
> >> I added some const to several API functions that take char* but
> >> typically called by passing string literals. In C++, a string literal
> >> is a const char* so you need to add a const_cast<> to every call site,
> >> which is inc
On 2/10/06, Tim Peters <[EMAIL PROTECTED]> wrote:
> [Jeremy]
> I added some const to several API functions that take char* but
> typically called by passing string literals.
>
> If he had _stuck_ to that, we wouldn't be having this discussion :-)
> (that is, nobody passes string literal
[Jeremy]
>> I added some const to several API functions that take char* but
>> typically called by passing string literals. In C++, a string literal
>> is a const char* so you need to add a const_cast<> to every call site,
>> which is incredibly cumbersome. After some discussion on python-dev,
>>
On 2/10/06, Jeremy Hylton <[EMAIL PROTECTED]> wrote:
> I added some const to several API functions that take char* but
> typically called by passing string literals. In C++, a string literal
> is a const char* so you need to add a const_cast<> to every call site,
> which is incredibly cumbersome.
[Jeremy]
>> It looks like a solution may be to define it as "const char * const *"
>> rather than "const char **". I'll see if that works.
[Jeremy]
> No. It doesn't work. I'm not sure about this one either, but some
> searching suggests that you can pass a char** to a function taking
> const ch
On 2/10/06, Jeremy Hylton <[EMAIL PROTECTED]> wrote:
> It looks like a solution may be to define it as "const char * const *"
> rather than "const char **". I'll see if that works.
No. It doesn't work. I'm not sure about this one either, but some
searching suggests that you can pass a char** to
[Jeremy Hylton]
> ...
> I admit that I'm also puzzled by Jack's specific question. I don't
> understand why an array passed to PyArg_ParseTupleAndKeywords() would
> need to be declared as const. I observed the problem in my initial
> changes but didn't think very hard about the cause of the probl
On 2/10/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Jeremy Hylton wrote:
> > I added some const to several API functions that take char* but
> > typically called by passing string literals. In C++, a string literal
> > is a const char* so you need to add a const_cast<> to every call site,
>
Jeremy Hylton wrote:
> I added some const to several API functions that take char* but
> typically called by passing string literals. In C++, a string literal
> is a const char* so you need to add a const_cast<> to every call site,
That's not true.
A string literal of length N is of type const c
It looks like a solution may be to define it as "const char * const *"
rather than "const char **". I'll see if that works.
Jeremy
On 2/10/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Jeremy Hylton wrote:
> > I admit that I'm also puzzled by Jack's specific question. I don't
> > understan
Jeremy Hylton wrote:
> I admit that I'm also puzzled by Jack's specific question. I don't
> understand why an array passed to PyArg_ParseTupleAndKeywords() would
> need to be declared as const. I observed the problem in my initial
> changes but didn't think very hard about the cause of the proble
On Fri, Feb 10, 2006 at 11:30:30AM -0500, Jeremy Hylton wrote:
> On 2/10/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > OMG. Are we now adding 'const' modifiers to random places? I thought
> > "const propagation hell" was a place we were happily avoiding by not
> > falling for that meme. What
On 2/10/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> OMG. Are we now adding 'const' modifiers to random places? I thought
> "const propagation hell" was a place we were happily avoiding by not
> falling for that meme. What changed?
I added some const to several API functions that take char* b
OMG. Are we now adding 'const' modifiers to random places? I thought
"const propagation hell" was a place we were happily avoiding by not
falling for that meme. What changed?
--Guido
On 2/10/06, Jack Jansen <[EMAIL PROTECTED]> wrote:
> I keep running into problems with the "const" modifications t
44 matches
Mail list logo
