Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #103427 > unrolled thread

C Names and Scopes

Back to article view | Back to comp.lang.c

Contents

  C Names and Scopes BartC <bc@freeuk.com> - 2017-02-08 02:13 +0000
    Re: C Names and Scopes David Brown <david.brown@hesbynett.no> - 2017-02-08 10:09 +0100
      Re: C Names and Scopes mark.bluemel@gmail.com - 2017-02-08 02:37 -0800
        Re: C Names and Scopes BartC <bc@freeuk.com> - 2017-02-08 11:07 +0000
          Re: C Names and Scopes fir <profesor.fir@gmail.com> - 2017-02-08 09:03 -0800
            Re: C Names and Scopes BartC <bc@freeuk.com> - 2017-02-08 17:19 +0000
              Re: C Names and Scopes fir <profesor.fir@gmail.com> - 2017-02-08 09:42 -0800
        Re: C Names and Scopes David Brown <david.brown@hesbynett.no> - 2017-02-08 12:08 +0100
      Re: C Names and Scopes Moai <penultimategrill@gmail.com> - 2017-02-08 19:16 -0500
        Re: C Names and Scopes David Brown <david.brown@hesbynett.no> - 2017-02-09 01:32 +0100
        Re: C Names and Scopes Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-09 08:18 -0800
        Re: C Names and Scopes Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-09 12:06 -0500
    Re: C Names and Scopes BartC <bc@freeuk.com> - 2017-02-08 10:51 +0000
    Re: C Names and Scopes Thiago Adams <thiago.adams@gmail.com> - 2017-02-08 03:11 -0800
      Re: C Names and Scopes BartC <bc@freeuk.com> - 2017-02-08 11:39 +0000
        Re: C Names and Scopes BartC <bc@freeuk.com> - 2017-02-08 12:06 +0000
          Re: C Names and Scopes BartC <bc@freeuk.com> - 2017-02-08 13:31 +0000
          Re: C Names and Scopes BartC <bc@freeuk.com> - 2017-02-08 13:40 +0000
            Re: C Names and Scopes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-08 16:39 +0000
              Re: C Names and Scopes BartC <bc@freeuk.com> - 2017-02-08 17:51 +0000
                Re: C Names and Scopes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-08 20:56 +0000
                  Re: C Names and Scopes BartC <bc@freeuk.com> - 2017-02-08 22:08 +0000
                    Re: C Names and Scopes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-08 23:27 +0000
        Re: C Names and Scopes David Brown <david.brown@hesbynett.no> - 2017-02-08 13:41 +0100
        Re: C Names and Scopes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-08 14:32 +0000
          Re: C Names and Scopes supercat@casperkitty.com - 2017-02-08 07:28 -0800
            Re: C Names and Scopes BartC <bc@freeuk.com> - 2017-02-08 20:12 +0000
              Re: C Names and Scopes Keith Thompson <kst-u@mib.org> - 2017-02-08 12:38 -0800
                Re: C Names and Scopes BartC <bc@freeuk.com> - 2017-02-08 21:54 +0000
                  Re: C Names and Scopes BartC <bc@freeuk.com> - 2017-02-08 22:40 +0000
    Re: C Names and Scopes BartC <bc@freeuk.com> - 2017-02-09 18:48 +0000
      Re: C Names and Scopes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-09 19:53 +0000
        Re: C Names and Scopes Keith Thompson <kst-u@mib.org> - 2017-02-09 12:25 -0800
          Re: C Names and Scopes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-09 21:27 +0000
            Re: C Names and Scopes Keith Thompson <kst-u@mib.org> - 2017-02-09 13:57 -0800
              Re: C Names and Scopes David Brown <david.brown@hesbynett.no> - 2017-02-13 10:54 +0100
          Re: C Names and Scopes BartC <bc@freeuk.com> - 2017-02-10 00:26 +0000
            Re: C Names and Scopes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-10 00:42 +0000
              Re: C Names and Scopes BartC <bc@freeuk.com> - 2017-02-10 01:03 +0000
                Re: C Names and Scopes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-10 01:49 +0000
                  Re: C Names and Scopes BartC <bc@freeuk.com> - 2017-02-10 12:31 +0000
                    Re: C Names and Scopes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-10 23:48 +0000
                      Re: C Names and Scopes supercat@casperkitty.com - 2017-02-10 16:06 -0800
                        Re: C Names and Scopes Keith Thompson <kst-u@mib.org> - 2017-02-10 16:22 -0800
                          Re: C Names and Scopes supercat@casperkitty.com - 2017-02-12 09:17 -0800
                          Re: C Names and Scopes Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-15 16:26 -0800
                Re: C Names and Scopes Keith Thompson <kst-u@mib.org> - 2017-02-09 17:56 -0800
                Re: C Names and Scopes supercat@casperkitty.com - 2017-02-10 07:42 -0800
                  Re: C Names and Scopes Keith Thompson <kst-u@mib.org> - 2017-02-10 08:44 -0800
                    Re: C Names and Scopes supercat@casperkitty.com - 2017-02-10 09:25 -0800
                    Re: C Names and Scopes Jerry Stuckle <jstucklex@attglobal.net> - 2017-02-10 16:43 -0500
                      Re: C Names and Scopes supercat@casperkitty.com - 2017-02-10 14:04 -0800
                        Re: C Names and Scopes BartC <bc@freeuk.com> - 2017-02-10 22:52 +0000
                          Re: C Names and Scopes Andrey Tarasevich <andreytarasevich@hotmail.com> - 2017-02-10 15:10 -0800
          Re: C Names and Scopes Tim Rentsch <txr@alumni.caltech.edu> - 2017-02-15 16:31 -0800
        Re: C Names and Scopes BartC <bc@freeuk.com> - 2017-02-09 23:09 +0000
          Re: C Names and Scopes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-09 23:36 +0000
            Re: C Names and Scopes BartC <bc@freeuk.com> - 2017-02-10 00:19 +0000
              Re: C Names and Scopes Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-10 00:38 +0000
    Re: C Names and Scopes BartC <bc@freeuk.com> - 2017-03-04 01:23 +0000
      Re: C Names and Scopes jameskuyper@verizon.net - 2017-03-03 18:23 -0800
        Re: C Names and Scopes GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-04 14:42 +0100
          Re: C Names and Scopes "James R. Kuyper" <jameskuyper@verizon.net> - 2017-03-04 11:02 -0500
            Re: C Names and Scopes GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-04 23:35 +0100
              Re: C Names and Scopes Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-03-04 14:50 -0800
              Re: C Names and Scopes Richard Heathfield <rjh@cpax.org.uk> - 2017-03-05 13:39 +0000
                Re: C Names and Scopes GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-05 15:10 +0100
                  Re: C Names and Scopes Richard Heathfield <rjh@cpax.org.uk> - 2017-03-05 14:34 +0000
                  Re: C Names and Scopes Keith Thompson <kst-u@mib.org> - 2017-03-05 19:25 -0800
                Re: C Names and Scopes raltbos@xs4all.nl (Richard Bos) - 2017-03-06 09:37 +0000
                  Re: C Names and Scopes Richard Heathfield <rjh@cpax.org.uk> - 2017-03-06 10:34 +0000
                  Re: C Names and Scopes James Kuyper <jameskuyper@verizon.net> - 2017-03-06 07:23 -0500
                    Re: C Names and Scopes GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-03-06 14:26 +0100
      Re: C Names and Scopes Keith Thompson <kst-u@mib.org> - 2017-03-04 11:52 -0800
        Re: C Names and Scopes BartC <bc@freeuk.com> - 2017-03-04 20:13 +0000
          Re: C Names and Scopes BartC <bc@freeuk.com> - 2017-03-04 20:17 +0000
          Re: C Names and Scopes Keith Thompson <kst-u@mib.org> - 2017-03-04 12:38 -0800
          Re: C Names and Scopes jameskuyper@verizon.net - 2017-03-04 13:50 -0800
            Re: C Names and Scopes BartC <bc@freeuk.com> - 2017-03-04 22:37 +0000
              Re: C Names and Scopes jameskuyper@verizon.net - 2017-03-04 16:15 -0800
                Re: C Names and Scopes BartC <bc@freeuk.com> - 2017-03-05 00:31 +0000
                  Re: C Names and Scopes jameskuyper@verizon.net - 2017-03-04 16:47 -0800
                    Re: C Names and Scopes BartC <bc@freeuk.com> - 2017-03-05 01:42 +0000
                      Re: C Names and Scopes jameskuyper@verizon.net - 2017-03-04 19:20 -0800
                      Re: C Names and Scopes Keith Thompson <kst-u@mib.org> - 2017-03-05 01:40 -0800

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

