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 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

#103603

On 10/02/2017 01:49, Ben Bacarisse wrote:
> BartC <bc@freeuk.com> writes:

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

That's supposed to be the best.

>  -pedantic-errors
>
> Does that not do what you want?

I will try it. (But it also reports things such as 'string longer than 
4095 characters. It also fails some of my own programs which currently 
work. If it means extra work to get my own C code to compile, I may have 
to relax my ideas of what constitutes an error!)

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

I consider syntax errors 'hard' (notice the word 'error' in 'syntax 
error'; you don't often hear about syntax warnings!).

Although compilers don't necessary abort on the first error so there's 
no reason why they can't carry on if they can. But I would want to fix a 
syntax error before trying to run a program.

(Actually I've only just noticed that C compilers distinguish between 
only warnings and errors. My own tools categorise them as lexical, 
syntax, name-resolution, type and code generation errors, corresponding 
to the different stages. But they are all errors; no warnings. A warning 
would have to come from a different kind of tool.)

-- 
bartc

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

#103647

BartC <bc@freeuk.com> writes:

> On 10/02/2017 01:49, Ben Bacarisse wrote:
>> BartC <bc@freeuk.com> writes:
>
>> Your complaint, phrased slightly sarcastically, was explicitly about gcc
>> both times.
>
> That's supposed to be the best.

You cut the context.  Here, let me put it back:

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

>>  -pedantic-errors
>>
>> Does that not do what you want?
>
> I will try it. (But it also reports things such as 'string longer than
> 4095 characters.

Why would you not want to know about that?  You appear to want to know
what you can and can not rely on when writing C.  To investigate what is
valid C you need to know about this sort of thing.

> It also fails some of my own programs which currently
> work. If it means extra work to get my own C code to compile, I may
> have to relax my ideas of what constitutes an error!)

Your original complaint was about overly lax compilers that let too much
through meaning you did not know what C really permitted and what it did
not.  This was in the context of learning about the language so you can
implement it.  I was not suggesting you'd use this flag on your own
code.  What sort of code you want to *write* (as opposed to the code
your compiler should accept) is another matter altogether.

>> 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.
>
> I consider syntax errors 'hard' (notice the word 'error' in 'syntax
> error'; you don't often hear about syntax warnings!).

The word *else* clearly means I know you consider syntax errors to be
hard errors.  It's the others I am claiming to be unsure about.  But
please note: I'm not asking to know.  I simply stating that I can't say
if -pedantic-errors will do what you want.  If it doesn't, I think you
are out of luck as far as gcc is concerned.

<snip>
-- 
Ben.

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

#103649

On Friday, February 10, 2017 at 5:48:23 PM UTC-6, Ben Bacarisse wrote:
> BartC writes:
> >>  -pedantic-errors
> >>
> >> Does that not do what you want?
> >
> > I will try it. (But it also reports things such as 'string longer than
> > 4095 characters.
> 
> Why would you not want to know about that?  You appear to want to know
> what you can and can not rely on when writing C.  To investigate what is
> valid C you need to know about this sort of thing.

Implementations are not required to process string literals longer than
4095 characters, but such literals are not a constraint violation.  A
conforming implementation is allowed to accept such literals or not as
it sees fit, and a Conforming program may use such literals (although
they would prevent the program from being Strictly Conforming).

By contrast, certain other constructs which gcc would allow by default
are not allowed to appear in a conforming program, and conforming
implementations are required to report such constraint violations.

I don't think it's unreasonable to think that a -pedantic-errors flag
should cause constraint violations to be regarded as errors, but not
treat as errors constructs which are allowed to appear in Conforming
programs.

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

#103650

supercat@casperkitty.com writes:
[...]
> I don't think it's unreasonable to think that a -pedantic-errors flag
> should cause constraint violations to be regarded as errors, but not
> treat as errors constructs which are allowed to appear in Conforming
> programs.

Here's what the gcc manual says on the topic.  ("-Wpedantic" and
"-pedantic" are synonymous.)

     Some users try to use '-Wpedantic' to check programs for strict ISO
     C conformance.  They soon find that it does not do quite what they
     want: it finds some non-ISO practices, but not all--only those for
     which ISO C _requires_ a diagnostic, and some others for which
     diagnostics have been added.

     A feature to report any failure to conform to ISO C might be useful
     in some instances, but would require considerable additional work
     and would be quite different from '-Wpedantic'.  We don't have
     plans to support such a feature in the near future.

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

#103738

