Sparse parsing question: string literal

Sparse parsing question: string literal

[Dibyendu Majumdar]

Hi,

I am looking at the parse tree for following snippet:

void main(int argc, const char *argv[])
{
5;
6.5;
"hello";
}

I see that 5 is treated as EXPR_VALUE, 6.5 as EXPR_FVALUE, but "hello"
is treated as EXPR_SYMBOL. Why is that?

Thanks and Regards
Dibyendu

Re: Sparse parsing question: string literal

[Christopher Li]

On Sun, Aug 20, 2017 at 8:31 AM, Dibyendu Majumdar
<mobile@majumdar.org.uk> wrote:
> Hi,
>
> I am looking at the parse tree for following snippet:
>
> void main(int argc, const char *argv[])
> {
> 5;
> 6.5;
> "hello";
> }
>
> I see that 5 is treated as EXPR_VALUE, 6.5 as EXPR_FVALUE, but "hello"
> is treated as EXPR_SYMBOL. Why is that?

Because "hello" is array of char from type point of view.

It is same as
char no_ident [] = {'h', 'e', 'l', 'l', 'o', '\0'};

except it does not have the name(sym->ident) for this symbol.

Chris

Re: Sparse parsing question: string literal

[Dibyendu Majumdar]

Hi Chris,

On 20 August 2017 at 14:05, Christopher Li <sparse@chrisli.org> wrote:
> On Sun, Aug 20, 2017 at 8:31 AM, Dibyendu Majumdar
> <mobile@majumdar.org.uk> wrote:
>> I am looking at the parse tree for following snippet:
>>
>> void main(int argc, const char *argv[])
>> {
>> 5;
>> 6.5;
>> "hello";
>> }
>>
>> I see that 5 is treated as EXPR_VALUE, 6.5 as EXPR_FVALUE, but "hello"
>> is treated as EXPR_SYMBOL. Why is that?
>
> Because "hello" is array of char from type point of view.
>
> It is same as
> char no_ident [] = {'h', 'e', 'l', 'l', 'o', '\0'};
>
> except it does not have the name(sym->ident) for this symbol.
>

I see - so every string literal results in an un-named symbol, whose
initializer is set to the string expression?

Regards
Dibyendu

Re: Sparse parsing question: string literal

[Christopher Li]

On Sun, Aug 20, 2017 at 9:12 AM, Dibyendu Majumdar
<mobile@majumdar.org.uk> wrote:
> I see - so every string literal results in an un-named symbol, whose
> initializer is set to the string expression?

Yes, because you can do sizeof("hello"). The string literal need to have type
and size. That is why it is wrap in a symbol of char array.  It can have a
proper size. Int and float constant has fix size and type, they can be
represented
directly in expression.

Chris

Re: Sparse parsing question: string literal

[Derek M Jones]

Christopher,

> Because "hello" is array of char from type point of view.
> 
> It is same as
> char no_ident [] = {'h', 'e', 'l', 'l', 'o', '\0'};

You forgot the static keyword:
Sentence 903:
http://c0x.coding-guidelines.com/6.4.5.html

But depending on context a conversion occurs.
Sentence 729:
http://c0x.coding-guidelines.com/6.3.2.1.html

and your example is one where such a conversion occurs.

-- 
Derek M. Jones           Software analysis
tel: +44 (0)1252 520667  blog:shape-of-code.coding-guidelines.com

Re: Sparse parsing question: string literal

[Christopher Li]

On Sun, Aug 20, 2017 at 11:16 AM, Derek M Jones <derek@knosof.co.uk> wrote:
>
> You forgot the static keyword:
> Sentence 903:
> http://c0x.coding-guidelines.com/6.4.5.html

Thanks for catching that. You are right. They need to be static as well.
I kind of expect that to be const as well. The stander did not put const
as requirement. Just said modify the string is undefined.

>
> But depending on context a conversion occurs.
> Sentence 729:
> http://c0x.coding-guidelines.com/6.3.2.1.html
>
> and your example is one where such a conversion occurs.

Thanks for pointing it out. Interesting read.

BTW, unrelated to string literal but relate to 729.

Do you have any comment on sparse giving warning of:
sizeof(function_name)?

The programmer usually mean sizeof(&function_name).
But 729 said sizeof is such a special case the function degenerate
into pointers does not work inside sizeof().

Should sparse give warning for sizeof(function_name) at all?

Thanks

Chris

Re: Sparse parsing question: string literal

[Derek M Jones]

Christopher,

> Do you have any comment on sparse giving warning of:
> sizeof(function_name)?
> 
> The programmer usually mean sizeof(&function_name).
> But 729 said sizeof is such a special case the function degenerate
> into pointers does not work inside sizeof().
> 
> Should sparse give warning for sizeof(function_name) at all?

It's a question of intent.

sizeof(function_name) was written, but was
sizeof(function_name()) intended?

Of course sizeof(&function_name) may have been written, but
sizeof(&function_name()) was intended.  But that & is an
unusually thing to include in a function call, which makes it
less likely that () were accidentally omitted.

Is it reasonable to require people to add & to signal,
yes I really do mean pointer to function?  The indignity
if having to type that extra character!

I'm inclined towards generating warnings, since there is a
way of making the warning to go away, e.g., add & or ().

-- 
Derek M. Jones           Software analysis
tel: +44 (0)1252 520667  blog:shape-of-code.coding-guidelines.com

Re: Sparse parsing question: string literal

[Christopher Li]

On Sun, Aug 20, 2017 at 12:31 PM, Derek M Jones <derek@knosof.co.uk> wrote:
>
>
> It's a question of intent.
>
> sizeof(function_name) was written, but was
> sizeof(function_name()) intended?

The case I saw was for as part of the structure initialization.
It want to store the generic object and its size.
So it has { .... , function_name, sizeof(function_name), .... }
some thing like that.

For that usage I am pretty sure it is sizeof(&function_name).

But you are right the other way to guess the intend can be
sizeof(function_name()).


>
> Of course sizeof(&function_name) may have been written, but
> sizeof(&function_name()) was intended.  But that & is an
> unusually thing to include in a function call, which makes it
> less likely that () were accidentally omitted.
>
> Is it reasonable to require people to add & to signal,
> yes I really do mean pointer to function?  The indignity
> if having to type that extra character!
>
> I'm inclined towards generating warnings, since there is a
> way of making the warning to go away, e.g., add & or ().

OK, that make sense. The warning should stay.

Thanks

Chris