#103488

BartC <bc@freeuk.com> writes:

> On 08/02/2017 16:39, Ben Bacarisse wrote:
>> BartC <bc@freeuk.com> writes:
>>
>>> On 08/02/2017 12:06, BartC wrote:
>>>
>>>> And I gave an example in one of my links where there are five identical
>>>> names in the same block all meaning different things!
>>
>> The ! makes you sound surprised but why should, say, a label called
>> "link" not be usable at the same time as a struct link type?  One can
>> only be used after goto, and the other only after struct.  Seems
>> reasonable to me, though as a programmer you might rarely come across
>> such cases.
>
> I disagree; why go to the trouble in the first place? What advantage
> is there to have A meaning a variable, a struct tag, and a label in
> the same scope?

I'm not saying there *are* any advantages, and of course it could have
been done differently and those other designs might even be better.  I'm
just surprised that you are surprised.  Either it's mock surprise
intended to elicit a response, or you are so tied to one way of seeing
programming languages that other choices are startling.

> It may technically be possible because certain kinds of names belong
> in particular contexts, but that doesn't make it any easier when
> confronted with code that makes use of that and that can throw you,
> because you weren't even aware that something was possible:
>
>   struct A A;

How could that throw anyone (other than the silly names)?  If I see

  struct node node;