On Friday, February 10, 2017 at 6:21:23 PM UTC-6, Keith Thompson wrote:
> supercat writes:
> [...]
> > I don't think it's unreasonable to think that a -pedantic-errors flag
> > should cause constraint violations to be regarded as errors, but not
> > treat as errors constructs which are allowed to appear in Conforming
> > programs.
> 
> Here's what the gcc manual says on the topic.  ("-Wpedantic" and
> "-pedantic" are synonymous.)
> 
>      Some users try to use '-Wpedantic' to check programs for strict ISO
>      C conformance.  They soon find that it does not do quite what they
>      want: it finds some non-ISO practices, but not all--only those for
>      which ISO C _requires_ a diagnostic, and some others for which
>      diagnostics have been added.
> 
>      A feature to report any failure to conform to ISO C might be useful
>      in some instances, but would require considerable additional work
>      and would be quite different from '-Wpedantic'.  We don't have
>      plans to support such a feature in the near future.

By my interpretation, the phrase "failure to conform to ISO C" means
"construct which ISO does not require implementations to support".  Being
able to squawk at constructs for which diagnostics are required without
having to simultaneously make the compiler squawk at constructs which do
not require one should be a comparatively simpler task, at least with
regard to things like literals over 4095 characters.

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

#103977

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

> supercat@casperkitty.com writes:
> [...]
>> I don't think it's unreasonable to think that a -pedantic-errors flag
>> should cause constraint violations to be regarded as errors, but not
>> treat as errors constructs which are allowed to appear in Conforming
>> programs.
>
> Here's what the gcc manual says on the topic.  ("-Wpedantic" and
> "-pedantic" are synonymous.)
>
>      Some users try to use '-Wpedantic' to check programs for strict ISO
>      C conformance.  They soon find that it does not do quite what they
>      want:  it finds some non-ISO practices, but not all--only those for
>      which ISO C _requires_ a diagnostic, and some others for which
>      diagnostics have been added.
>
>      A feature to report any failure to conform to ISO C might be useful
>      in some instances, but would require considerable additional work
>      and would be quite different from '-Wpedantic'.  We don't have
>      plans to support such a feature in the near future.

It would be nice to have, (a) an option that generates diagnostics
in all cases where the Standard requires a diagnostic, and only
those cases, and (b) a different option that generates diagnostics
in cases that may work in some implementations but do /not/ work
in this one, and (c) a third option that generates diagnostics in
cases that /might not work/ in other implementations even though
they /do/ work in this implementation.  The -pedantic option is
all of (a) plus some of (c), and probably also some of (b).
Unfortunately gcc doesn't give separate controls for these three
cases so -pedantic forces the (c) cases whether they are wanted or
not.  IMO that is a serious omission.  Normally I would prefer to
have the (a) and (b) cases, as errors, in all compiles, and
sometimes also the (c) cases, as warnings, eg, during reviews for
code cleanliness.

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

#103591

BartC <bc@freeuk.com> writes:
[...]
> 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.

Then use -std=cNN -pedantic-errors, as I already explained.

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

gcc correctly rejects it.  In fact every copy of gcc that I can find
treats it as a fatal error, even with no command-line options.

See N1570 6.7p3 and 6.7.2.3p1.  The latter says, "A specific type shall
have its content defined at most once.".

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

#103609

On Thursday, February 9, 2017 at 7:04:08 PM UTC-6, Bart wrote:
> 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.

I would suggest that the most helpful behavior for a language would be to
allow a redefinition *provided that it matches the original*, and squawk at
a redefinition which does not match the original.  Supporting such semantics
may have been difficult on compilers that were running with extremely limited
resources, making it necessary for such compilers to either accept or reject
such constructs without regard for whether they match earlier definitions.

Personally, I think the Standard should have specified that code seeking to
be portable should avoid using such constructs, but compilers seeking to
maximize compatibility with the existing corpus of C code should support
them.  Having multiple header files that each say:

    #ifdef FOO_STRUCT
    #define FOO_STRUCT
    struct foo { ... }
    #endif

makes code far less robust than it would be if each header file was allowed
to simply declare the structure for itself *and have the compiler validate
that it matched the expected definition*.

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

#103610

supercat@casperkitty.com writes:
> On Thursday, February 9, 2017 at 7:04:08 PM UTC-6, Bart wrote:
>> 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.
>
> I would suggest that the most helpful behavior for a language would be to
> allow a redefinition *provided that it matches the original*, and squawk at
> a redefinition which does not match the original.  Supporting such semantics
> may have been difficult on compilers that were running with extremely limited
> resources, making it necessary for such compilers to either accept or reject
> such constructs without regard for whether they match earlier definitions.

I don't understand how that would be an advantage.

