Re: PATCH: Support for Pascal strings -- Take 2

[Ziemowit Laski <zlaski at apple dot com>]

On Friday, June 29, 2001, at 12:38 , Joseph S. Myers wrote:

> On Fri, 29 Jun 2001, Ziemowit Laski wrote:
>
> In general, your mailer seems to be wrapping lines.  Please fix this.

Yes, I have to be more careful when pasting in the diffs -- the 
surrounding text seems all right, though (or else this line will be 
wrapped as well...).
>
>> +             if (t != strings && !is_pascal_string)
>> +               warning ("Pascal string-length escape (\\p) ignored in
>> concatenation");
>
> Should be a hard error.

Ok -- will make all warnings into errors

>
>>                        for (j=0; j<(WCHAR_TYPE_SIZE / BITS_PER_UNIT)-1;
>
> Use GNU coding style (spaces around < and = and -).

I have no problem with fixing this "in principle", except that the above 
line is not part of my patch and there are plenty more just like it 
throughout the source tree... :)

>>            if ((TYPE_MAIN_VARIANT (TREE_TYPE (TREE_TYPE (string)))
>>                 != char_type_node)
>> +             && (TYPE_MAIN_VARIANT (TREE_TYPE (TREE_TYPE (string)))
>> +              != unsigned_char_type_node)
>>                && TYPE_PRECISION (typ1) == BITS_PER_UNIT)
>
> I don't know exactly what you're doing with initialisation, but you need
> to document it, and have testcases.

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.

>
>> + As is the case with C string literals, Pascal string literals are
>> + terminated with a NULL character; this character is @emph{not} 
>> counted
>
> This character is known as NUL, not NULL.

Ok.

> Your description of types is wrong.  String literals have array type, 
> not
> pointer type.  Also, in ISO 9899, the type is not const-qualified.  You
> need to state what the actual type is, in the context of both ISO 9899 
> and
> ISO 14882, and with -Wwrite-strings.  You need to document the absence 
> of
> a deprecated conversion to unsigned char * in C++, and test it.  You 
> need
> to include a statement of what the dimension of the array is, as well as
> the element type.

I will work on this further.  Which deprecated conversion to unsigned 
char * do you speak of -- can you point me to the appropriate section of 
ISO 14882?

>
>> + int
>> + strlen (const unsigned char *s)
>
> Use strlen from the standard library rather than reimplementing it in a
> testcase.

Ok.

>
> Using a -std= option for a C standard version does not make sense in C++
> tests.

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