it is clear what's going on (provided I have even the most basic
understanding of C's struct syntax).  On the flip side, your way will
surprise people who expect to be able to call their variable X even when
X is used for some totally different kind of name.  Again: I am not
saying that's good or bad -- it's different and neither seems
particularly odd or counter-intuitive.

> or:
>
>   Point p;
>   struct Point q;

How is that going to be clearer if the struct tag can't share a name
with the type?  Using different names won't stop the code being odd, and
it's obvious that something very odd is going on.  By being able to use
the same name the strangeness is brought to the fore so I'd call that an
advantage in this case.

<snip>
> or:
>
>  struct L*L;
>
>  if (L)
>    L: goto L;
>
> I didn't even need to go to the trouble of declaring new names halfway
> through a block. (It already reminds me of that scene in Being John
> Malkovich where everyone has the same face!)

I don't find that confusing (35 years using C is a long time) but I
agree that it could be for people just starting out.  However, it's a
very contrived example and it does not take much to unravel.

> Without that ability, people would be forced to write that last example as:
>
>  struct S*P;
>
>  if (P)
>    L: goto L;

No, they are not forced to write it like that anymore than c currently
forces (or even encourages) the code you wrote.  All that would change
is that people would have to use different names.  They could be just as
silly in the new choice of names as you were with the old ones:

  struct label *Union;

  if (Union)
     pointer: goto pointer;

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#103494

On 08/02/2017 20:56, Ben Bacarisse wrote:
> BartC <bc@freeuk.com> writes:

>> It may technically be possible because certain kinds of names belong
>> in particular contexts, but that doesn't make it any easier when
>> confronted with code that makes use of that and that can throw you,
>> because you weren't even aware that something was possible:
>>
>>   struct A A;
>
> How could that throw anyone (other than the silly names)?  If I see
>
>   struct node node;
>
> it is clear what's going on  (provided I have even the most basic
> understanding of C's struct syntax).  On the flip side, your way will
> surprise people who expect to be able to call their variable X even when
> X is used for some totally different kind of name.

I don't know what you mean by 'my way' unless it's not to allow 
overloading of any names in the same scope.

And do people really expect to use X for different things like that?

C already allows you to use letter-case to vary names so that:

   struct Node node;

is possible. Are C programmers so devoid of creativity that they have to 
reuse exactly the same names without even bothering to change case, or 
use an extra block scope?

There are 15 ways of writing 'node' and still have an identifier which 
is distinct from 'node'.

   Again: I am not
> saying that's good or bad -- it's different and neither seems
> particularly odd or counter-intuitive.
>
>> or:
>>
>>   Point p;
>>   struct Point q;
>
> How is that going to be clearer if the struct tag can't share a name
> with the type?  Using different names won't stop the code being odd, and
> it's obvious that something very odd is going on.  By being able to use
> the same name the strangeness is brought to the fore so I'd call that an
> advantage in this case.

This doesn't make sense. You're advocating justifying an odd feature 
because using it highlights the fact that it's odd and gets people to 
look twice? Having about not having it at all? Then there would be no need.

I can't imagine these different namespaces make C any easier to process, 
and using them would raise eyebrows, so I can't see any point to them at 
all.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#103501

BartC <bc@freeuk.com> writes:

