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

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

*&aptr , &*aptr question

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

Contents

  *&aptr , &*aptr question G G <gdotone@gmail.com> - 2016-06-14 13:43 -0700
    Re: *&aptr , &*aptr question Richard Heathfield <rjh@cpax.org.uk> - 2016-06-14 22:01 +0100
      Re: *&aptr , &*aptr question Ike Naar <ike@iceland.freeshell.org> - 2016-06-14 21:20 +0000
        Re: *&aptr , &*aptr question G G <gdotone@gmail.com> - 2016-06-14 14:38 -0700
      Re: *&aptr , &*aptr question Richard Heathfield <rjh@cpax.org.uk> - 2016-06-14 22:42 +0100
      Re: *&aptr , &*aptr question Ken Brody <kenbrody@spamcop.net> - 2016-06-15 14:22 -0400
        Re: *&aptr , &*aptr question Richard Heathfield <rjh@cpax.org.uk> - 2016-06-15 19:24 +0100
    Re: *&aptr , &*aptr question "James R. Kuyper" <jameskuyper@verizon.net> - 2016-06-14 17:17 -0400
    Re: *&aptr , &*aptr question Keith Thompson <kst-u@mib.org> - 2016-06-14 14:37 -0700
    Re: *&aptr , &*aptr question "James R. Kuyper" <jameskuyper@verizon.net> - 2016-06-14 17:40 -0400
      Re: *&aptr , &*aptr question "James R. Kuyper" <jameskuyper@verizon.net> - 2016-06-14 17:49 -0400
      Re: *&aptr , &*aptr question BartC <bc@freeuk.com> - 2016-06-14 22:57 +0100
        Re: *&aptr , &*aptr question jameskuyper@verizon.net - 2016-06-14 15:22 -0700
          Re: *&aptr , &*aptr question "James R. Kuyper" <jameskuyper@verizon.net> - 2016-06-14 18:40 -0400
          Re: *&aptr , &*aptr question BartC <bc@freeuk.com> - 2016-06-14 23:44 +0100
          Re: *&aptr , &*aptr question BartC <bc@freeuk.com> - 2016-06-14 23:54 +0100
            Re: *&aptr , &*aptr question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-15 00:14 +0100
            Re: *&aptr , &*aptr question Keith Thompson <kst-u@mib.org> - 2016-06-14 16:51 -0700
              Re: *&aptr , &*aptr question BartC <bc@freeuk.com> - 2016-06-15 01:15 +0100
                Re: *&aptr , &*aptr question Keith Thompson <kst-u@mib.org> - 2016-06-14 17:44 -0700
                Re: *&aptr , &*aptr question David Brown <david.brown@hesbynett.no> - 2016-06-15 09:12 +0200
                  Re: *&aptr , &*aptr question Richard Heathfield <rjh@cpax.org.uk> - 2016-06-15 08:28 +0100
                    Re: *&aptr , &*aptr question David Brown <david.brown@hesbynett.no> - 2016-06-15 10:26 +0200
                      Re: *&aptr , &*aptr question Richard Heathfield <rjh@cpax.org.uk> - 2016-06-15 09:48 +0100
                  Re: *&aptr , &*aptr question BartC <bc@freeuk.com> - 2016-06-15 11:05 +0100
                    Re: *&aptr , &*aptr question David Brown <david.brown@hesbynett.no> - 2016-06-15 12:22 +0200
                      Re: *&aptr , &*aptr question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-15 03:55 -0700
                        Re: *&aptr , &*aptr question David Brown <david.brown@hesbynett.no> - 2016-06-15 13:15 +0200
                          Re: *&aptr , &*aptr question BartC <bc@freeuk.com> - 2016-06-15 13:08 +0100
                            Re: *&aptr , &*aptr question David Brown <david.brown@hesbynett.no> - 2016-06-15 14:15 +0200
                              Re: *&aptr , &*aptr question BartC <bc@freeuk.com> - 2016-06-15 14:02 +0100
                              Re: *&aptr , &*aptr question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-15 13:38 -0700
                                Re: *&aptr , &*aptr question David Brown <david.brown@hesbynett.no> - 2016-06-16 00:01 +0200
                                  Re: *&aptr , &*aptr question Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-06-16 00:58 -0700
                            Re: *&aptr , &*aptr question supercat@casperkitty.com - 2016-06-15 09:06 -0700
                              Re: *&aptr , &*aptr question BartC <bc@freeuk.com> - 2016-06-15 17:54 +0100
                            Re: *&aptr , &*aptr question raltbos@xs4all.nl (Richard Bos) - 2016-06-15 20:10 +0000
      Re: *&aptr , &*aptr question supercat@casperkitty.com - 2016-06-14 16:28 -0700
        Re: *&aptr , &*aptr question Keith Thompson <kst-u@mib.org> - 2016-06-14 16:54 -0700
          Re: *&aptr , &*aptr question supercat@casperkitty.com - 2016-06-14 19:13 -0700
            Re: *&aptr , &*aptr question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-15 13:19 +0100
              Re: *&aptr , &*aptr question Tim Rentsch <txr@alumni.caltech.edu> - 2016-06-16 10:39 -0700
                Re: *&aptr , &*aptr question supercat@casperkitty.com - 2016-06-16 12:06 -0700
                  Re: *&aptr , &*aptr question Tim Rentsch <txr@alumni.caltech.edu> - 2016-06-21 12:21 -0700
                Re: *&aptr , &*aptr question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-16 21:06 +0100
                  Re: *&aptr , &*aptr question supercat@casperkitty.com - 2016-06-16 14:35 -0700
                    Re: *&aptr , &*aptr question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-17 01:22 +0100
                  Re: *&aptr , &*aptr question Tim Rentsch <txr@alumni.caltech.edu> - 2016-06-16 22:21 -0700
                    Re: *&aptr , &*aptr question Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-06-18 00:55 +0100
                      Re: *&aptr , &*aptr question supercat@casperkitty.com - 2016-06-17 17:26 -0700
                      Re: *&aptr , &*aptr question Tim Rentsch <txr@alumni.caltech.edu> - 2016-06-21 12:19 -0700
                        Re: *&aptr , &*aptr question supercat@casperkitty.com - 2016-06-21 13:09 -0700
    Re: *&aptr , &*aptr question Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-06-14 22:30 -0400
      Re: *&aptr , &*aptr question Tim Rentsch <txr@alumni.caltech.edu> - 2016-06-15 14:20 -0700

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

