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


First off, a quick note regarding my previous message, specifically the 
turning of warnings into hard errors.  It appears that at least some of 
them (e.g, extraneous \p in concatenation) will need to remain warnings 
since this is used in legacy code.

On Friday, June 29, 2001, at 01:42 , Joseph S. Myers wrote:

> You also need to ensure tabs and spaces don't get confused.  Pasting is
> generally a bad way of doing things.  If you can't get your mailer to
> behave, then attaching as text/plain can be used, but having patches in
> the body of the messages is preferred.

I guess I'll be attaching the diffs from now on, then, until I figure 
out how to preserve tabs across pastes.

> +         if (length -2 > 255)
>
> That line also fails to allow for target bytes being wider than 8 bits.

To my knowledge, Pascal strings have a hard limit of 255 even if the 
byte size is larger.  I'm not sure about this, as I've never seen a 
machine with bytes larger than 8, let alone one with a Pascal compiler 
ported to it. :)

>
>> The logic being patched (in both c-typeck.c and cp/typeck2.c) has to do
>> with initializing wide char arrays with narrow strings and vice versa.
>> Without the patch, Pascal strings would be mistaken for wide strings.
>> I'm not sure what kind of documentation or test case I should provide
>> here (please advise) since the objective here is to maintain existing
>> semantics rather than to add functionality.
>
> Test initialising each kind of array (char, signed char, unsigned char,
> wchar_t) with each kind of string literal (normal, Pascal, wide), for 
> both
> C and C++, testing that errors occur exactly when they are meant to.
>
> Document that character arrays may be initialised with Pascal string
> literals when they may be initialised with normal narrow ones.

Would it suffice to describe that in the test case itself, or should it 
go into extend.texi?

--------------------------------------------------------------
Ziemowit Laski                   Apple Computer, Inc.
zlaski@apple.com                 2 Infinite Loop, MS 302-4SN
+1.408.974.6229  Fax .1344       Cupertino, CA  95014-2085


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