This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH: Support for Pascal strings
- To: Stan Shebs <shebs at apple dot com>
- Subject: Re: PATCH: Support for Pascal strings
- From: Mark Mitchell <mark at codesourcery dot com>
- Date: Fri, 22 Jun 2001 10:18:03 -0700
- cc: Ziemowit Laski <zlaski at apple dot com>, Daniel Jacobowitz <dmj+ at andrew dot cmu dot edu>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
--On Thursday, June 21, 2001 05:44:03 PM -0700 Stan Shebs <shebs@apple.com>
wrote:
> Mark Mitchell wrote:
>>
>> Good. Can we negotiate the unsignedness?
>>
>> I cannot imagine very many people rely on this particular aspect of the
>> extension. In we can make "\p..." be a plan `char' --- signed or
>> unsigned in the same way that "..." would be -- then we are in business.
>> In that case, we just have the preprocessor replace \p with the length
>> byte, and that is it. The change then becomes extremely minimal, both
>> in terms of semantics and in terms of code.
>
> The response was swift and negative
Very unfortunate.
However, I see that DEFAULT_SIGNED_CHAR is `0' in <rs6000.h>. Unless
you overrode that in Darwin-land, the second objection is then moot;
a `char' is unsigned. It is still a different type from `unsigned char',
and I don't think that `unsigned char* p = (char*) ...' is legal, which
is what your typedef would boil down too. You could change the typedef;
in theory, good programmers have not depended on the exact type of the
typedef.
I think having string literals that have type "unsigned char [n]" is
pretty weird, so I guess I'm growing negative on this extension -- if
it needs that behavior. Hmm.
There are two issues here: the technical issues about whether an extension
makes sense, etc., and the political ones about Apple using GCC and forking
GCC and so forth. I think that this is a technically not-so-good
extension, in its current form. I don't know if the political issues could
override the technical ones; that's not for me to judge.
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com