#89135

On 15/06/16 02:15, BartC wrote:
> On 15/06/2016 00:51, Keith Thompson wrote:

>> What do you mean by "fine"?  Did you not get warnings?
> 
> Yes, I did! But I keep forgetting that the way I use gcc hides all the
> warnings. So the lines I've marked //w above had warnings (from gcc,
> clang, tcc). Other compilers gave actual errors.
> 

That is not "using gcc" - it is /abusing/ gcc.

For most of my development, I have -Wall -Wextra, plus a number of other
warning flags, and -Werror to make the warnings into errors.  The
warnings are there for a reason, and they help developers avoid or spot
mistakes at the earliest opportunity.

(People, projects, code styles, etc., are often different, and
particular choices of warnings flags are going to vary a lot.  But the
principle of getting the compiler to check as much as possible is, I
believe, suitable for most C programming.)

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

#89137

On 15/06/16 08:12, David Brown wrote:

<snip>

> For most of my development, I have -Wall -Wextra, plus a number of other
> warning flags, and -Werror to make the warnings into errors.

For testing code I post in Usenet articles (or for other situations 
where I'm starting the compiler directly from the command line, rather 
than by invoking make) I tend to use -W -Wall -ansi -pedantic, which is 
easy to remember, quick to type, and seems to be enough to catch most 
things. My normal collection of switches for makefile usage is a little 
lengthier, but there's a point of diminishing returns where some 
warnings complain far more about good code than they do about bad code. 
(There are a couple of warnings that berate me for initialising structs 
like this = { 0 } which is perfectly idiomatic C, and I'm not sure that 
those warnings have /ever/ warned me about an actual problem with the code.)

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#89143

On 15/06/16 09:28, Richard Heathfield wrote:
> On 15/06/16 08:12, David Brown wrote:
> 
> <snip>
> 
>> For most of my development, I have -Wall -Wextra, plus a number of other
>> warning flags, and -Werror to make the warnings into errors.
> 
> For testing code I post in Usenet articles (or for other situations
> where I'm starting the compiler directly from the command line, rather
> than by invoking make) I tend to use -W -Wall -ansi -pedantic, which is
> easy to remember, quick to type, and seems to be enough to catch most
> things. My normal collection of switches for makefile usage is a little
> lengthier, but there's a point of diminishing returns where some
> warnings complain far more about good code than they do about bad code.
> (There are a couple of warnings that berate me for initialising structs
> like this = { 0 } which is perfectly idiomatic C, and I'm not sure that
> those warnings have /ever/ warned me about an actual problem with the
> code.)
> 