> On 08/02/2017 20:56, Ben Bacarisse wrote:
>> BartC <bc@freeuk.com> writes:
>
>>> It may technically be possible because certain kinds of names belong
>>> in particular contexts, but that doesn't make it any easier when
>>> confronted with code that makes use of that and that can throw you,
>>> because you weren't even aware that something was possible:
>>>
>>>   struct A A;
>>
>> How could that throw anyone (other than the silly names)?  If I see
>>
>>   struct node node;
>>
>> it is clear what's going on  (provided I have even the most basic
>> understanding of C's struct syntax).  On the flip side, your way will
>> surprise people who expect to be able to call their variable X even when
>> X is used for some totally different kind of name.
>
> I don't know what you mean by 'my way' unless it's not to allow
> overloading of any names in the same scope.

I intened to suggest whatever it was you think C should have done.  In
this case putting struct tags and object names into the same namespace.

> And do people really expect to use X for different things like that?

If people don't do this the issue you worry about above (readers being
surprised) by the use simply won't happen.  If it does happen (so you
are right to wonder if readers will surprised) then presumably it's
because people expected to be a able to do it.

<snpi>
>>> or:
>>>
>>>   Point p;
>>>   struct Point q;
>>
>> How is that going to be clearer if the struct tag can't share a name
>> with the type?  Using different names won't stop the code being odd, and
>> it's obvious that something very odd is going on.  By being able to use
>> the same name the strangeness is brought to the fore so I'd call that an
>> advantage in this case.
>
> This doesn't make sense. You're advocating justifying an odd feature
> because using it highlights the fact that it's odd and gets people to
> look twice? Having about not having it at all? Then there would be no
> need.

I think you need to explain what the code above is doing.  To me it
defines two obviously very closely related kinds of thing in two
different ways.  If typedef names and struct tags can't be the same the
programmer would have written something else but I can't know what that
would be because I can't know the intent.

Maybe they would have written

   Point2D p;
   struct Vector2D q;

Now the only oddity why one is a struct and the other is not, but it's
also clear that the error in your example is not down to C's naming
permission but that bad names were chosen.

But if a Point and a struct Point are indeed the same thing then I want
your code to stay as it is and look odd -- as odd as possible -- because
it needs correcting to either

  Point p, q;

or

  struct Point p, q;

to make that clear.  Obliging the programmer to use slightly different
names won't make this odd code ant clearer.  In fact it might hide how
very off it is by suggesting that maybe the two things are different.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#103455

On 08/02/17 12:39, BartC wrote:
> On 08/02/2017 11:11, Thiago Adams wrote:
>> On Wednesday, February 8, 2017 at 12:13:30 AM UTC-2, Bart wrote:
>>> I've been trying to understand this aspect, and the more I learn the
>>> more chaotic it seems compared with other languages.
>>>
>>> I've written up what I understand of it here:
>>>
>>> http://pastebin.com/UgcT0Mag
>>>
>>> If it's on totally the wrong lines then perhaps someone can point it
>>> out.
>>>
>>
>> I have the same questions on my mind and more how to implement these
>> scopes.
>>
>> I have used a multi-map. A "key" can point for more than one symbol.
>> So for instance, for function "F" I can point to the declaration and
>> also implementation and for multi-declarations of F.
>> If I have a struct X and enum X the key "X"points
>> to both and then the disambiguation can be done looking into
>> the pointed data.
> 
> I think I also have a rather strange symbol table arrangement that has
> worked successfully on /my/ languages but am trying to adapt it to C...
> 
>> For the local variables I have an stack of symbol-maps and an
>> algorithm to find the variable going up into this stack.
> 
> ... although C's block scopes are going to be a bit of a challenge. I've
> developed a scheme to deal with them efficientlu but still need to try
> it out. But it is essential that I know exactly what the capabilities
> are, including all the corner cases that even experienced C coders don't
> know exist.
> 
> (With block scopes, here is one tricky case:
> 
>    int A;        // A1
>    { A = 0;      // A1
>      int A;      // A2
>      A = 0;      // A2
>    }
> 

View the scopes like a stack.  Every new declaration is a new stack
entry - you can consider it just like entering a new block.  Any time
you need to find an identifier, you start from the top of the stack and
work down until you get a first hit.

So the code above gets parsed just as though it were:

  {
    int A;
    {
      A = 0;
      {
        int A;
        A = 0;
      }
    }
  }




> Supposed this is parsed to an AST, without doing name resolving. By
> then, I have A1 in the outer scope, and A2 in the inner one.
> 
> But if later trying to resolve the A's in either of the A=0 expressions,
> how to stop them both resolving to A2? The second 'int A' doesn't result
> in an AST node, but even if it did, it wouldn't help.
> 
> The language is forcing my hand in doing the resolving as I go along, so
> the first expression is name-resolved before the second 'int A' is
> encountered. I would rather have had the choice.)
> 
>> (
>> To implement a warning in my static analiser for hidden variable
>> (when you declare a variable with the same name of one from
>> the scope above) it's a easy task.
>> )
> 
> Your task is different. I assume the code is correct if it's legal C.
> 

