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

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

C declarations

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

Contents

  C declarations BartC <bc@freeuk.com> - 2017-01-30 13:00 +0000
    Re: C declarations David Brown <david.brown@hesbynett.no> - 2017-01-30 14:25 +0100
      Re: C declarations Keith Thompson <kst-u@mib.org> - 2017-01-30 11:42 -0800
    Re: C declarations Andrey Tarasevich <andreytarasevich@hotmail.com> - 2017-01-31 13:46 -0800
      Re: C declarations BartC <bc@freeuk.com> - 2017-01-31 22:13 +0000
        Re: C declarations Andrey Tarasevich <andreytarasevich@hotmail.com> - 2017-01-31 16:43 -0800
          Re: C declarations Andrey Tarasevich <andreytarasevich@hotmail.com> - 2017-01-31 17:06 -0800
        Re: C declarations Ian Collins <ian-news@hotmail.com> - 2017-02-01 17:58 +1300
          Re: C declarations luser droog <luser.droog@gmail.com> - 2017-01-31 22:42 -0800
            Re: C declarations Ian Collins <ian-news@hotmail.com> - 2017-02-01 19:48 +1300
              Re: C declarations Robert Wessel <robertwessel2@yahoo.com> - 2017-02-01 01:18 -0600
              Re: C declarations David Brown <david.brown@hesbynett.no> - 2017-02-01 10:10 +0100
                Re: C declarations BartC <bc@freeuk.com> - 2017-02-01 11:39 +0000
                  Re: C declarations David Brown <david.brown@hesbynett.no> - 2017-02-01 13:55 +0100
                    Re: C declarations BartC <bc@freeuk.com> - 2017-02-01 13:22 +0000
                      Re: C declarations David Brown <david.brown@hesbynett.no> - 2017-02-01 16:30 +0100
                        Re: C declarations Keith Thompson <kst-u@mib.org> - 2017-02-01 08:15 -0800
                          Re: C declarations supercat@casperkitty.com - 2017-02-01 08:44 -0800
                            Re: C declarations David Brown <david.brown@hesbynett.no> - 2017-02-01 20:56 +0100
                        Re: C declarations supercat@casperkitty.com - 2017-02-01 08:29 -0800
                          Re: C declarations BartC <bc@freeuk.com> - 2017-02-01 17:24 +0000
                            Re: C declarations fir <profesor.fir@gmail.com> - 2017-02-01 09:55 -0800
                              Re: C declarations BartC <bc@freeuk.com> - 2017-02-01 18:44 +0000
                                Re: C declarations Keith Thompson <kst-u@mib.org> - 2017-02-01 11:03 -0800
                                Re: C declarations fir <profesor.fir@gmail.com> - 2017-02-01 12:26 -0800
                                  Re: C declarations fir <profesor.fir@gmail.com> - 2017-02-01 13:03 -0800
                                    Re: C declarations fir <profesor.fir@gmail.com> - 2017-02-01 13:12 -0800
                                    Re: C declarations fir <profesor.fir@gmail.com> - 2017-02-03 16:07 -0800
                            Re: C declarations Keith Thompson <kst-u@mib.org> - 2017-02-01 10:44 -0800
                            Re: C declarations jameskuyper@verizon.net - 2017-02-01 11:08 -0800
                          Re: C declarations Keith Thompson <kst-u@mib.org> - 2017-02-01 10:40 -0800
                        Re: C declarations BartC <bc@freeuk.com> - 2017-02-01 17:04 +0000
                          Re: C declarations Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-02-01 19:58 +0000
                            Re: C declarations BartC <bc@freeuk.com> - 2017-02-01 21:23 +0000
                      Re: C declarations Keith Thompson <kst-u@mib.org> - 2017-02-01 08:08 -0800
                  Re: C declarations Andrey Tarasevich <andreytarasevich@hotmail.com> - 2017-02-01 12:45 -0800
    Re: C declarations Andrey Tarasevich <andreytarasevich@hotmail.com> - 2017-03-06 11:19 -0800
      Re: C declarations Keith Thompson <kst-u@mib.org> - 2017-03-06 11:27 -0800