These days I use <http://gcc.godbolt.org/#> for testing code for Usenet
posts.  I usually use -Wall -Wextra -std=gnu++14, tweaked a bit for C
code rather than C++ (though the great majority of C I write is also
valid C++).  But for my purposes, modern features are normally more
important than compatibility with last century's standards, and usually
gcc extensions are fine.  And some tweaks to the warning flag choices
are needed to suit particular styles or particular code.  It's great
that we have such choice!

(Occasionally I need to work with updating code that not only uses last
century's standards, but uses last century's tools - last year I had to
make some modifications to a program I wrote 20 years ago, using the
same compiler that I used for the original.  It was a bit shocking to
read the code I wrote in those days!)

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

#89145

On 15/06/16 09:26, David Brown wrote:
<snip>
>
> (Occasionally I need to work with updating code that not only uses last
> century's standards, but uses last century's tools - last year I had to
> make some modifications to a program I wrote 20 years ago, using the
> same compiler that I used for the original.  It was a bit shocking to
> read the code I wrote in those days!)

It doesn't always take 20 years.

In 1990, I got a job (ostensibly as a C programmer) at a site that 
mostly used a 4GL called 'KnowledgeMan'. I'd never heard of it before, 
but it was a relatively easy language, so I soon caught on. After I'd 
been there about a year, I was asked to investigate a bug which had been 
irritating the users for some considerable time, and they'd finally 
complained about it loudly enough to be heard.

Reading the code for the program in question, I was struck by two things:

1) I couldn't spot any flaws in the logic of the code; but
2) whoever had written this code had clearly had *no idea whatsoever* of 
how to write KnowledgeMan code. It was just ghastly. I could see what 
the author was thinking, more or less, but there was no sense of idiom, 
no - uh - rhyme(?) to the code, if I can use that word. No elegance. It 
was a hack and slash job, through and through.

But I couldn't see the actual bug. So, to give myself a little thinking 
time, I set about tidying the code up - rewriting the loops in a more 
idiomatic way, abstracting out repeated code, that sort of thing. 
Prettifying it, if you like. Then I re-ran the code to check that I 
hadn't broken anything in the process, and... the bug had gone! Further 
investigation showed that it really had gone and I really had fixed the 
problem (without ever really knowing the specific cause).

Now was the time to check the logs, to find out which bonehead had 
written the code in the first place, so that I could re-educate him in 
how to write decent K/Man code.

(You're ahead of me, I know*.)

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
*Hint: the original code had been written about twelve months earlier.

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

#89148

On 15/06/2016 08:12, David Brown wrote:
> On 15/06/16 02:15, BartC wrote:
>> On 15/06/2016 00:51, Keith Thompson wrote:
>
>>> What do you mean by "fine"?  Did you not get warnings?
>>
>> Yes, I did! But I keep forgetting that the way I use gcc hides all the
>> warnings. So the lines I've marked //w above had warnings (from gcc,
>> clang, tcc). Other compilers gave actual errors.
>>
>
> That is not "using gcc" - it is /abusing/ gcc.

Usually when I run a C compiler, it is compiling auto-generated code 
that is expected to be structurally sound, and also type-checked. So it 
makes sense to silence warnings that are just going to be noise and that 
would obscure real errors.

But I think I will have to invoke it differently when compiling normal 
hand-written C.

-- 
Bartc

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

#89150

On 15/06/16 12:05, BartC wrote:
> On 15/06/2016 08:12, David Brown wrote:
>> On 15/06/16 02:15, BartC wrote:
>>> On 15/06/2016 00:51, Keith Thompson wrote:
>>
>>>> What do you mean by "fine"?  Did you not get warnings?
>>>
>>> Yes, I did! But I keep forgetting that the way I use gcc hides all the
>>> warnings. So the lines I've marked //w above had warnings (from gcc,
>>> clang, tcc). Other compilers gave actual errors.
>>>
>>
>> That is not "using gcc" - it is /abusing/ gcc.
> 
> Usually when I run a C compiler, it is compiling auto-generated code
> that is expected to be structurally sound, and also type-checked. So it
> makes sense to silence warnings that are just going to be noise and that
> would obscure real errors.
> 

