This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: PATCH: Support for Pascal strings




--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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]