C as it's currently defined does not, in most cases, permit identical
redefinitions.  I fail to see how this causes any inconvenience.  Just
define everything *once*.

> Personally, I think the Standard should have specified that code seeking to
> be portable should avoid using such constructs, but compilers seeking to
> maximize compatibility with the existing corpus of C code should support
> them.  Having multiple header files that each say:
>
>     #ifdef FOO_STRUCT
>     #define FOO_STRUCT
>     struct foo { ... }
>     #endif
>
> makes code far less robust than it would be if each header file was allowed
> to simply declare the structure for itself *and have the compiler validate
> that it matched the expected definition*.

The usual approach, which works perfectly well, is to define
    struct foo { ... };
in exactly one header, and have any code that needs to refer to the
type include that header.  Why would you want to define it in more
than one place?

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

#103612

On Friday, February 10, 2017 at 10:45:23 AM UTC-6, Keith Thompson wrote:
> I don't understand how that would be an advantage.
> 
> C as it's currently defined does not, in most cases, permit identical
> redefinitions.  I fail to see how this causes any inconvenience.  Just
> define everything *once*.

A declaration like "int i;" maps "i" to a region of storage *which was not
formerly used for any purpose*.  If such a declaration were repeated, then
following the declaration "i" would need to map to a region of storage which
had been formerly used before that second declaration, or it would have to
map it to something different from the earlier definition.

A struct declaration, by contrast, does not reserve any storage but merely
defines symbols.  The purpose of such a declaration is to leave the system
with certain struct symbols defined, and the state of the system after a
second declaration could be precisely as it should be, whether or not a
matching declaration had previously existed.

> > Personally, I think the Standard should have specified that code seeking to
> > be portable should avoid using such constructs, but compilers seeking to
> > maximize compatibility with the existing corpus of C code should support
> > them.  Having multiple header files that each say:
> >
> >     #ifdef FOO_STRUCT
> >     #define FOO_STRUCT
> >     struct foo { ... }
> >     #endif
> >
> > makes code far less robust than it would be if each header file was allowed
> > to simply declare the structure for itself *and have the compiler validate
> > that it matched the expected definition*.
> 
> The usual approach, which works perfectly well, is to define
>     struct foo { ... };
> in exactly one header, and have any code that needs to refer to the
> type include that header.  Why would you want to define it in more
> than one place?

If some inline functions in bar.c/bar.h and boz.c/boz.h both make use of
a type which is defined in foo.h, the type is unlikely to change, and
many consumers of bar.? and boz.? won't need to use anything that's
in boz.h, including foo.h from within bar.h and boz.h will increase the
number of files that need to be included when compiling code which does
not need any of the features in foo.h, and will clutter up the namespace
with a bunch of symbols from foo.h that the code neither needs nor wants.

If there's no need for inline functions or function-like macros, incomplete
structure types would often be sufficient.  If, however, one wants to have
an inline function that can quickly process common-case behavior, that may
require having a complete structure type available.

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

#103630

On 2/10/2017 11:44 AM, Keith Thompson wrote:
> supercat@casperkitty.com writes:
>> On Thursday, February 9, 2017 at 7:04:08 PM UTC-6, Bart wrote:
>>> 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.
>>
>> I would suggest that the most helpful behavior for a language would be to
>> allow a redefinition *provided that it matches the original*, and squawk at
>> a redefinition which does not match the original.  Supporting such semantics
>> may have been difficult on compilers that were running with extremely limited
>> resources, making it necessary for such compilers to either accept or reject
>> such constructs without regard for whether they match earlier definitions.
> 
> I don't understand how that would be an advantage.
> 
> C as it's currently defined does not, in most cases, permit identical
> redefinitions.  I fail to see how this causes any inconvenience.  Just
> define everything *once*.
> 
>> Personally, I think the Standard should have specified that code seeking to
>> be portable should avoid using such constructs, but compilers seeking to
>> maximize compatibility with the existing corpus of C code should support
>> them.  Having multiple header files that each say:
>>
>>     #ifdef FOO_STRUCT
>>     #define FOO_STRUCT
>>     struct foo { ... }
>>     #endif
>>
>> makes code far less robust than it would be if each header file was allowed
>> to simply declare the structure for itself *and have the compiler validate
>> that it matched the expected definition*.
> 
> The usual approach, which works perfectly well, is to define
>     struct foo { ... };
> in exactly one header, and have any code that needs to refer to the
> type include that header.  Why would you want to define it in more
> than one place?
> 

It would cause a real problem in some instances, such as when code is
later modified:

void f(int x) {
   int i = 3;
   ... some code
   if (x > 3) {    // added code
      int i;
      ... more code
   }              // added code

Now the second "i" has different scope and refers to a different
variable than the first "i".  If the following code depended on them
being the same, you have a major problem.

And what about the following code?

void f(int x) {
   int i = 3;
   ... some code
   int i = 42;
   ... more code

What is the correct value for i?

I see no problem with C as it is, and potential problems with the "fix".

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

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

#103632

On Friday, February 10, 2017 at 3:43:04 PM UTC-6, Jerry Stuckle wrote:
> And what about the following code?
> 
> void f(int x) {
>    int i = 3;
>    ... some code
>    int i = 42;
>    ... more code
> 
> What is the correct value for i?
> 
> I see no problem with C as it is, and potential problems with the "fix".

Given the definitions "int a; int b;", the identifiers "a" and "b" would
identify different objects.  Repeating the same name for both definitions
would cause that name to refer to different objects, which is rightly
forbidden.

On the other hand, given "struct x {int a;}; struct y {int a;};" the only
way in which the definitions would not be equivalent would be as a
consequence of type-compatibility rules which say that for things of
structure type to be compatible the structures need to have the same tag.
If the two declarations were allowed to have the same tag and everything
else about them was identical, then both uses of the tag would identify
the same structure type.

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

#103635

On 10/02/2017 22:04, supercat@casperkitty.com wrote:

> Given the definitions "int a; int b;", the identifiers "a" and "b" would
> identify different objects.  Repeating the same name for both definitions
> would cause that name to refer to different objects, which is rightly
> forbidden.

At file-scope, that's allowed:

  int a; int b;
  int a; int b;
  int a; int b;
  int a; int b;
  int a; int b;
  int a; int b;
  int a; int b;
  int a; int b;

But they probably don't count as definitions.

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

#103640

On 2/10/2017 2:52 PM, BartC wrote:
> On 10/02/2017 22:04, supercat@casperkitty.com wrote:
>
>> Given the definitions "int a; int b;", the identifiers "a" and "b" would
>> identify different objects.  Repeating the same name for both definitions
>> would cause that name to refer to different objects, which is rightly
>> forbidden.
>
> At file-scope, that's allowed:
>
>  int a; int b;
>  int a; int b;
>  int a; int b;
>  int a; int b;
>  int a; int b;
>  int a; int b;
>  int a; int b;
>  int a; int b;
>
> But they probably don't count as definitions.

They do, but they are _tentative_. They all fold into a single 
zero-initialized external definition for 'a' (and another one for 'b') 
at the end of the containing translation unit.

-- 
Best regards,
Andrey Tarasevich

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

#103978

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.

Unfortunately -pedantic also gives diagnostics in some cases
where the Standard does not require them, and where the case
involved actually works on the particular system being targeted
(and, in some cases, I believe most implementations being used
today, although of course I am not sure of that).

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

#103577

On 09/02/2017 19:53, Ben Bacarisse wrote:
> BartC <bc@freeuk.com> writes:

>>   int;
>
> <snip>
>> ... Does the
>> standard actually allow this?
>
> No.

Error, then.

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

A weak argument. As I understand it, a construct that includes a type 
either expects a name (eg ordinary declaration), or doesn't expect one 
(eg a cast), or can be with or without a name (eg function param).

The first two should be straight errors if a name is missing or whatever.

The third just makes it tricky, for people reading the code too not just 
language processors:

  int fn (int (((T))));

This is a function with an int parameter called T. But if a declaration 
like this is visible:

  typedef double T;

then that parameter becomes some sort of function or pointer to 
function, and doesn't have a name. But you don't know that until you're 
N levels deep in parentheses.

(Of course, this isn't poor design because I'm not looking at the wider 
picture!)

-- 
Bartc

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

#103579

BartC <bc@freeuk.com> writes:

> On 09/02/2017 19:53, Ben Bacarisse wrote:
>> BartC <bc@freeuk.com> writes:
>
>>>   int;
>>
>> <snip>
>>> ... Does the
>>> standard actually allow this?
>>
>> No.
>
> Error, then.
>
>> 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.
>
> A weak argument.

Well you cut half of it, and specifically the part where I said it was
speculation.  If if you don't find it a helpful explanation about what
gcc might be doing, that's fine.  Maybe your parser will be able to give
good diagnostics without lax parsing, but I've found it hard in the past
(though not for C syntax).

> As I understand it, a construct that includes a type
> either expects a name (eg ordinary declaration), or doesn't expect one
> (eg a cast), or can be with or without a name (eg function param).
>
> The first two should be straight errors if a name is missing or
> whatever.

There's no question about that.  Did you misunderstand me?  My
speculation was about how to give the best diagnostic.

> The third just makes it tricky, for people reading the code too not
> just language processors:
>
>  int fn (int (((T))));
>
> This is a function with an int parameter called T. But if a
> declaration like this is visible:
>
>  typedef double T;
>
> then that parameter becomes some sort of function or pointer to
> function,

It's a function type and you know what happens to those in parameter
lists.  Many C programmers have probably never seen a function type --
they are very odd looking.

> and doesn't have a name. But you don't know that until
> you're N levels deep in parentheses.

You just throw them away.  I don't think there is any place where more
than one pair makes any difference.  Certainly not here. 

> (Of course, this isn't poor design because I'm not looking at the
> wider picture!)

What wider picture do you think you are missing?  You are writing a
parser so you must surely be looking at this in the most general way
possible, no?

-- 
Ben.

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

#103582

On 09/02/2017 23:36, Ben Bacarisse wrote:
> BartC <bc@freeuk.com> writes:

>>  int fn (int (((T))));
>>
>> This is a function with an int parameter called T. But if a
>> declaration like this is visible:
>>
>>  typedef double T;
>>
>> then that parameter becomes some sort of function or pointer to
>> function,
>
> It's a function type and you know what happens to those in parameter
> lists.

Um... no? Is it the same sort of thing goes on with array types? An 
actual array or function can't be passed, so it's converted (T[] to *T, 
function to pointer-to-function presumably).

It doesn't look like a pointer, but compilers report it as a pointer (if 
they detect it at all that is!); eg:

typedef double T;

int fn(int (((T))));

int main(void){
   fn(10);
}

Pelles C: error: expected int __cdecl (*)(double)...
lccwin:   error: expected pointer to to int function(double)
DMC:      no error or warning
gcc:      warning: expected int(*)(T)
Tiny C:   no error or warning
MSVC:     error: syntax problem to do with ) and {

(And the bad design problem is this: a function taking a int parameter 
expressed as above works perfectly well. Until something is introduced 
later, perhaps in an included header, that defines a typedef with a name 
matching the parameter. Now the meaning changes. But with certain 
compilers, you won't know.

With the designs I do, that doesn't arise because a function pointer 
type (function types are impossible to declare) always involves the 
keyword 'function' or 'proc'. It makes parsing foolproof, and it's 
helpful for humans too!)

>> and doesn't have a name. But you don't know that until
>> you're N levels deep in parentheses.
>
> You just throw them away.

Yes, but I was hoping to know earlier on if something was a function 
type and whether parameters were named.

-- 
Bartc

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

#103584

BartC <bc@freeuk.com> writes:

> On 09/02/2017 23:36, Ben Bacarisse wrote:
>> BartC <bc@freeuk.com> writes:
>
>>>  int fn (int (((T))));
>>>
>>> This is a function with an int parameter called T. But if a
>>> declaration like this is visible:
>>>
>>>  typedef double T;
>>>
>>> then that parameter becomes some sort of function or pointer to
>>> function,
>>
>> It's a function type and you know what happens to those in parameter
>> lists.
>
> Um... no? Is it the same sort of thing goes on with array types? An
> actual array or function can't be passed, so it's converted (T[] to
> *T, function to pointer-to-function presumably).

Yes.  I was sure this had come up before.  Maybe I'm misremembering --
my intent was not to sound snide.

> It doesn't look like a pointer, but compilers report it as a pointer

The type

   int (double)

is a function type (int (T) with the typedef) so, no, it does not look
like a pointer type.  That's like array types in parameter lists -- they
don't look like pointer types either.

<snip>
-- 
Ben.

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

#105361

Take these declarations at file-scope:

   struct FS {
     struct MS *M;
   };

   struct MS {
     int (*C)(int*);
   };

The behaviour I'm observing with existing C compilers is that struct tag 
MS defined inside struct tag FS appears to have file-scope.

So the two MS declarations, both refer to the same struct. And if I 
modify the first definition to:

struct FS {
   struct MS {int x,y,z;} *M;
};

then gcc for example complains that MS is later redefined.

Is this correct? I assume it must be (even if it's hard to understand 
why it would be like that, although I'm not really surprised any more).

Does this mean that struct tag names declared inside other structs don't 
have a scope constrained by the immediate enclosing struct, but by 
either file-scope or by a normal block-scope?

Another example, where the two lots of B and C share the same scope:

  int main(void){

  struct I{
   struct B {int x,y;}b;
   struct C {int x,y;}c;
  };

  struct F{
   struct B {float x,y;}b;
   struct C {float x,y;}c;
  };
}

-- 
Bartc

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

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

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

csiph-web