No, it makes sense to generate your code in a way that won't produce
warnings - then the warnings that remain are real errors.

> But I think I will have to invoke it differently when compiling normal
> hand-written C.
> 

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

#89152

On Wednesday, June 15, 2016 at 11:22:14 AM UTC+1, David Brown wrote:
>
> No, it makes sense to generate your code in a way that won't produce
> warnings - then the warnings that remain are real errors.
> 
Assuming you've debugged the code generator, the C produced is 
correct. The warnings are just noise, and whilst it's generally a good
idea to generate code that isn't likely to be warning-rich, sometimes
it's very difficult. Some compilers will warn about unused parameters,
other will warn about code with no effects, some will warn if a function
doesn't end with a return value, other about unreachable code 
(assuming the closing brace can't be reached) and so on.

Anyway, you shouldn't be fixing the warnings by editing the generated
code, but by changing the generator, and that might not be a task 
for the person who uses the generator.

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

#89155

On 15/06/16 12:55, Malcolm McLean wrote:
> On Wednesday, June 15, 2016 at 11:22:14 AM UTC+1, David Brown wrote:
>>
>> No, it makes sense to generate your code in a way that won't produce
>> warnings - then the warnings that remain are real errors.
>>
> Assuming you've debugged the code generator, the C produced is 
> correct. 

And if you haven't debugged the code generator or the C it produces is
not correct, then you /really/ want the warnings!

> The warnings are just noise

No, warnings are not "just noise".  If you think that, then you don't
understand your compiler or how to use it, or you don't understand C.

You might need to use different choices of warning flags to suit the
type of code you generate.  But if you get /any/ warnings, either your
code is bad or your choice of flags is poor.  And in either case, it
should be fixed - not glossed over with "it's just a warning.  If it
were important, it would be an error message".  I have had to fix code
written with that attitude - and the code was invariably crap.

> and whilst it's generally a good
> idea to generate code that isn't likely to be warning-rich, sometimes
> it's very difficult. Some compilers will warn about unused parameters,
> other will warn about code with no effects, some will warn if a function
> doesn't end with a return value, other about unreachable code 
> (assuming the closing brace can't be reached) and so on.

Learn to use your compiler.  Then there will be no problem.  Don't
enable warnings that are inappropriate for the code - tools like gcc
support many warnings that are not applicable everywhere.

Remember, the compiler is there to help you - cooperate with it.

> 
> Anyway, you shouldn't be fixing the warnings by editing the generated
> code, but by changing the generator, and that might not be a task 
> for the person who uses the generator.
> 

Obviously the generator is what needs fixing in most cases.  The
alternative is to fix the flags that are used when calling the compiler.

So when your system generates warnings about "unused parameters", you
have a number of choices.

1. Don't have unnecessary parameters in the functions.  After all, /you/
decide how the code is generated.

2. Add code that suppresses such warnings on many compilers - "(void)
param;" is a common choice.

3. Add compiler-specific code for the compiler-specific warning, perhaps
wrapped in a macro to keep the generated code portable (such as
"__attribute__((unused))" on gcc/clang).

4. Disable that warning in the compiler, with a "-Wno-unused-parameter"
flag.

Rinse and repeat for any other warnings you see as "just noise", so that
you can have your warnings enabled and deal with them appropriately.

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

#89159

On 15/06/2016 12:15, David Brown wrote:
> On 15/06/16 12:55, Malcolm McLean wrote:

>> Assuming you've debugged the code generator, the C produced is
>> correct.
>
> And if you haven't debugged the code generator or the C it produces is
> not correct, then you /really/ want the warnings!

Only if they are truly relevant.

I get warnings such as unused labels (my loops have up to four labels 
generated for each, to allow multiple loop controls, and it would a pain 
having to scan the generated code and eliminate unused ones). But that's 
only with Pelles C.

Or I get a warning about an unintended assignment here:

   if (a=b)

when the assignment is intended. If I use 'if ((a==b))' then it might 
shut up one compiler, but not another.

This is unlikely to be an actual mistake in the original source as ":=" 
is used for assignment and the "="/"==" mixup doesn't happen.

> So when your system generates warnings about "unused parameters", you
> have a number of choices.
>
> 1. Don't have unnecessary parameters in the functions.  After all, /you/
> decide how the code is generated.

> 2. Add code that suppresses such warnings on many compilers - "(void)
> param;" is a common choice.
>
> 3. Add compiler-specific code for the compiler-specific warning, perhaps
> wrapped in a macro to keep the generated code portable (such as
> "__attribute__((unused))" on gcc/clang).
>
> 4. Disable that warning in the compiler, with a "-Wno-unused-parameter"
> flag.

When using a C as intermediate code:

(1) We're not compiling C, but another language with its own identity
     (and with its own idea of what checks can be usefully be made and
     reported)

(2) The type-system and idiosyncrasies of C can be an obstacle to get
     around, if necessary by ignoring well-meaning warnings, provided
     the resultant code will still work.

(3) The C code generator will not know, in general, which C compiler
     is going to be used. Sometimes, in fact, the purpose is to generate
     C code only (for distribution for example).

(4) When used as an integrated system from original source to native
     code, the user of the primary language may not even be aware that
     a C compiler is being invoked.

(5) That user wouldn't understand the message from the C compiler,
     (and the line number reported would be meaningless in the context
     of the original source), nor know what to do about it.

The process should be as transparent as possible. Any actual error 
should be a rare event, and reported like any other that is suspected to 
be a bug in the overall implementation rather than a coding error in the 
user's code.

Anyway, for this purpose, you do have to use C compilers somewhat 
differently.

-- 
Bartc

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

#89161

On 15/06/16 14:08, BartC wrote:
> On 15/06/2016 12:15, David Brown wrote:
>> On 15/06/16 12:55, Malcolm McLean wrote:
> 
>>> Assuming you've debugged the code generator, the C produced is
>>> correct.
>>
>> And if you haven't debugged the code generator or the C it produces is
>> not correct, then you /really/ want the warnings!
> 
> Only if they are truly relevant.
> 
> I get warnings such as unused labels (my loops have up to four labels
> generated for each, to allow multiple loop controls, and it would a pain
> having to scan the generated code and eliminate unused ones). But that's
> only with Pelles C.
> 
> Or I get a warning about an unintended assignment here:
> 
>   if (a=b)

If I ever saw that, in automatically or manually written C, I'd assume
it was wrong.

> 
> when the assignment is intended. If I use 'if ((a==b))' then it might
> shut up one compiler, but not another.

Choose your code generation, with appropriate macros as needed for
portability, and choose your compiler flags to match your code.  If you
/really/ want to be able to write "if (a=b)", then call gcc with a flag
to disable the warning on that type of code.

> 
> This is unlikely to be an actual mistake in the original source as ":="
> is used for assignment and the "="/"==" mixup doesn't happen.
> 
>> So when your system generates warnings about "unused parameters", you
>> have a number of choices.
>>
>> 1. Don't have unnecessary parameters in the functions.  After all, /you/
>> decide how the code is generated.
> 
>> 2. Add code that suppresses such warnings on many compilers - "(void)
>> param;" is a common choice.
>>
>> 3. Add compiler-specific code for the compiler-specific warning, perhaps
>> wrapped in a macro to keep the generated code portable (such as
>> "__attribute__((unused))" on gcc/clang).
>>
>> 4. Disable that warning in the compiler, with a "-Wno-unused-parameter"
>> flag.
> 
> When using a C as intermediate code:
> 
> (1) We're not compiling C, but another language with its own identity
>     (and with its own idea of what checks can be usefully be made and
>     reported)
> 
> (2) The type-system and idiosyncrasies of C can be an obstacle to get
>     around, if necessary by ignoring well-meaning warnings, provided
>     the resultant code will still work.
> 
> (3) The C code generator will not know, in general, which C compiler
>     is going to be used. Sometimes, in fact, the purpose is to generate
>     C code only (for distribution for example).
> 
> (4) When used as an integrated system from original source to native
>     code, the user of the primary language may not even be aware that
>     a C compiler is being invoked.
> 
> (5) That user wouldn't understand the message from the C compiler,
>     (and the line number reported would be meaningless in the context
>     of the original source), nor know what to do about it.
> 
> The process should be as transparent as possible. Any actual error
> should be a rare event, and reported like any other that is suspected to
> be a bug in the overall implementation rather than a coding error in the
> user's code.
> 
> Anyway, for this purpose, you do have to use C compilers somewhat
> differently.
> 

Whatever.  It's your code generator, you do what you want with it.  I
won't be using generated C code that results in piles of warnings with a
typical set of common warning flags (i.e., -Wall).  I think your
attitude to warnings here is completely wrong, but I know I am not going
to change your mind.

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

#89166

On 15/06/2016 13:15, David Brown wrote:
> On 15/06/16 14:08, BartC wrote:

>> when the assignment is intended. If I use 'if ((a==b))' then it might
>> shut up one compiler, but not another.
>
> Choose your code generation, with appropriate macros as needed for
> portability, and choose your compiler flags to match your code.  If you
> /really/ want to be able to write "if (a=b)", then call gcc with a flag
> to disable the warning on that type of code.

Suppose /I/ just supply the translator from X to C.

I can only suggest what compilers are used and which options are 
recommended, but it is largely out of my hands.

At the moment, the list is very short (intentionally so):

(1) gcc or clang should be used if label pointers are involved (as
    other compilers don't support them). Otherwise any C compiler will
    do.

(2) The generated C will have assumed a 32-bit or 64-bit target, so the
     appropriate compiler or option needs to be used. (Maybe an assert
     of some kind can be incorporated to check this.)

I've never got involved in selective masking or enabling of warnings for 
C compilers, I don't want to, and don't really expect anyone else to do so.

Things Should Just Work. Not become dependent on an elaborate 
sub-language of compiler and build options for a program to work properly.

In my IDE, I only need to pay attention to (1), but I mainly use gcc 
anyway as it gives the least trouble.

(A shame it's also the slowest! However I tend to avoid the C target 
completely for most development.)

(Here's some example generated C, of the Fannkuch benchmark, plus the 
output logs of various C compilers:

http://pastebin.com/vdX1iiKg )

-- 
Bartc

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

#89202

On Wednesday, June 15, 2016 at 1:16:07 PM UTC+1, David Brown wrote:
> On 15/06/16 14:08, BartC wrote:
>
> > 
> >   if (a=b)
> 
> If I ever saw that, in automatically or manually written C, I'd assume
> it was wrong.
> 
In manually written C, it's awful.
But automatically generated C will not absent-mindedly output "="
when "==" was intended. Computers don't make that sort of
mistake.
>
> Whatever.  It's your code generator, you do what you want with it.  I
> won't be using generated C code that results in piles of warnings with a
> typical set of common warning flags (i.e., -Wall).  I think your
> attitude to warnings here is completely wrong, but I know I am not going
> to change your mind.
>
Why are warning warnings?
Why not treat warnings as errors?

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

#89219

On 15/06/16 22:38, Malcolm McLean wrote:
> On Wednesday, June 15, 2016 at 1:16:07 PM UTC+1, David Brown wrote:
>> On 15/06/16 14:08, BartC wrote:
>>
>>>
>>>    if (a=b)
>>
>> If I ever saw that, in automatically or manually written C, I'd assume
>> it was wrong.
>>
> In manually written C, it's awful.
> But automatically generated C will not absent-mindedly output "="
> when "==" was intended. Computers don't make that sort of
> mistake.

People programming computers may make that sort of mistake - and the 
code generator was written by a human (though in this case, I would 
expect such a mistake to be found pretty quickly).

However, one of the points of generating C from another language is so 
that it can be used conveniently along with other code written in C. 
(That is not necessarily an expected use-case, but it is not uncommon.) 
  I would expect the generated C to follow at least the levels of code 
quality required to compile warning-free with typical warning levels 
(such as "-Wall") in order to fit conveniently in a standard build 
system alongside manual code.

>>
>> Whatever.  It's your code generator, you do what you want with it.  I
>> won't be using generated C code that results in piles of warnings with a
>> typical set of common warning flags (i.e., -Wall).  I think your
>> attitude to warnings here is completely wrong, but I know I am not going
>> to change your mind.
>>
> Why are warning warnings?
> Why not treat warnings as errors?
>

I /do/ treat them as errors.

But in most cases, warnings (rather than errors) are to indicate that 
something /might/ be wrong with your code - but it is still legal code 
according to the C standards, and thus the compiler will compile it 
rather than rejecting it.  There are certainly situations where it is a 
compiler dependent decision if something should be a warning or an 
error, or no warning at all.

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

#89255

On Wednesday, June 15, 2016 at 11:01:38 PM UTC+1, David Brown wrote:
> On 15/06/16 22:38, Malcolm McLean wrote:
> 
> > In manually written C, it's awful.
> > But automatically generated C will not absent-mindedly output "="
> > when "==" was intended. Computers don't make that sort of
> > mistake.
> 
> People programming computers may make that sort of mistake - and the 
> code generator was written by a human (though in this case, I would 
> expect such a mistake to be found pretty quickly).
> 
> However, one of the points of generating C from another language is so 
> that it can be used conveniently along with other code written in C. 
> (That is not necessarily an expected use-case, but it is not uncommon.) 
>   I would expect the generated C to follow at least the levels of code 
> quality required to compile warning-free with typical warning levels 
> (such as "-Wall") in order to fit conveniently in a standard build 
> system alongside manual code.
> 
I agree there.
If the intention is that the user should modify the generated 
code, then attention needs to be paid to human readability
and constructs if(a = b) are unacceptable.
But if it is simply a magic function which is called and does 
what the human-readable script says, then the C code can be 
anything. For technical reasons to do with the way script compilers
are written, you often need gotos for example.

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

#89167

On Wednesday, June 15, 2016 at 7:09:09 AM UTC-5, Bart wrote:
> When using a C as intermediate code:
> 
> (2) The type-system and idiosyncrasies of C can be an obstacle to get
>      around, if necessary by ignoring well-meaning warnings, provided
>      the resultant code will still work.

What do you do if the "outer" language supports semantics which compilers
used to support, but don't any longer?  For example, if the outer language
allows functions to accept pointers to arbitrary structures with a specific
common initial sequence whose length is not necessarily a multiple of its
alignment, how would one generate code for that in C?  Would it make more
sense to use memcpy all over the place, thereby throwing most useful
aliasing analysis out the window, or require that the target compiler honor
certain aliasing behaviors even if the only way to do that is to use
-fno-strict-aliasing or equivalent?

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

#89172

On 15/06/2016 17:06, supercat@casperkitty.com wrote:
> On Wednesday, June 15, 2016 at 7:09:09 AM UTC-5, Bart wrote:
>> When using a C as intermediate code:
>>
>> (2) The type-system and idiosyncrasies of C can be an obstacle to get
>>      around, if necessary by ignoring well-meaning warnings, provided
>>      the resultant code will still work.
>
> What do you do if the "outer" language supports semantics which compilers
> used to support, but don't any longer?  For example, if the outer language
> allows functions to accept pointers to arbitrary structures with a specific
> common initial sequence whose length is not necessarily a multiple of its
> alignment, how would one generate code for that in C?  Would it make more
> sense to use memcpy all over the place, thereby throwing most useful
> aliasing analysis out the window, or require that the target compiler honor
> certain aliasing behaviors even if the only way to do that is to use
> -fno-strict-aliasing or equivalent?

There are already plenty of problems with semantics that don't sit well 
with C as it is now.

You find a way around, or try to avoid using a troublesome feature, or 
just give up and generate native code directly as there is less red tape 
that way.

But if portability is a must, then there is a possibility of targeting a 
much lower level of C (as I used to do in fact), where everything needs 
to be spelled out, full of memcmps and casts as needed. (Probably most 
of the language can be discarded, and it will still suffice as an 
intermediate language.)

Otherwise I don't really want to get involved in the nitty-gritty of 
obscure C behaviours. I target C to make life easier not harder!

-- 
Bartc

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

#89199

BartC <bc@freeuk.com> wrote:

> When using a C as intermediate code:
> 
> (1) We're not compiling C, but another language with its own identity
>      (and with its own idea of what checks can be usefully be made and
>      reported)
> 
> (2) The type-system and idiosyncrasies of C can be an obstacle to get
>      around, if necessary by ignoring well-meaning warnings, provided
>      the resultant code will still work.
> 
> (3) The C code generator will not know, in general, which C compiler
>      is going to be used. Sometimes, in fact, the purpose is to generate
>      C code only (for distribution for example).

All this sounds to me very much like you're complaining about your own
choice of tools.

> (4) When used as an integrated system from original source to native
>      code, the user of the primary language may not even be aware that
>      a C compiler is being invoked.
> 
> (5) That user wouldn't understand the message from the C compiler,
>      (and the line number reported would be meaningless in the context
>      of the original source), nor know what to do about it.
> 
> The process should be as transparent as possible. Any actual error 
> should be a rare event, and reported like any other that is suspected to 
> be a bug in the overall implementation rather than a coding error in the 
> user's code.
> 
> Anyway, for this purpose, you do have to use C compilers somewhat 
> differently.

Sure. But that in itself implies that problems you encounter in that
process are not valid complaints about C /ipse/.

Richard

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

#89120

On Tuesday, June 14, 2016 at 4:41:01 PM UTC-5, James R. Kuyper wrote:
> I presume that's a typo for *&Ptr?
> If so, &Ptr has a value that is the address of the Ptr object. Applying
> the * operator to that address creates an lvalue referring to that
> object. What that means depends upon how that lvalue is used. If used in
> a expression that reads the value, such as *&Ptr + 5, then it will read
> the value stored in Ptr, which is the address of 'a'. If used in a
> expression that writes the value, such as *&Ptr = &b, it will set Ptr to
> point at b. If used in the expression &*&Ptr, it will give the address
> of Ptr again, so &*&Ptr == &Ptr.

Given:

    struct s1 {int x; };
    struct s1 *p1;

what differences are there, if any, among:

    int temp = p1->x;

    int temp = *&p1->x;

    int *pp = &p1->x;
    int temp = *pp;

I would think the second two should be equivalent, and both should be
legal in cases where the storage identified by &p->x holds an "int" that
has been written via any means, since neither performs an access using a
pointer of type "struct s1", but instead merely use that type to get the
address of an "int", and then perform an access using an int*.

The second form, however, does not work in gcc, even if p1 points to a
global variable of union type containing s1, which was declared before
the code above, and whose other member is active but shares a common
initial sequence with s1.  Is there anything in C99 that would justify
a difference in the latter two forms?

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

#89122

supercat@casperkitty.com writes:
[...]
> Given:
>
>     struct s1 {int x; };
>     struct s1 *p1;
>
> what differences are there, if any, among:
>
>     int temp = p1->x;
>
>     int temp = *&p1->x;
>
>     int *pp = &p1->x;
>     int temp = *pp;
>
> I would think the second two should be equivalent, and both should be
> legal in cases where the storage identified by &p->x holds an "int" that
> has been written via any means, since neither performs an access using a
> pointer of type "struct s1", but instead merely use that type to get the
> address of an "int", and then perform an access using an int*.
>
> The second form, however, does not work in gcc, even if p1 points to a
> global variable of union type containing s1, which was declared before
> the code above, and whose other member is active but shares a common
> initial sequence with s1.  Is there anything in C99 that would justify
> a difference in the latter two forms?

Please explain exactly what you mean by "does not work".

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

#89126

On Tuesday, June 14, 2016 at 6:54:18 PM UTC-5, Keith Thompson wrote:
> Please explain exactly what you mean by "does not work".

Does not cause the compiler to see the effects of an earlier action which
wrote an "int" to the same location.

	#include <stdio.h>
	
	struct s1 { int x; };
	struct s2 { int x; };
	union { struct s1 v1; struct s2 v2; } u;
	
	int test1a(struct s1 *p1, struct s2 *p2)
	{
		if (p1->x != 23) return 0;
		*&p2->x = 5;
		return p1->x;
	}
	
	int test1(void)
	{
		struct s2 v2 = {23};
		u.v2 = v2;
	 	return test1a(&u.v1, &u.v2);
	}
	
	int test2a(struct s1 *p1, struct s2 *p2)
	{
		if (p1->x != 23) return 0;
		int *p = &p2->x;
		*p = 5;
		return p1->x;
	}
	
	int test2(void)
	{
		struct s2 v2 = {23};
		u.v2 = v2;
	 	return test2a(&u.v1, &u.v2);
	}
	
	int main(void) {
		printf("%d\n", test1());
		printf("%d\n", test2());
		return 0;
	}

Code available at http://ideone.com/u8ObBJ

Copying the address of p2->x to an int* variable and then using it as an
int* causes the compiler to recognize that p1->x needs to be reloaded, but
taking the address and then dereferencing it directly has no such effect.
Even adding an explicit cast to (int*) has no effect.

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

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

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

csiph-web