Page 2 of 2 — ← Prev page 1 [2]

#102914

On 01/02/2017 16:29, supercat@casperkitty.com wrote:
> On Wednesday, February 1, 2017 at 9:30:23 AM UTC-6, David Brown wrote:
>> How can you be writing a parser, and complaining about what C does and
>> does not allow, and how other compilers match the standards, when you
>> haven't even bothered to /read/ the standards?  How are you making
>> making your code at the moment - by skim-reading a couple of Wikipedia
>> articles then some trial-and-error runs with a few existing compilers?
>
> The language Dennis Ritchie designed was not processed using a formal grammar,
> nor is a formal grammar the most efficient way to parse that language.  In
> addition, I don't think a formal grammar works well as a human-readable way of
> describing it either.

I found it pretty much impossible, especially the declaration stuff.

It doesn't help that so many compilers are happy to ignore what the spec 
says, and just give a warning. So it's possible to have a C file 
consisting of only:

  (((((a)))));

and that's fine. No matter that people will be scratching their heads 
wondering what it means. (In one of my languages, to declare a variable 
'a' of type 'int' I /have/ to write it as 'int a'; there's no other way. 
A bit boring, but there's less head-scratching.)

I suspect the grammar only exists to help with automatic tools, and K&R2 
says as much.

-- 
bartc

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

#102915

W dniu środa, 1 lutego 2017 18:24:18 UTC+1 użytkownik Bart napisał:
> On 01/02/2017 16:29, supercat@casperkitty.com wrote:
> > On Wednesday, February 1, 2017 at 9:30:23 AM UTC-6, David Brown wrote:
> >> How can you be writing a parser, and complaining about what C does and
> >> does not allow, and how other compilers match the standards, when you
> >> haven't even bothered to /read/ the standards?  How are you making
> >> making your code at the moment - by skim-reading a couple of Wikipedia
> >> articles then some trial-and-error runs with a few existing compilers?
> >
> > The language Dennis Ritchie designed was not processed using a formal grammar,
> > nor is a formal grammar the most efficient way to parse that language.  In
> > addition, I don't think a formal grammar works well as a human-readable way of
> > describing it either.
> 
> I found it pretty much impossible, especially the declaration stuff.
> 
> It doesn't help that so many compilers are happy to ignore what the spec 
> says, and just give a warning. So it's possible to have a C file 
> consisting of only:
> 
>   (((((a)))));
> 
> and that's fine. No matter that people will be scratching their heads 
> wondering what it means. (In one of my languages, to declare a variable 
> 'a' of type 'int' I /have/ to write it as 'int a'; there's no other way. 
> A bit boring, but there's less head-scratching.)
> 
> I suspect the grammar only exists to help with automatic tools, and K&R2 
> says as much.
> 
you always come to this point and you always get it 
wrong 

you will only scratch a head if you dont know how it works after learning how it works it will be same part of the language as thousands other parts

this implicit int (b legacy it seems) is interesting to 
me (i would like to get it working probably) - but c comitee spoiled so many thing they are soo weak .. 

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

#102918

On 01/02/2017 17:55, fir wrote:
> W dniu środa, 1 lutego 2017 18:24:18 UTC+1 użytkownik Bart napisał:

> So it's possible to have a C file
>> consisting of only:
>>
>>   (((((a)))));
>>
>> and that's fine. No matter that people will be scratching their heads
>> wondering what it means.

> you always come to this point and you always get it
> wrong
>
> you will only scratch a head if you dont know how it works after learning how it works it will be same part of the language as thousands other parts

C has many quirks that even experts can be confused over when faced with 
an unusual construct. For example:

   f(x);

This calls a function f with argument x, yes? Not necessarily, not if f 
is a typedef name, then it will declare x as a variable of type f.

(It think it was such an example that David Brown said he hadn't 
realised you could do.)

So, yes, (((((a))))); can be confusing. Because for a start, it can mean 
different things depending on context. And it doesn't exactly look like 
a typical declaration.

-- 
Bartc

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

#102919

BartC <bc@freeuk.com> writes:
[...]
> So, yes, (((((a))))); can be confusing. Because for a start, it can mean 
> different things depending on context. And it doesn't exactly look like 
> a typical declaration.

It isn't a declaration.  At block scope, it could be an expression
statement depending on how and whether `a` is declared.  At file
scope, it's invalid.

Some compilers might accept it with a warning, which is an acceptable
way to flag it as a violation of a constraint or syntax rule.
Compilers that accept it without a diagnostic are non-conforming (but
can likely be made reasonably conforming with the right options.)

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

#102925

W dniu środa, 1 lutego 2017 19:44:17 UTC+1 użytkownik Bart napisał:
> On 01/02/2017 17:55, fir wrote:
> > W dniu środa, 1 lutego 2017 18:24:18 UTC+1 użytkownik Bart napisał:
> 
> > So it's possible to have a C file
> >> consisting of only:
> >>
> >>   (((((a)))));
> >>
> >> and that's fine. No matter that people will be scratching their heads
> >> wondering what it means.
> 
> > you always come to this point and you always get it
> > wrong
> >
> > you will only scratch a head if you dont know how it works after learning how it works it will be same part of the language as thousands other parts
> 
> C has many quirks that even experts can be confused over when faced with 
> an unusual construct. For example:
> 
>    f(x);
> 
> This calls a function f with argument x, yes? Not necessarily, not if f 
> is a typedef name, then it will declare x as a variable of type f.
> 
> (It think it was such an example that David Brown said he hadn't 
> realised you could do.)
> 
> So, yes, (((((a))))); can be confusing. Because for a start, it can mean 
> different things depending on context. And it doesn't exactly look like 
> a typical declaration.
> 
this is another point but also was talked

its hard to answer becouse i dont really see the 
point you make.. 

what can i say, if you read code you need read-back milions things (even much worse  than that really).. (*)

if you use various 'polysemic' syntax it grants you need 
to make a bit of more look ups but code is shorter 

///

(*) you know like if you see a function and wander what
is its role in general mechanic of given app

if you would want the c codes more readable imo it would 
be better adress such problems - and if you just prefer 
spare those quite easy (and rare) lookups (ny the cost of longer code) it may be more a metter of preference

(i prefer quicker code - though each syntax case needs
separate consideration; i dont share the opinion that 
((((a)))); is bad (in the context of old c syntax) i could say more if this was proved that it do not make syntax conflicts it is good, i could use it, and im rather sorry it is not widely supported :C )

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

#102930

W dniu środa, 1 lutego 2017 21:26:32 UTC+1 użytkownik fir napisał:
> W dniu środa, 1 lutego 2017 19:44:17 UTC+1 użytkownik Bart napisał:
> > On 01/02/2017 17:55, fir wrote:
> > > W dniu środa, 1 lutego 2017 18:24:18 UTC+1 użytkownik Bart napisał:
> > 
> > > So it's possible to have a C file
> > >> consisting of only:
> > >>
> > >>   (((((a)))));
> > >>
> > >> and that's fine. No matter that people will be scratching their heads
> > >> wondering what it means.
> > 
> > > you always come to this point and you always get it
> > > wrong
> > >
> > > you will only scratch a head if you dont know how it works after learning how it works it will be same part of the language as thousands other parts
> > 
> > C has many quirks that even experts can be confused over when faced with 
> > an unusual construct. For example:
> > 
> >    f(x);
> > 
> > This calls a function f with argument x, yes? Not necessarily, not if f 
> > is a typedef name, then it will declare x as a variable of type f.
> > 
> > (It think it was such an example that David Brown said he hadn't 
> > realised you could do.)
> > 
> > So, yes, (((((a))))); can be confusing. Because for a start, it can mean 
> > different things depending on context. And it doesn't exactly look like 
> > a typical declaration.
> > 
> this is another point but also was talked
> 
> its hard to answer becouse i dont really see the 
> point you make.. 
> 
> what can i say, if you read code you need read-back milions things (even much worse  than that really).. (*)
> 
> if you use various 'polysemic' syntax it grants you need 
> to make a bit of more look ups but code is shorter 
> 
> ///
> 
> (*) you know like if you see a function and wander what
> is its role in general mechanic of given app
> 
> if you would want the c codes more readable imo it would 
> be better adress such problems - and if you just prefer 
> spare those quite easy (and rare) lookups (ny the cost of longer code) it may be more a metter of preference
> 
> (i prefer quicker code - though each syntax case needs
> separate consideration; i dont share the opinion that 
> ((((a)))); is bad (in the context of old c syntax) i could say more if this was proved that it do not make syntax conflicts it is good, i could use it, and im rather sorry it is not widely supported :C )

i could even think how to cut it down even more..
i mean here you could down int keyword but you left
the declaration, i could think (damn i could eat tuna)
for example for cutting both this int declatration and float keywords.. this seem a good idea

check

void main()
{
  a = foo();  //a is integer //no declaration needed
  boo(a);
}

at some way it seem s to me that maybe globals should be more declared than locals as they could be confusing
(globals should be distinguished on module external,
module internal, and maybe even file scope - There are also options to not distinguish it (only optionally) or distinguish it by some prefixes like :a for module ::a 
for external - this is to be rethink) 

floats could be removed by

void main()
{
  a = foo(); //if foo returns floats
  
  b = 1.; //b is float 
 
}

i mean types can be deduced from initialisers
(even more complex ones 

void main()
{
  c = "alamakota"; //c is char* (or char[])
}

seem good idea, this is just like yet more hungarian notation out, codes yet shorter

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

#102931

W dniu środa, 1 lutego 2017 22:03:45 UTC+1 użytkownik fir napisał:
> W dniu środa, 1 lutego 2017 21:26:32 UTC+1 użytkownik fir napisał:
> > W dniu środa, 1 lutego 2017 19:44:17 UTC+1 użytkownik Bart napisał:
> > > On 01/02/2017 17:55, fir wrote:
> > > > W dniu środa, 1 lutego 2017 18:24:18 UTC+1 użytkownik Bart napisał:
> > > 
> > > > So it's possible to have a C file
> > > >> consisting of only:
> > > >>
> > > >>   (((((a)))));
> > > >>
> > > >> and that's fine. No matter that people will be scratching their heads
> > > >> wondering what it means.
> > > 
> > > > you always come to this point and you always get it
> > > > wrong
> > > >
> > > > you will only scratch a head if you dont know how it works after learning how it works it will be same part of the language as thousands other parts
> > > 
> > > C has many quirks that even experts can be confused over when faced with 
> > > an unusual construct. For example:
> > > 
> > >    f(x);
> > > 
> > > This calls a function f with argument x, yes? Not necessarily, not if f 
> > > is a typedef name, then it will declare x as a variable of type f.
> > > 
> > > (It think it was such an example that David Brown said he hadn't 
> > > realised you could do.)
> > > 
> > > So, yes, (((((a))))); can be confusing. Because for a start, it can mean 
> > > different things depending on context. And it doesn't exactly look like 
> > > a typical declaration.
> > > 
> > this is another point but also was talked
> > 
> > its hard to answer becouse i dont really see the 
> > point you make.. 
> > 
> > what can i say, if you read code you need read-back milions things (even much worse  than that really).. (*)
> > 
> > if you use various 'polysemic' syntax it grants you need 
> > to make a bit of more look ups but code is shorter 
> > 
> > ///
> > 
> > (*) you know like if you see a function and wander what
> > is its role in general mechanic of given app
> > 
> > if you would want the c codes more readable imo it would 
> > be better adress such problems - and if you just prefer 
> > spare those quite easy (and rare) lookups (ny the cost of longer code) it may be more a metter of preference
> > 
> > (i prefer quicker code - though each syntax case needs
> > separate consideration; i dont share the opinion that 
> > ((((a)))); is bad (in the context of old c syntax) i could say more if this was proved that it do not make syntax conflicts it is good, i could use it, and im rather sorry it is not widely supported :C )
> 
> i could even think how to cut it down even more..
> i mean here you could down int keyword but you left
> the declaration, i could think (damn i could eat tuna)
> for example for cutting both this int declatration and float keywords.. this seem a good idea
> 
> check
> 
> void main()
> {
>   a = foo();  //a is integer //no declaration needed
>   boo(a);
> }
> 
> at some way it seem s to me that maybe globals should be more declared than locals as they could be confusing
> (globals should be distinguished on module external,
> module internal, and maybe even file scope - There are also options to not distinguish it (only optionally) or distinguish it by some prefixes like :a for module ::a 
> for external - this is to be rethink) 
> 
> floats could be removed by
> 
> void main()
> {
>   a = foo(); //if foo returns floats
>   
>   b = 1.; //b is float 
>  
> }
> 
> i mean types can be deduced from initialisers
> (even more complex ones 
> 
> void main()
> {
>   c = "alamakota"; //c is char* (or char[])
> }
> 
> seem good idea, this is just like yet more hungarian notation out, codes yet shorter

for bartc it would be probably good example of confusion,
for me it would be probably handy and nice 

(as some type checks skipped it would be prone on mistakes but i dont worry to much, old way to put the explicite types thus checks would be also avaliable)

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

#103095

W dniu środa, 1 lutego 2017 22:03:45 UTC+1 użytkownik fir napisał:
> W dniu środa, 1 lutego 2017 21:26:32 UTC+1 użytkownik fir napisał:
> > W dniu środa, 1 lutego 2017 19:44:17 UTC+1 użytkownik Bart napisał:
> > > On 01/02/2017 17:55, fir wrote:
> > > > W dniu środa, 1 lutego 2017 18:24:18 UTC+1 użytkownik Bart napisał:
> > > 
> > > > So it's possible to have a C file
> > > >> consisting of only:
> > > >>
> > > >>   (((((a)))));
> > > >>
> > > >> and that's fine. No matter that people will be scratching their heads
> > > >> wondering what it means.
> > > 
> > > > you always come to this point and you always get it
> > > > wrong
> > > >
> > > > you will only scratch a head if you dont know how it works after learning how it works it will be same part of the language as thousands other parts
> > > 
> > > C has many quirks that even experts can be confused over when faced with 
> > > an unusual construct. For example:
> > > 
> > >    f(x);
> > > 
> > > This calls a function f with argument x, yes? Not necessarily, not if f 
> > > is a typedef name, then it will declare x as a variable of type f.
> > > 
> > > (It think it was such an example that David Brown said he hadn't 
> > > realised you could do.)
> > > 
> > > So, yes, (((((a))))); can be confusing. Because for a start, it can mean 
> > > different things depending on context. And it doesn't exactly look like 
> > > a typical declaration.
> > > 
> > this is another point but also was talked
> > 
> > its hard to answer becouse i dont really see the 
> > point you make.. 
> > 
> > what can i say, if you read code you need read-back milions things (even much worse  than that really).. (*)
> > 
> > if you use various 'polysemic' syntax it grants you need 
> > to make a bit of more look ups but code is shorter 
> > 
> > ///
> > 
> > (*) you know like if you see a function and wander what
> > is its role in general mechanic of given app
> > 
> > if you would want the c codes more readable imo it would 
> > be better adress such problems - and if you just prefer 
> > spare those quite easy (and rare) lookups (ny the cost of longer code) it may be more a metter of preference
> > 
> > (i prefer quicker code - though each syntax case needs
> > separate consideration; i dont share the opinion that 
> > ((((a)))); is bad (in the context of old c syntax) i could say more if this was proved that it do not make syntax conflicts it is good, i could use it, and im rather sorry it is not widely supported :C )
> 
> i could even think how to cut it down even more..
> i mean here you could down int keyword but you left
> the declaration, i could think (damn i could eat tuna)
> for example for cutting both this int declatration and float keywords.. this seem a good idea
> 
> check
> 
> void main()
> {
>   a = foo();  //a is integer //no declaration needed
>   boo(a);
> }
> 

this is overal very good (interesting) idea im happy with that,
(though im sleepy now so cant say much longer)

good is it makes codes quite noticably shorter 
(as local declarations are so common) and also like clearer,  it also removes like some unsymetry, code is 
code [code is code flow] and those locals instantiations
looked veird, here locals are showed like just temporary
helping storage and names which they are.. it burdens a bit a programer learning phase becouse he would be expected to know how it is resolved in the background but it is ok to me (not much burden), code would seen be more logically clear

what else can i say, it would be probably needed to write some pieces in this style to check how it feels like and if there arent some problems with that.. overal feel of c 
may change, hope not on something worse, but as old way
of explicite type writing is also avaliable i hope it 
would be good addon anyway




> at some way it seem s to me that maybe globals should be more declared than locals as they could be confusing
> (globals should be distinguished on module external,
> module internal, and maybe even file scope - There are also options to not distinguish it (only optionally) or distinguish it by some prefixes like :a for module ::a 
> for external - this is to be rethink) 
> 
> floats could be removed by
> 
> void main()
> {
>   a = foo(); //if foo returns floats
>   
>   b = 1.; //b is float 
>  
> }
> 
> i mean types can be deduced from initialisers
> (even more complex ones 
> 
> void main()
> {
>   c = "alamakota"; //c is char* (or char[])
> }
> 
> seem good idea, this is just like yet more hungarian notation out, codes yet shorter

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

#102917

BartC <bc@freeuk.com> writes:
[...]
> It doesn't help that so many compilers are happy to ignore what the spec 
> says, and just give a warning.
[...]

The standard only says that a violation of any syntax rule or constraint
results in a diagnostic.  That diagnostic can be a non-fatal warning.
Many compilers provide options to provide more stringent checking, such
as gcc's "-std=c11 -pedantic-errors".

(There's also no requirement that the diagnostic must be clear; that's a
QoI issue.)

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

#102921

On Wednesday, February 1, 2017 at 12:24:18 PM UTC-5, Bart wrote:
...
> It doesn't help that so many compilers are happy to ignore what the spec 
> says, and just give a warning.

The ONLY requirement the standard imposes when on an implementation when
translating a translation unit which contains one or more syntax errors or a
constraint violations, is that at least one diagnostic message must be issued.
It never prohibits the generation of a diagnostic message - the "Hello world!"
program could cause the generation of the message "Too short.". The only case
where rejection of a program is mandatory is when it contains a #error
directive that survives conditional compilation. How does giving a warning
message and continuing to process a program that does not contain such a #error
directive qualify as "ignoring the spec"?

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

#102916

supercat@casperkitty.com writes:
> On Wednesday, February 1, 2017 at 9:30:23 AM UTC-6, David Brown wrote:
>> How can you be writing a parser, and complaining about what C does and
>> does not allow, and how other compilers match the standards, when you
>> haven't even bothered to /read/ the standards?  How are you making
>> making your code at the moment - by skim-reading a couple of Wikipedia
>> articles then some trial-and-error runs with a few existing compilers?
>
> The language Dennis Ritchie designed was not processed using a formal grammar,
> nor is a formal grammar the most efficient way to parse that language.  In
> addition, I don't think a formal grammar works well as a human-readable way of
> describing it either.

The earliest C reference manuals, from 1974 and 1975, describe the
syntax using a formal grammar, so the *language* certainly was defined
that way.  If you're making a claim about how Dennis Ritchie's early C
compiler happened to operate, then (a) please be clear about that, and
(b) I fail see the relevance.

> Since some compiler-generation tools are easiest to use when they have a
> formal grammar as a starting point, I think it is reasonable for the Standard
> to provide a grammar and say that implementations are required to handle the
> cases described by the Standard and are not required to handle cases outside
> the grammar.  Given the charter of the Committee, however, I really doubt that
> the Committee intended that compilers should be required to reject forms that
> they had accepted previously and which may be in use by production code.

Compilers are not required to reject anything other than code that uses
a #error directive.

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

#102913

On 01/02/2017 15:30, David Brown wrote:
> On 01/02/17 14:22, BartC wrote:
>> On 01/02/2017 12:55, David Brown wrote:

>>> Section 6.7.2 of N1570 (C11 draft) seems reasonably clear to me.  "int
>>> int" is not allowed - you can have /one/ list of type specifier from the
>>> list given under "constraints".
>>
>> Oh, OK, I didn't get that far!
>
> How can you be writing a parser, and complaining about what C does and
> does not allow, and how other compilers match the standards, when you
> haven't even bothered to /read/ the standards?

I started reading 6.7 about decl-specs without realising that type-specs 
(part of a decl-spec) had their own section. Anyway I already knew most 
of the restrictions but they were not stipulated by means of the grammar.

> How are you making
> making your code at the moment - by skim-reading a couple of Wikipedia
> articles then some trial-and-error runs with a few existing compilers?

So far I do trial runs with code fragments, then do proper testing using 
hundreds of thousands of lines of real code. One test file has nearly 
900,000 lines in a single module when 650 headers are included.

But my emphasis is on streamlining for speed.

>> But it has to resort to listing all the
>> combinations (but not the permutations) that are allowed. And which may
>> be intermixed with other attributes. This is not very elegant (nor
>> efficient) to parse and to check.
>
> The language has historical baggage.  This is no surprise - its 40 years
> old and has gone through many revisions.  Originally there was only
> "int" and "double", and other types had to be added in a way that
> allowed existing code to keep working.  The result is a bit less
> consistent than if it had been designed with advice from
> time-travellers.

I wasn't involved with computing when C was designed, but I was a decade 
later. And the languages I started to create then /had/ to be quick and 
easy to compile, so they needed to be simple.

I know for a fact (even if other details have faded), then I did not 
cripple the designs by mandating an intermediate macro-language that 
pre-processed source code by means of a pure interpreter implemented 
within the compiler! It sounds crazy when put that way, but that's 
exactly how it works in C.

-- 
bartc

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

#102924

BartC <bc@freeuk.com> writes:
<snip>
> I know for a fact (even if other details have faded), then I did not
> cripple the designs by mandating an intermediate macro-language that
> pre-processed source code by means of a pure interpreter implemented
> within the compiler!

It was (and still is in some cases) a separate program.  It is "within
the compiler" only in the sense that pre-processing is a required part
of translating a source program.

> It sounds crazy when put that way, but that's exactly how it works in
> C.

It sounds like the only sane way to do it.

Do you mean you would simply never have a macro processor at the front
of a compiler?  That's a reasonable stance, but you might find you want
some mechanism to do the things one does in C using cpp.

-- 
Ben.

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

#102932

On 01/02/2017 19:58, Ben Bacarisse wrote:
> BartC <bc@freeuk.com> writes:
> <snip>
>> I know for a fact (even if other details have faded), then I did not
>> cripple the designs by mandating an intermediate macro-language that
>> pre-processed source code by means of a pure interpreter implemented
>> within the compiler!
>
> It was (and still is in some cases) a separate program.  It is "within
> the compiler" only in the sense that pre-processing is a required part
> of translating a source program.
>
>> It sounds crazy when put that way, but that's exactly how it works in
>> C.
>
> It sounds like the only sane way to do it.
>
> Do you mean you would simply never have a macro processor at the front
> of a compiler?

I've resisted the temptation so far. And haven't really missed it. And a 
number of other languages seem to do without.

> That's a reasonable stance, but you might find you want
> some mechanism to do the things one does in C using cpp.

I believe in having the requisite language features in place instead.

That can't handle all the esoteric things that macros can do, but when 
you see code dominated by macro calls, and then see the indecipherable 
macro definitions involved, then that might be a good thing.

(My cpp can handle a version of gcc's cc1 component presented as one 
file (plus system headers). That appeared to work. Until I turned on the 
__STDC__ macro. Then it started to give problems. (Presumably switching 
on some conditional code that was previously ignored.) However, there 
are 890,000 lines of code in 146 source files, with some 330,000 macro 
invocations. I don't fancy debugging it; do you?!

The macro language is a horrible thing that I would rather not have 
anywhere near a compiler. And the test code here is a perfect example 
where over-reliance on macros and conditional source makes the code 
impossible to follow.)

-- 
bartc

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

#102908

BartC <bc@freeuk.com> writes:
[...]
> (I notice you shouldn't use _Complex by itself, but have to combine it 
> with float or double, which I hadn't realised. Yet usually you can. More 
> laxity on the part of compilers.)

That is unfortunate.

With gcc 6.2, this:

    _Complex x;

compiles with no warning by default.  With "-pedantic", it warns:

    warning: ISO C does not support plain ‘complex’ meaning ‘double complex’ [-Wpedantic]

C90 did not have complex at all.  C99, which introduced the _Complex
keyword, did not permit it by itself; it's a type specifier that has to
be associated with "float", "double", or "long double".  There is no
standard version of the language in which that declaration is valid.

My guess is that it was proposed as equivalent to `double _Complex` some
time during the development of the C99 standard, and gcc implemented
support for it.

IMHO gcc *should* at least warn about it by default.  But then you
probably shouldn't invoke gcc with default arguments if you care about
catching errors in your code.

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

#102927

On 2/1/2017 3:39 AM, BartC wrote:
>
> However, the grammar also seems to allow these:
>
> const const const a;          // no initial value
> int int int b;
>
> gcc allows the first (but 'implicit int'), and disallows the second
> (more than one type specifier).
>

But the further wording in the document prohibits this.

This is actually how the whole infrastructure works: the grammar is 
checked first. The additional wording present in the document can impose 
further restrictions on what is allowed by the grammar, but it cannot 
relax these restrictions.

The text can prohibit what was allowed by the grammar, but the text 
cannot allow what was prohibited by the grammar.

-- 
Best regards,
Andrey Tarasevich

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

#105501

On 1/30/2017 5:00 AM, BartC wrote:
>
>   #include <stdio.h>
>
>   a=10, b=20, c=30;
>
>   int main(void){}
>
> This compiles fine. But not if the declarations are inside a function.

The CRM document (https://www.bell-labs.com/usr/dmr/www/cman.pdf) states 
the following:

"In a declaration inside a function, if a storage class but no type is 
given, the identifier is assumed to be 'int'; if a type but no storage 
class is indicated, the identifier is assumed to be 'auto'. An exception 
to the latter rule is made for functions, since auto functions are 
meaningless (C being incapable of compiling code into the stack). If the 
type of an identifier is ‘‘function returning ...’’, it is implicitly 
declared to be 'extern'.
...
Undefined identifiers not followed by '(' are assumed to be labels which 
will be defined later in the function. (Since a label is not an lvalue, 
this accounts for the ‘‘Lvalue required’’ error message sometimes 
noticed when an undeclared identifier is used.) Naturally, appearance of 
an identifier as a label declares it as such."

It implies says that even back in CRM times the application of "implict 
int" rule in local scope required at least storage class specifier to be 
present. Otherwise, a completely unknown identifier was regarded as a 
_label_, not as an "implicitly int" variable.

-- 
Best regards,
Andrey Tarasevich

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

#105504

Andrey Tarasevich <andreytarasevich@hotmail.com> writes:
> On 1/30/2017 5:00 AM, BartC wrote:
>>
>>   #include <stdio.h>
>>
>>   a=10, b=20, c=30;
>>
>>   int main(void){}
>>
>> This compiles fine. But not if the declarations are inside a function.
>
> The CRM document (https://www.bell-labs.com/usr/dmr/www/cman.pdf) states 
> the following:
[snip]

I presume "CRM" stands for "C Reference Manual".  I've never heard it
referred to that way, and these days CRM more commonly stands for
"Customer Relationship Management".

Also, cman.pdf is just one of a number of versions of the "C Reference
Manual".

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

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web