[toc] | [prev] | [next] | [standalone]

#103468

BartC <bc@freeuk.com> writes:
<snip>
> ... although C's block scopes are going to be a bit of a
> challenge. I've developed a scheme to deal with them efficientlu but
> still need to try it out. But it is essential that I know exactly what
> the capabilities are, including all the corner cases that even
> experienced C coders don't know exist.
>
> (With block scopes, here is one tricky case:
>
>    int A;        // A1
>    { A = 0;      // A1
>      int A;      // A2
>      A = 0;      // A2
>    }
>
> Supposed this is parsed to an AST, without doing name resolving. By
> then, I have A1 in the outer scope, and A2 in the inner one.

I don't think you can parse C without name resolving as you go because
of the typedef issue.  Since you have to keep a symbol table for that,
you might as well use it for other things.

Logically, nested scopes are just a stack or maps.  A linked list of
hash tables would be one model of that and might even be reasonably
efficient for normal C code.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#103470

On Wednesday, February 8, 2017 at 8:32:35 AM UTC-6, Ben Bacarisse wrote:
> Logically, nested scopes are just a stack or maps.  A linked list of
> hash tables would be one model of that and might even be reasonably
> efficient for normal C code.

An alternative which could be useful in cases where one will want to keep all
symbols that have ever been defined (for feeding to a debugger, e.g.) would
be to be to use a hash table to identify for each name the most recent symbol
table entry associated with it, and then have each symbol table entry contain
the index of the previous entry associated with that name (if any) and an
identifier for the scope where the symbol is declared.   Another table (or
entries in the same table) would identify all scopes that have been declared
and specify the parent of each.

[toc] | [prev] | [next] | [standalone]

#103485

On 08/02/2017 15:28, supercat@casperkitty.com wrote:
> On Wednesday, February 8, 2017 at 8:32:35 AM UTC-6, Ben Bacarisse wrote:
>> Logically, nested scopes are just a stack or maps.  A linked list of
>> hash tables would be one model of that and might even be reasonably
>> efficient for normal C code.
>
> An alternative which could be useful in cases where one will want to keep all
> symbols that have ever been defined (for feeding to a debugger, e.g.) would
> be to be to use a hash table to identify for each name the most recent symbol
> table entry associated with it, and then have each symbol table entry contain
> the index of the previous entry associated with that name (if any) and an
> identifier for the scope where the symbol is declared.   Another table (or
> entries in the same table) would identify all scopes that have been declared
> and specify the parent of each.
>

The scheme I'm planning to use (to parse C code) uses a single hash 
table of symbol entries.

For each unique identifier, there is one generic entry in that hash 
table, joined to a linked list that contains all instances of that name 
across all functions and blocks. (And, in the original scheme, across 
all modules. But C likes modules to be compiled entirely independently 
from each other.)

Blocks are numbered sequentially in each function, and that number is 
stored with each identifier's symbol entry.

There is a simple stack, but that is to manage the block numbers as 
blocks are created then discarded.

I hoping that will be fast enough without needed to purge symbols 
associated with a function. They will be needed anyway for diagnostics.

-- 
bartc

[toc] | [prev] | [next] | [standalone]

#103487

BartC <bc@freeuk.com> writes:
[...]
> For each unique identifier, there is one generic entry in that hash 
> table, joined to a linked list that contains all instances of that name 
> across all functions and blocks. (And, in the original scheme, across 
> all modules. But C likes modules to be compiled entirely independently 
> from each other.)
[...]

Just one small observation.  If two separate scopes happen to define the
same identifier, for example:

    void foo(void) {
        for (int i = 0; i < N; i ++) {
            /* ... */
        }
    }

    void bar(void) {
        for (int i = 0; i < N; i ++) {
            /* ... */
        }
    }

then the two instances of the name "i" are completely independent.
Consider whether it makes sense to include them both in the same linked
list.  (If the symbol table is used for things other than compiling
code, it might well make sense.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#103493

On 08/02/2017 20:38, Keith Thompson wrote:
> BartC <bc@freeuk.com> writes:
> [...]
>> For each unique identifier, there is one generic entry in that hash
>> table, joined to a linked list that contains all instances of that name
>> across all functions and blocks. (And, in the original scheme, across
>> all modules. But C likes modules to be compiled entirely independently
>> from each other.)
> [...]
>
> Just one small observation.  If two separate scopes happen to define the
> same identifier, for example:
>
>     void foo(void) {
>         for (int i = 0; i < N; i ++) {
>             /* ... */
>         }
>     }
>
>     void bar(void) {
>         for (int i = 0; i < N; i ++) {
>             /* ... */
>         }
>     }
>
> then the two instances of the name "i" are completely independent.
> Consider whether it makes sense to include them both in the same linked
> list.  (If the symbol table is used for things other than compiling
> code, it might well make sense.)

Yes, that can happen if symbols defined in each function are not purged. 
Entries are linked together in other ways so it knows that one 'i' 
belongs to 'foo' and the other belongs to 'bar'.

I use the technique on other projects, where even if there are dozens of 
entries for 'i', it can manage byte-code compiling (which equates to 
parsing a language like C) at up to 1Mlps or more.


-- 
bartc

[toc] | [prev] | [next] | [standalone]

#103498

On 08/02/2017 22:32, Stefan Ram wrote:
> BartC <bc@freeuk.com> writes:
>> On 08/02/2017 20:38, Keith Thompson wrote:
>>>     void foo(void) {
>>>         for (int i = 0; i < N; i ++) {
>>>             /* ... */
>>>         }
>>>     }
>>>     void bar(void) {
>>>         for (int i = 0; i < N; i ++) {
>>>             /* ... */
>>>         }
>>>     }
>>> then the two instances of the name "i" are completely independent.
>> Entries are linked together in other ways so it knows that one 'i'
>> belongs to 'foo' and the other belongs to 'bar'.
>
>   Even when both »i« belong to the same »f«, they can be completely
>   independent.
>
>   main.c
>
> #include <stdio.h>
> #include <stdlib.h>
>
> void f( int const depth )
> { int const i = rand();
>   if( !depth )f( depth + 1 );
>   printf( "i = %d\n", i ); }
>
> int main( void ){ f( 0 ); }
>
>   transcript
>
> i = 18467
> i = 41

That's at runtime. At compile-time, each of the 'i' variables in Keith's 
example has only one instance.

[toc] | [prev] | [next] | [standalone]

#103550

On 08/02/2017 02:13, BartC wrote:
>
> I've been trying to understand this aspect,

I've been using gcc to test fragments of code, as being perhaps one of 
the more definitive implementations of C.

But it can be exasperating in how forgiving it is of code that is 
obviously wrong. What exactly do you have to do to make it report an 
error, rather than a warning?

Here's the example that led me to post:

   int;

Here, gcc merely warns against a useless declaration. Other compilers 
either report an outright error, or report nothing at all, with default 
options (DMC and MSVC).

Does a line such as this belong in any correct program? Does the 
standard actually allow this? If so then it has a bug.

(Actually I was testing typedefs:

    typedef double T;
    {
      const T;
      T;

expecting an error on one of these lines. Is it defining a new const int 
variable called T, or is it defining a const double with a missing name? 
It doesn't help when the compiler apparently isn't bothered no matter 
what I write!

This was another test:

     enum E {a=1};
     {
        typedef enum E T;
        enum E {b=2} x;
        T y;

x is an enum of type {b=2}. But what about y? I assuming it is of type 
{a=1}. (Not that it makes much difference as both x,y are really ints I 
think. But it shows how typedefs and defines could give different results.))

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#103557

BartC <bc@freeuk.com> writes:

> ... What exactly do you have to do to make it report an
> error, rather than a warning?

-Werror

> Here's the example that led me to post:
>
>   int;

<snip>
> ... Does the
> standard actually allow this?

No.

> ... It doesn't help when the compiler apparently isn't bothered no
> matter what I write!

The compiler is bothered by it -- bothered enough to tell you about it.
Lots of people don't like gcc's default choices about what provokes an
error and what a warning, but I suspect that would be true whatever the
choices it made.

Speculating..., gcc does this for two reasons.  First, you generally get
better diagnostics from a successful parse than from a syntax error, so
it is not uncommon to be very lax in the syntax that is accepted and
then report some other failure when the parse tree is inspected (here,
the fact that nothing is being declared).

Secondly, a C compiler has to be able to parse declaration-like forms
in function prototypes where the name is optional:

  void f(int, const char *, void (*)(int *));

So, since it's likely that the parser can already understand "int;" it
might as well do so in order to give you that better diagnostic.

<snip>
> This was another test:
>
>     enum E {a=1};
>     {
>        typedef enum E T;
>        enum E {b=2} x;
>        T y;
>
> x is an enum of type {b=2}.

The enum constants are not part of the type, but I can see what you are
getting at.  All you know about x is that it is of some type compatible
with char or a signed or unsigned integer type capable of representing
all the listed constants.  The enumeration constants themselves (a and b
here) are of type int and play no role in the type at all once the range
of them has been used to determine the type for declared objects of the
enumeration.

> But what about y? I assuming it is of type {a=1}.

It has some integer type capable of representing the value 1.  As the
author of the implementation, you get to choose the type.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#103565

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> BartC <bc@freeuk.com> writes:
>
>> ... What exactly do you have to do to make it report an
>> error, rather than a warning?
>
> -Werror

Or -pedantic-errors.

-Werror turns all warnings into fatal errors, which is great if you want
to reject everything that gcc warns about, but it can be overkill.

-pedantic errors causes all standard-required diagnostics to be fatal
errors.  Use it along with, for example, -std=c11.

[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#103572

Keith Thompson <kst-u@mib.org> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> BartC <bc@freeuk.com> writes:
>>
>>> ... What exactly do you have to do to make it report an
>>> error, rather than a warning?
>>
>> -Werror
>
> Or -pedantic-errors.
>
> -Werror turns all warnings into fatal errors, which is great if you want
> to reject everything that gcc warns about, but it can be overkill.
>
> -pedantic errors causes all standard-required diagnostics to be fatal
> errors.  Use it along with, for example, -std=c11.

Yes, thanks, that's often much more useful.  And, in this case, you
don't even need to give a -std= argument (though no doubt that helps in
other cases), as plain gcc -pedantic-errors then reports a lone type as
an error.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#103573

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>> BartC <bc@freeuk.com> writes:
>>>
>>>> ... What exactly do you have to do to make it report an
>>>> error, rather than a warning?
>>>
>>> -Werror
>>
>> Or -pedantic-errors.
>>
>> -Werror turns all warnings into fatal errors, which is great if you want
>> to reject everything that gcc warns about, but it can be overkill.
>>
>> -pedantic errors causes all standard-required diagnostics to be fatal
>> errors.  Use it along with, for example, -std=c11.
>
> Yes, thanks, that's often much more useful.  And, in this case, you
> don't even need to give a -std= argument (though no doubt that helps in
> other cases), as plain gcc -pedantic-errors then reports a lone type as
> an error.

Yes, but the default version has changed with different releases of gcc.
Prior to gcc 5, IIRC, the default was "-std=gnu89" (C89/C90 with
GNU-specific extensions).  In gcc 5 and later, the default is
"-std=gnu11".  If you're compiling code on multiple platforms, as BartC
seems to be doing, it's probably best to specify which standard you
want.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#103780

On 09/02/17 22:57, Keith Thompson wrote:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>> BartC <bc@freeuk.com> writes:
>>>>
>>>>> ... What exactly do you have to do to make it report an
>>>>> error, rather than a warning?
>>>>
>>>> -Werror
>>>
>>> Or -pedantic-errors.
>>>
>>> -Werror turns all warnings into fatal errors, which is great if you want
>>> to reject everything that gcc warns about, but it can be overkill.
>>>
>>> -pedantic errors causes all standard-required diagnostics to be fatal
>>> errors.  Use it along with, for example, -std=c11.
>>
>> Yes, thanks, that's often much more useful.  And, in this case, you
>> don't even need to give a -std= argument (though no doubt that helps in
>> other cases), as plain gcc -pedantic-errors then reports a lone type as
>> an error.
> 
> Yes, but the default version has changed with different releases of gcc.
> Prior to gcc 5, IIRC, the default was "-std=gnu89" (C89/C90 with
> GNU-specific extensions).  In gcc 5 and later, the default is
> "-std=gnu11".  If you're compiling code on multiple platforms, as BartC
> seems to be doing, it's probably best to specify which standard you
> want.
> 

I think it is best to specify which standard you want anyway, regardless
of the versions or platforms you are using.  In particular, if you want
to stick to standard C (as you usually do if you are interested in
-pedantic), you want to specify a C standard without the gcc extensions.

[toc] | [prev] | [next] | [standalone]

#103583

On 09/02/2017 20:25, Keith Thompson wrote:
> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> BartC <bc@freeuk.com> writes:
>>
>>> ... What exactly do you have to do to make it report an
>>> error, rather than a warning?
>>
>> -Werror
>
> Or -pedantic-errors.
>
> -Werror turns all warnings into fatal errors, which is great if you want
> to reject everything that gcc warns about, but it can be overkill.

OK, that's forcing gcc to report an error. But neither is quite what I 
meant, which is how wrong does a program have to be before gcc will say 
'error:' without needing to be coerced into doing so with options.

[toc] | [prev] | [next] | [standalone]

#103585

BartC <bc@freeuk.com> writes:

> On 09/02/2017 20:25, Keith Thompson wrote:
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>> BartC <bc@freeuk.com> writes:
>>>
>>>> ... What exactly do you have to do to make it report an
>>>> error, rather than a warning?
>>>
>>> -Werror
>>
>> Or -pedantic-errors.
>>
>> -Werror turns all warnings into fatal errors, which is great if you want
>> to reject everything that gcc warns about, but it can be overkill.
>
> OK, that's forcing gcc to report an error. But neither is quite what I
> meant, which is how wrong does a program have to be before gcc will
> say 'error:' without needing to be coerced into doing so with options.

Why do you care?  You know how to get what you asked for so this just
looks like another excuse to moan about gcc.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#103587

On 10/02/2017 00:42, Ben Bacarisse wrote:
> BartC <bc@freeuk.com> writes:
>
>> On 09/02/2017 20:25, Keith Thompson wrote:
>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>> BartC <bc@freeuk.com> writes:
>>>>
>>>>> ... What exactly do you have to do to make it report an
>>>>> error, rather than a warning?
>>>>
>>>> -Werror
>>>
>>> Or -pedantic-errors.
>>>
>>> -Werror turns all warnings into fatal errors, which is great if you want
>>> to reject everything that gcc warns about, but it can be overkill.
>>
>> OK, that's forcing gcc to report an error. But neither is quite what I
>> meant, which is how wrong does a program have to be before gcc will
>> say 'error:' without needing to be coerced into doing so with options.
>
> Why do you care?  You know how to get what you asked for so this just
> looks like another excuse to moan about gcc.

I'm not partisan. I recently listed how six compilers behaved on a 
particular problem. Only two I thought properly reported the error. gcc 
half did so (by making it a warning), and the other three failed IMO.

And to repeat: -Werror is not the answer. I want actual hard errors 
(including syntax errors) to be reported as errors. I don't want a whole 
bunch of harmless warnings to be turned into errors, because then my 
program won't compile. And I won't learn what kinds of things are 
considered serious.

Another example; should this be an error:

   struct S {int x,y;};
   struct S {int x,y;};

Most compilers say yes; one (not gcc) says no. It's hard to get a 
consensus on these things. To me, this is little different from 
repeating a function declaration.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#103590

BartC <bc@freeuk.com> writes:

> On 10/02/2017 00:42, Ben Bacarisse wrote:
>> BartC <bc@freeuk.com> writes:
>>
>>> On 09/02/2017 20:25, Keith Thompson wrote:
>>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>>> BartC <bc@freeuk.com> writes:
>>>>>
>>>>>> ... What exactly do you have to do to make it report an
>>>>>> error, rather than a warning?
>>>>>
>>>>> -Werror
>>>>
>>>> Or -pedantic-errors.
>>>>
>>>> -Werror turns all warnings into fatal errors, which is great if you want
>>>> to reject everything that gcc warns about, but it can be overkill.
>>>
>>> OK, that's forcing gcc to report an error. But neither is quite what I
>>> meant, which is how wrong does a program have to be before gcc will
>>> say 'error:' without needing to be coerced into doing so with options.
>>
>> Why do you care?  You know how to get what you asked for so this just
>> looks like another excuse to moan about gcc.
>
> I'm not partisan.

Your complaint, phrased slightly sarcastically, was explicitly about gcc
both times.

<snip>
> And to repeat: -Werror is not the answer. I want actual hard errors
> (including syntax errors) to be reported as errors.

OK, but that's not what you asked for.  The first request was for a way
to "make it [gcc] report an error, rather than a warning".  The second
sounds rhetorical which is why I didn't answer it: "how wrong does a
program have to be before gcc will say 'error:' without needing to be
coerced into doing so with options".  How could anyone possibly answer
that question?

So, you want something you call "hard errors" to be reported as errors
while

> I don't want a whole bunch of harmless warnings to be turned into errors,

an unspecified set of "harmless warnings" must remain harmless
warnings.  Currently the best answer is

 -pedantic-errors

Does that not do what you want?

I can't evaluate it because, while it should report all syntax errors,
I'm not sure what else you consider "hard" or whether you consider
something "harmless" that it will turn into an error.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

Page 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

Back to top | Article view | comp.lang.c

csiph-web