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

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

Why I use gcc

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

Contents

  Why I use gcc BartC <bc@freeuk.com> - 2016-09-26 14:31 +0100
    Re: Why I use gcc David Brown <david.brown@hesbynett.no> - 2016-09-26 15:45 +0200
      Re: Why I use gcc BartC <bc@freeuk.com> - 2016-09-26 15:22 +0100
        Re: Why I use gcc David Brown <david.brown@hesbynett.no> - 2016-09-26 16:31 +0200
        Re: Why I use gcc Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-27 15:05 -0700
          Re: Why I use gcc BartC <bc@freeuk.com> - 2016-09-28 00:42 +0100
            Re: Why I use gcc Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-28 09:50 -0700
              Re: Why I use gcc BartC <bc@freeuk.com> - 2016-09-28 18:39 +0100
                Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-07 12:28 +0100
                  Re: Why I use gcc Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-07 04:36 -0700
                Re: Why I use gcc Thiago Adams <thiago.adams@gmail.com> - 2016-10-07 05:31 -0700
                  Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-07 14:00 +0100
                    Re: Why I use gcc Thiago Adams <thiago.adams@gmail.com> - 2016-10-07 07:48 -0700
                      Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-07 17:36 +0100
                        Re: Why I use gcc Thiago Adams <thiago.adams@gmail.com> - 2016-10-07 10:38 -0700
                          Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-07 19:47 +0100
                            Re: Why I use gcc Keith Thompson <kst-u@mib.org> - 2016-10-07 12:25 -0700
                            Re: Why I use gcc Thiago Adams <thiago.adams@gmail.com> - 2016-10-07 12:26 -0700
                              Re: Why I use gcc Keith Thompson <kst-u@mib.org> - 2016-10-07 13:10 -0700
                                Re: Why I use gcc Thiago Adams <thiago.adams@gmail.com> - 2016-10-07 13:22 -0700
                                  Re: Why I use gcc Keith Thompson <kst-u@mib.org> - 2016-10-07 14:13 -0700
                              Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-08 01:15 +0100
                                Re: Why I use gcc James Harris <james.harris.1@gmail.com> - 2016-10-08 10:42 +0100
                                  Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-08 11:36 +0100
                                    Re: Why I use gcc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-08 14:25 +0100
                                      Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-08 15:05 +0100
                                        Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-08 16:29 +0100
                                          Re: Why I use gcc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-08 17:21 +0100
                                        Re: Why I use gcc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-08 16:39 +0100
                                          Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-08 16:58 +0100
                                            Re: Why I use gcc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-08 21:15 +0100
                                        Re: Why I use gcc supercat@casperkitty.com - 2016-10-08 11:27 -0700
                                          Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-08 20:09 +0100
                                            Re: Why I use gcc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-08 21:16 +0100
                                              Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-08 21:28 +0100
                                                Re: Why I use gcc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-09 01:19 +0100
                                                  Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-09 01:36 +0100
                                Re: Why I use gcc Thiago Adams <thiago.adams@gmail.com> - 2016-10-08 09:32 -0700
                                  Re: Why I use gcc Tim Rentsch <txr@alumni.caltech.edu> - 2016-10-09 03:44 -0700
                                    Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-09 12:07 +0100
                                  Re: Why I use gcc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-09 12:12 +0100
                                    Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-09 12:37 +0100
                                      Re: Why I use gcc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-09 13:57 +0100
                                        Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-09 14:32 +0100
                                          Re: Why I use gcc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-10-09 20:00 +0100
                                            Re: Why I use gcc Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-09 13:14 -0700
                                            Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-09 22:54 +0100
                                          Re: Why I use gcc Tim Rentsch <txr@alumni.caltech.edu> - 2016-10-15 14:40 -0700
                  Re: Why I use gcc James Kuyper <jameskuyper@verizon.net> - 2016-10-07 10:37 -0400
                    Re: Why I use gcc supercat@casperkitty.com - 2016-10-07 07:52 -0700
                      Re: Why I use gcc jameskuyper@verizon.net - 2016-10-07 09:10 -0700
                        Re: Why I use gcc supercat@casperkitty.com - 2016-10-07 10:48 -0700
                          Re: Why I use gcc jameskuyper@verizon.net - 2016-10-07 16:21 -0700
                            Re: Why I use gcc supercat@casperkitty.com - 2016-10-08 11:15 -0700
                    Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-07 17:12 +0100
                      Re: Why I use gcc Keith Thompson <kst-u@mib.org> - 2016-10-07 12:20 -0700
                        Re: Why I use gcc Thiago Adams <thiago.adams@gmail.com> - 2016-10-07 12:32 -0700
    Re: Why I use gcc Richard Heathfield <rjh@cpax.org.uk> - 2016-09-26 14:45 +0100
      Re: Why I use gcc BartC <bc@freeuk.com> - 2016-09-26 15:12 +0100
        Re: Why I use gcc Richard Heathfield <rjh@cpax.org.uk> - 2016-09-26 15:26 +0100
          Re: Why I use gcc supercat@casperkitty.com - 2016-09-26 08:00 -0700
            Re: Why I use gcc Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-28 10:49 -0700
          Re: Why I use gcc BartC <bc@freeuk.com> - 2016-09-26 17:30 +0100
            Re: Why I use gcc David Brown <david.brown@hesbynett.no> - 2016-09-26 21:12 +0200
              Re: Why I use gcc jacobnavia <jacob@jacob.remcomp.fr> - 2016-09-26 22:09 +0200
              Re: Why I use gcc supercat@casperkitty.com - 2016-09-26 13:32 -0700
                Re: Why I use gcc jacobnavia <jacob@jacob.remcomp.fr> - 2016-09-26 23:14 +0200
                  Re: Why I use gcc Richard Heathfield <rjh@cpax.org.uk> - 2016-09-26 22:47 +0100
                    Re: Why I use gcc BartC <bc@freeuk.com> - 2016-09-27 01:13 +0100
                      Re: Why I use gcc Richard Heathfield <rjh@cpax.org.uk> - 2016-09-27 01:18 +0100
                      Re: Why I use gcc Keith Thompson <kst-u@mib.org> - 2016-09-26 17:41 -0700
                        Re: Why I use gcc BartC <bc@freeuk.com> - 2016-09-27 02:01 +0100
                          Re: Why I use gcc Keith Thompson <kst-u@mib.org> - 2016-09-27 08:41 -0700
                    Re: Why I use gcc James Harris <james.harris.1@gmail.com> - 2016-09-27 01:41 +0100
                      Re: Why I use gcc jameskuyper@verizon.net - 2016-09-26 18:15 -0700
                      Re: Why I use gcc Gareth Owen <gwowen@gmail.com> - 2016-09-27 20:59 +0100
                        Re: Why I use gcc Richard Heathfield <rjh@cpax.org.uk> - 2016-09-27 21:50 +0100
                          Re: Why I use gcc Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-28 06:26 -0700
                        Re: Why I use gcc gazelle@shell.xmission.com (Kenny McCormack) - 2016-09-27 23:23 +0000
                        Re: Why I use gcc Noob <root@127.0.0.1> - 2016-10-08 00:12 +0200
                          Re: Why I use gcc James Kuyper <jameskuyper@verizon.net> - 2016-10-07 23:11 -0400
                            Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-08 10:58 +0100
                              Re: Why I use gcc jameskuyper@verizon.net - 2016-10-08 07:07 -0700
                          Re: Why I use gcc Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-07 21:44 -0700
                Re: Why I use gcc David Brown <david.brown@hesbynett.no> - 2016-09-27 09:48 +0200
                  Re: Why I use gcc BartC <bc@freeuk.com> - 2016-09-27 11:22 +0100
                    Re: Why I use gcc David Brown <david.brown@hesbynett.no> - 2016-09-27 13:52 +0200
                      Re: Why I use gcc jacobnavia <jacob@jacob.remcomp.fr> - 2016-09-27 14:47 +0200
                        Re: Why I use gcc David Brown <david.brown@hesbynett.no> - 2016-09-27 15:18 +0200
                          Re: Why I use gcc BartC <bc@freeuk.com> - 2016-09-27 14:38 +0100
                            Re: Why I use gcc jacobnavia <jacob@jacob.remcomp.fr> - 2016-09-27 17:21 +0200
                          Re: Why I use gcc jacobnavia <jacob@jacob.remcomp.fr> - 2016-09-27 17:17 +0200
                            Re: Why I use gcc Keith Thompson <kst-u@mib.org> - 2016-09-27 08:52 -0700
                            Re: Why I use gcc Robert Wessel <robertwessel2@yahoo.com> - 2016-09-30 02:00 -0500
                      Re: Why I use gcc supercat@casperkitty.com - 2016-09-27 07:18 -0700
                      Re: Why I use gcc Keith Thompson <kst-u@mib.org> - 2016-09-27 08:46 -0700
                        Re: Why I use gcc supercat@casperkitty.com - 2016-09-27 09:11 -0700
                    Re: Why I use gcc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-27 13:33 +0100
                      Re: Why I use gcc BartC <bc@freeuk.com> - 2016-09-27 14:13 +0100
                        Re: Why I use gcc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-27 15:30 +0100
                          Re: Why I use gcc supercat@casperkitty.com - 2016-09-27 08:29 -0700
                  Re: Why I use gcc supercat@casperkitty.com - 2016-09-27 07:11 -0700
              Re: Why I use gcc BartC <bc@freeuk.com> - 2016-09-26 21:43 +0100
              Re: Why I use gcc raltbos@xs4all.nl (Richard Bos) - 2016-09-30 17:50 +0000
            Re: Why I use gcc BartC <bc@freeuk.com> - 2016-09-27 01:04 +0100
              Re: Why I use gcc Keith Thompson <kst-u@mib.org> - 2016-09-26 17:39 -0700
                Re: Why I use gcc BartC <bc@freeuk.com> - 2016-09-27 01:49 +0100
                  Re: Why I use gcc Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-09-27 11:39 +0100
                    Re: Why I use gcc BartC <bc@freeuk.com> - 2016-09-27 11:56 +0100
                      Re: Why I use gcc Tim Rentsch <txr@alumni.caltech.edu> - 2016-09-27 15:15 -0700
                        Re: Why I use gcc David Brown <david.brown@hesbynett.no> - 2016-09-28 08:55 +0200
      Re: Why I use gcc jacobnavia <jacob@jacob.remcomp.fr> - 2016-09-26 22:11 +0200
        Re: Why I use gcc Richard Heathfield <rjh@cpax.org.uk> - 2016-09-26 22:04 +0100
    Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-10 11:39 +0100
      Re: Why I use gcc already5chosen@yahoo.com - 2016-10-10 07:32 -0700
        Re: Why I use gcc Richard Heathfield <rjh@cpax.org.uk> - 2016-10-10 16:17 +0100
          Re: Why I use gcc Robert Wessel <robertwessel2@yahoo.com> - 2016-10-10 21:09 -0500
            Re: Why I use gcc Richard Heathfield <rjh@cpax.org.uk> - 2016-10-11 04:18 +0100
            Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-11 10:56 +0100
              Re: Why I use gcc already5chosen@yahoo.com - 2016-10-11 04:08 -0700
                Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-11 13:36 +0100
                  Re: Why I use gcc already5chosen@yahoo.com - 2016-10-11 06:20 -0700
                    Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-11 14:29 +0100
                  Re: Why I use gcc Keith Thompson <kst-u@mib.org> - 2016-10-11 09:31 -0700
                    Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-11 19:38 +0100
                      Re: Why I use gcc supercat@casperkitty.com - 2016-10-11 12:23 -0700
                        Re: Why I use gcc jacobnavia <jacob@jacob.remcomp.fr> - 2016-10-11 23:19 +0200
                          Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-11 23:26 +0100
                            Re: Why I use gcc jacobnavia <jacob@jacob.remcomp.fr> - 2016-10-12 09:01 +0200
                          Re: Why I use gcc supercat@casperkitty.com - 2016-10-12 08:55 -0700
                            Re: Why I use gcc already5chosen@yahoo.com - 2016-10-12 10:52 -0700
                              Re: Why I use gcc supercat@casperkitty.com - 2016-10-12 12:34 -0700
                                Re: Why I use gcc Keith Thompson <kst-u@mib.org> - 2016-10-12 13:18 -0700
                                Re: Why I use gcc luser droog <luser.droog@gmail.com> - 2016-10-12 13:24 -0700
                        Re: Why I use gcc crankypuss <undisclosedUserid@gmail.com> - 2016-10-13 13:31 -0600
                          Re: Why I use gcc Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-16 03:00 -0700
                            Re: Why I use gcc crankypuss <undisclosedUserid@gmail.com> - 2016-10-16 04:46 -0600
                              Re: Why I use gcc Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-10-16 04:05 -0700
                      Re: Why I use gcc Keith Thompson <kst-u@mib.org> - 2016-10-11 12:28 -0700
                        Re: Why I use gcc Thiago Adams <thiago.adams@gmail.com> - 2016-10-11 13:24 -0700
                        Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-11 21:28 +0100
                        Re: Why I use gcc gazelle@shell.xmission.com (Kenny McCormack) - 2016-10-11 20:43 +0000
                  Re: Why I use gcc Robert Wessel <robertwessel2@yahoo.com> - 2016-10-11 23:40 -0500
              Re: Why I use gcc already5chosen@yahoo.com - 2016-10-11 04:40 -0700
        Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-10 18:19 +0100
      Re: Why I use gcc Keith Thompson <kst-u@mib.org> - 2016-10-10 09:08 -0700
        Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-10 18:04 +0100
          Re: Why I use gcc supercat@casperkitty.com - 2016-10-10 10:39 -0700
          Re: Why I use gcc Keith Thompson <kst-u@mib.org> - 2016-10-10 11:25 -0700
        Re: Why I use gcc Jerry Stuckle <jstucklex@attglobal.net> - 2016-10-10 17:05 -0400
          Re: Why I use gcc supercat@casperkitty.com - 2016-10-10 14:46 -0700
      Re: Why I use gcc BartC <bc@freeuk.com> - 2016-10-15 13:39 +0100
        Re: Why I use gcc Keith Thompson <kst-u@mib.org> - 2016-10-15 13:40 -0700
          Re: Why I use gcc already5chosen@yahoo.com - 2016-10-15 13:46 -0700

Page 1 of 8  [1] 2 3 4 5 6 7 8  Next page →

#94083 — Why I use gcc

I normally generate my own native code for my projects but often 
translate to C source and use gcc -O3 for a bit of extra speed.

But I sometimes like to generate C anyway so that the project is in a 
form that can be compiled by anyone. In that case I prefer not to have 
to stipulate which C compiler should be used. They don't make it easy 
however!

For example ('function' is an empty macro and int32/uint32 are typedefs):

     extern function _stdcall int32 GetStdHandle(uint32 _1);

This is fine in gcc/tcc but other compilers don't like the __stdcall 
(used in 32-bit Windows) before the int32; it has to be after.

A similar problem with 64 bit Windows, where I have to put the declspec 
after the void (but gcc/tcc don't care):

     extern function void *__declspec(dllimport) GetProcAddress(uint64
      _1,char (*_2));

This shuts up the two complaining compilers, but the third needs to have 
the "*" after the declspec not before!

And when stdcall/declspec is sorted, one compiler don't like __stdcall 
within a cast:

          return (int64)((int32 __stdcall (*)(void))fnaddr)();

But the same compiler has no problem with __declspec(dllimport) in the 
same place for 64-bits!

Even when such problems are overcome (with a temporary workaround 
sometimes just to see what else will crop up), then one compiler crashes 
when trying to link.

Another has a mysterious undefined powid() call when linking. (To do 
with optimising exponentiation. But when the code is altered to avoid 
exponentiation completely and it links, the program crashes for other 
mysterious reasons.)

Yet another fails with an internal error (to do with incorrect operands 
for its internal assembler) when compiling this code:

       if (((uint32)(flags).codes[1-1]==83)) ...

But only when optimised. If optimisation is turned off for that module, 
then it compiles the rest (with a manual fix for the *__declspec 
problem), but then has an undefined _exit() symbol when linking (WTF?). 
I need to use ExitProcess() instead to get around that.

Apart from such problems, there is clang. This no longer works on my 
machine: apparently it now piggybacks onto MSVC rather than gcc, and I 
don't have a proper MSVC (of course, it tells you nothing about such 
matters). Using the -I switch to use gcc's includes allows you to 
compiler hello.c, but little else as it gives an error when compiling 
gcc's stdlib.h.

So clang might be fine, for someone with a working copy, but I can't 
test it.

This means if I distribute a project as C source code, I will need to 
recommend gcc to compile it. Or Tiny C.

-- 
Bartc

[toc] | [next] | [standalone]

#94084

On 26/09/16 15:31, BartC wrote:
> I normally generate my own native code for my projects but often
> translate to C source and use gcc -O3 for a bit of extra speed.
> 
> But I sometimes like to generate C anyway so that the project is in a
> form that can be compiled by anyone. In that case I prefer not to have
> to stipulate which C compiler should be used. They don't make it easy
> however!
> 
> For example ('function' is an empty macro and int32/uint32 are typedefs):
> 
>     extern function _stdcall int32 GetStdHandle(uint32 _1);
> 
> This is fine in gcc/tcc but other compilers don't like the __stdcall
> (used in 32-bit Windows) before the int32; it has to be after.
> 
> A similar problem with 64 bit Windows, where I have to put the declspec
> after the void (but gcc/tcc don't care):
> 
>     extern function void *__declspec(dllimport) GetProcAddress(uint64
>      _1,char (*_2));
> 
> This shuts up the two complaining compilers, but the third needs to have
> the "*" after the declspec not before!
> 
> And when stdcall/declspec is sorted, one compiler don't like __stdcall
> within a cast:
> 
>          return (int64)((int32 __stdcall (*)(void))fnaddr)();
> 
> But the same compiler has no problem with __declspec(dllimport) in the
> same place for 64-bits!
> 

<snip>

Why don't you do what everyone else does when they want code to work
with multiple compilers, and are faced with different
implementation-dependent features of the tools?  Define some macros,
with some conditional compilation at the start of the file:

#ifdef __gnuc__
#define STDCALL(t) _stdcall t
#else
#define STDCALL(t) t _stdcall
#endif

...

extern function STDCALL(int32) GetStdHandle(uint32 _1);


Sort out the different arrangements needed for the different types of
function calls, and the different compilers, and make macros to suit.

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

#94087

On 26/09/2016 14:45, David Brown wrote:
> On 26/09/16 15:31, BartC wrote:

>> And when stdcall/declspec is sorted, one compiler doesn't like __stdcall
>> within a cast:
>>
>>          return (int64)((int32 __stdcall (*)(void))fnaddr)();
>>
>> But the same compiler has no problem with __declspec(dllimport) in the
>> same place for 64-bits!
>>
>
> <snip>
>
> Why don't you do what everyone else does when they want code to work
> with multiple compilers, and are faced with different
> implementation-dependent features of the tools?  Define some macros,
> with some conditional compilation at the start of the file:
>
> #ifdef __gnuc__
> #define STDCALL(t) _stdcall t
> #else
> #define STDCALL(t) t _stdcall
> #endif
>
> ...
>
> extern function STDCALL(int32) GetStdHandle(uint32 _1);
>
>
> Sort out the different arrangements needed for the different types of
> function calls, and the different compilers, and make macros to suit.

We're talking about C type declarations here. The __stdcall needs to go 
somewhere *inside* the type not either on left or right.

When t is int*, then your macros will give:

     __stdcall int*   or   int* _stdcall

but one compiler appears to want int __stdcall * !

Also I'm not sure what I can do about the compiler that doesn't like 
__stdcall inside a cast; I think I will need to rewrite the code for 
that and see if __stdcall is allowed inside a typedef, and cast using 
the typedef.

But, whatever, it's a damned nuisance. It is very tempting to just say 
use gcc as only that is known to work (and to give reasonable code).

-- 
Bartc

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

#94089

On 26/09/16 16:22, BartC wrote:
> On 26/09/2016 14:45, David Brown wrote:
>> On 26/09/16 15:31, BartC wrote:
> 
>>> And when stdcall/declspec is sorted, one compiler doesn't like __stdcall
>>> within a cast:
>>>
>>>          return (int64)((int32 __stdcall (*)(void))fnaddr)();
>>>
>>> But the same compiler has no problem with __declspec(dllimport) in the
>>> same place for 64-bits!
>>>
>>
>> <snip>
>>
>> Why don't you do what everyone else does when they want code to work
>> with multiple compilers, and are faced with different
>> implementation-dependent features of the tools?  Define some macros,
>> with some conditional compilation at the start of the file:
>>
>> #ifdef __gnuc__
>> #define STDCALL(t) _stdcall t
>> #else
>> #define STDCALL(t) t _stdcall
>> #endif
>>
>> ...
>>
>> extern function STDCALL(int32) GetStdHandle(uint32 _1);
>>
>>
>> Sort out the different arrangements needed for the different types of
>> function calls, and the different compilers, and make macros to suit.
> 
> We're talking about C type declarations here. The __stdcall needs to go
> somewhere *inside* the type not either on left or right.
> 
> When t is int*, then your macros will give:
> 
>     __stdcall int*   or   int* _stdcall
> 
> but one compiler appears to want int __stdcall * !
> 

Then write your macros to suit.  You are generating the code
automatically - make your code generate the macro calls needed.  Add:

#ifdef __gnuc__
#define STDCALL_P(t) _stdcall t*
#else
#define STDCALL_P(t) t _stdcall *
#endif

...

extern function STDCALL_P(int32) GetStdHandle(uint32 _1);

or whatever is necessary.

> Also I'm not sure what I can do about the compiler that doesn't like
> __stdcall inside a cast; I think I will need to rewrite the code for
> that and see if __stdcall is allowed inside a typedef, and cast using
> the typedef.
> 
> But, whatever, it's a damned nuisance. It is very tempting to just say
> use gcc as only that is known to work (and to give reasonable code).
> 

It's something you have to deal with, and it might be a pain keeping it
up to date when you use a different compiler, but it is not hard.

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

#94173

BartC <bc@freeuk.com> writes:

> On 26/09/2016 14:45, David Brown wrote:
>> On 26/09/16 15:31, BartC wrote:
>>
>>> And when stdcall/declspec is sorted, one compiler doesn't like __stdcall
>>> within a cast:
>>>
>>>          return (int64)((int32 __stdcall (*)(void))fnaddr)();
>>>
>>> But the same compiler has no problem with __declspec(dllimport) in the
>>> same place for 64-bits!
>>
>> <snip>
>>
>> Why don't you do what everyone else does when they want code to work
>> with multiple compilers, and are faced with different
>> implementation-dependent features of the tools?  Define some macros,
>> with some conditional compilation at the start of the file:
>>
>> #ifdef __gnuc__
>> #define STDCALL(t) _stdcall t
>> #else
>> #define STDCALL(t) t _stdcall
>> #endif
>>
>> ...
>>
>> extern function STDCALL(int32) GetStdHandle(uint32 _1);
>>
>>
>> Sort out the different arrangements needed for the different types of
>> function calls, and the different compilers, and make macros to suit.
>
> We're talking about C type declarations here.  The __stdcall needs to
> go somewhere *inside* the type not either on left or right.
>
> When t is int*, then your macros will give:
>
>     __stdcall int*   or   int* _stdcall
>
> but one compiler appears to want int __stdcall * !

I am curious.  Which compiler is that?  Do you know what happens
with that compiler if '__stdcall int *' is used instead?

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

#94178

On 27/09/2016 23:05, Tim Rentsch wrote:
> BartC <bc@freeuk.com> writes:

>> We're talking about C type declarations here.  The __stdcall needs to
>> go somewhere *inside* the type not either on left or right.
>>
>> When t is int*, then your macros will give:
>>
>>     __stdcall int*   or   int* _stdcall
>>
>> but one compiler appears to want int __stdcall * !
>
> I am curious.  Which compiler is that?  Do you know what happens
> with that compiler if '__stdcall int *' is used instead?

I thought I must have been imagining things because I couldn't found the 
problem any more.

But it appears to be a misunderstanding: it was __declspec not 
__stdcall; int(*)() not int*; and in a cast not a normal declaration. 
(So much for my powers of recall.)

Examples:

  void* fnaddr;

  return ((int __declspec(dllimport) (*) (void))fnaddr)();  // (1)
  return ((int(*) __declspec(dllimport)  (void))fnaddr)();  // (2)
  return ((__declspec(dllimport) int(*)  (void))fnaddr)();  // (3)

(2) is wrong on all compilers, because the (*?) is where the name of the 
function would go, and stdcall/declspec can't occur after the function name.

So it's down to the compiler (Pelles C) compiling (1) and not (2). It's 
just fussy about being before or after the type.

However if __stdcall is used in these casts, then it doesn't like it at 
all, even though __stdcall can be used for normal declarations. (I 
haven't tried declarations of pointers.)

-- 
Bartc

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

#94196

BartC <bc@freeuk.com> writes:

> On 27/09/2016 23:05, Tim Rentsch wrote:
>> BartC <bc@freeuk.com> writes:
>>
>>> We're talking about C type declarations here.  The __stdcall needs to
>>> go somewhere *inside* the type not either on left or right.
>>>
>>> When t is int*, then your macros will give:
>>>
>>>     __stdcall int*   or   int* _stdcall
>>>
>>> but one compiler appears to want int __stdcall * !
>>
>> I am curious.  Which compiler is that?  Do you know what happens
>> with that compiler if '__stdcall int *' is used instead?
>
> I thought I must have been imagining things because I couldn't found
> the problem any more.
>
> But it appears to be a misunderstanding:  it was __declspec not
> __stdcall;  int(*)() not int*; and in a cast not a normal
> declaration.  (So much for my powers of recall.)
>
> Examples:
>
>  void* fnaddr;
>
>  return ((int __declspec(dllimport) (*) (void))fnaddr)();  // (1)
>  return ((int(*) __declspec(dllimport)  (void))fnaddr)();  // (2)
>  return ((__declspec(dllimport) int(*)  (void))fnaddr)();  // (3)
>
> (2) is wrong on all compilers, because the (*?) is where the name of
> the function would go, and stdcall/declspec can't occur after the
> function name.
>
> So it's down to the compiler (Pelles C) compiling (1) and not
> (2).  It's just fussy about being before or after the type.
>
> However if __stdcall is used in these casts, then it doesn't like it
> at all, even though __stdcall can be used for normal declarations.  (I
> haven't tried declarations of pointers.)

What happens if you try, eg,

    (int (__stdcall *)()) function_pointer

like what Microsoft's documentation shows for similar cases?

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

#94203

On 28/09/2016 17:50, Tim Rentsch wrote:
> BartC <bc@freeuk.com> writes:

>>  return ((int __declspec(dllimport) (*) (void))fnaddr)();  // (1)
>>  return ((int(*) __declspec(dllimport)  (void))fnaddr)();  // (2)
>>  return ((__declspec(dllimport) int(*)  (void))fnaddr)();  // (3)
>>
>> (2) is wrong on all compilers, because the (*?) is where the name of
>> the function would go, and stdcall/declspec can't occur after the
>> function name.
>>
>> So it's down to the compiler (Pelles C) compiling (1) and not
>> (2).  It's just fussy about being before or after the type.
>>
>> However if __stdcall is used in these casts, then it doesn't like it
>> at all, even though __stdcall can be used for normal declarations.  (I
>> haven't tried declarations of pointers.)
>
> What happens if you try, eg,
>
>     (int (__stdcall *)()) function_pointer
>
> like what Microsoft's documentation shows for similar cases?

Bingo - that works. Thanks.

(However the same syntax doesn't work for __declspec(dllimport), which 
still has to be in the (1) format above.

Now I just have to rewrite my C-type-spec generator to incorporate an 
internal attribute as well as a name, and take heed of these different 
rules.

The code generator doesn't know what C compiler is to be used, but it 
will know whether one of __stdcall or __declspec is needed, and it looks 
like there could be a common syntax subset that is acceptable across all 
compilers.)

-- 
bartc

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

#94548

On 28/09/2016 18:39, BartC wrote:
> On 28/09/2016 17:50, Tim Rentsch wrote:
>> BartC <bc@freeuk.com> writes:
>
>>>  return ((int __declspec(dllimport) (*) (void))fnaddr)();  // (1)
>>>  return ((int(*) __declspec(dllimport)  (void))fnaddr)();  // (2)
>>>  return ((__declspec(dllimport) int(*)  (void))fnaddr)();  // (3)
>>>
>>> (2) is wrong on all compilers, because the (*?) is where the name of
>>> the function would go, and stdcall/declspec can't occur after the
>>> function name.
>>>
>>> So it's down to the compiler (Pelles C) compiling (1) and not
>>> (2).  It's just fussy about being before or after the type.
>>>
>>> However if __stdcall is used in these casts, then it doesn't like it
>>> at all, even though __stdcall can be used for normal declarations.  (I
>>> haven't tried declarations of pointers.)
>>
>> What happens if you try, eg,
>>
>>     (int (__stdcall *)()) function_pointer
>>
>> like what Microsoft's documentation shows for similar cases?
>
> Bingo - that works. Thanks.
>
> (However the same syntax doesn't work for __declspec(dllimport), which
> still has to be in the (1) format above.
>
> Now I just have to rewrite my C-type-spec generator to incorporate an
> internal attribute as well as a name, and take heed of these different
> rules.
>
> The code generator doesn't know what C compiler is to be used, but it
> will know whether one of __stdcall or __declspec is needed, and it looks
> like there could be a common syntax subset that is acceptable across all
> compilers.)

I'm about to implement this stuff now and tests have shown that these 
formats are best, when using function pointers:

For __stdcall (for 32-Windows), this syntax works across all compilers 
I've tried (Pelles C, lccwin, DMC, gcc, Tiny C; clang I guess will work 
like gcc):

#include <stdio.h>       // REQUIRED BY TINY C

static int *	(__stdcall *bill)	(int,int);

int main(void) {
void* fnaddr;
int * p;

     p = ((int *	(__stdcall *)	(int,int))fnaddr)(10,20);
     return  ((int (__stdcall *)	(int a,int b))fnaddr)(10,20);
}

(Tiny C needs stdio.h where __stdcall is declared. Not a big deal as it 
will nearly always be present - except when testing a fragment of code 
like this where you're tearing your hair out wondering why it works 
elsewhere but not here!)

For __declspec(dllimport) (occurs in 64-bit Windows), works across all 
compilers except Pelles C:

#include <stdio.h>

static int * (__declspec(dllimport) *bill) (int,int);

int main(void) {
void* fnaddr;
int * p;

     p = ((int *	(__declspec(dllimport) *) (int,int))fnaddr)
       (10,20);
     return  ((int (__declspec(dllimport) *) (int a,int b))fnaddr)
       (10,20);
}

For Pelles C, this is the best I could come up with:

static int __declspec(dllimport)* (*bill) (int,int);

int main(void) {
void* fnaddr;
int * p;

     p = ((int __declspec(dllimport)*(*) (int,int))fnaddr)
         (10,20);
     return  ((int __declspec(dllimport) (*) (int a,int b))fnaddr)
         (10,20);
}

It doesn't like the static declaration, but the other two are OK. With 
the static, it seems to be getting mixed up with the external attribute 
of the function being pointed to, and the static attribute of the 
pointer itself. (gcc has the same problem in this form, but I will use 
the alternate syntax for that.)

So I think I will leave Pelles C 64-bit off my list of tested compilers, 
and file a bug report. (Of course there are many other tests to do 
another than just manage to struggle through a compilation; the program 
has to link and work. And at least two of the compilers have crashed 
while linking.)

That still leaves gcc as the least troublesome compiler.

However I yet have to modify my code generator to stick the attribute 
just inside the opening "(" of the "(*)" or "(*name)" that is apparently 
always present in a function pointer declaration. It's harder than it 
sounds.

-- 
Bartc

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

#94549

On Friday, October 7, 2016 at 12:28:15 PM UTC+1, Bart wrote:
> On 28/09/2016 18:39, BartC wrote:
> 
> (Tiny C needs stdio.h where __stdcall is declared. Not a big deal as it 
> will nearly always be present - except when testing a fragment of code 
> like this where you're tearing your hair out wondering why it works 
> elsewhere but not here!)
> 
That's a nuisance to me.

My method involves separating the functions (which I must call Malcolm-functions
in the context of comp.lang.c) from the procedures, call them Malcolm-procedures
to avert protests.
Malcolm-functions are not allowed to do IO, Malcolm-procedures are. So ideally
inclusion or non-inclusion of stdio.h would be the marker.

And we want as much of the program as possible to be Malcolm-functions.

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

#94551

On Wednesday, September 28, 2016 at 2:39:14 PM UTC-3, Bart wrote:
...
> 
> (However the same syntax doesn't work for __declspec(dllimport), which 
> still has to be in the (1) format above.
> 
> Now I just have to rewrite my C-type-spec generator to incorporate an 
> internal attribute as well as a name, and take heed of these different 
> rules.
> 
> The code generator doesn't know what C compiler is to be used, but it 
> will know whether one of __stdcall or __declspec is needed, and it looks 
> like there could be a common syntax subset that is acceptable across all 
> compilers.)


What is this "my C-type-spec generator" ? What it does?

By coincidence I was searching for grammar of these calling conventions.
Where they go in the grammar? Similar of type-qualifier?

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

#94552

On 07/10/2016 13:31, Thiago Adams wrote:
> On Wednesday, September 28, 2016 at 2:39:14 PM UTC-3, Bart wrote:
> ...
>>
>> (However the same syntax doesn't work for __declspec(dllimport), which
>> still has to be in the (1) format above.
>>
>> Now I just have to rewrite my C-type-spec generator to incorporate an
>> internal attribute as well as a name, and take heed of these different
>> rules.
>>
>> The code generator doesn't know what C compiler is to be used, but it
>> will know whether one of __stdcall or __declspec is needed, and it looks
>> like there could be a common syntax subset that is acceptable across all
>> compilers.)
>
>
> What is this "my C-type-spec generator" ? What it does?

It's part of my compiler which can translate another language to C 
source code. It needs to take an internal representation of a type (or a 
function declaration; the two are distinct in the other language), and 
write it out in C type declaration syntax.

> By coincidence I was searching for grammar of these calling conventions.
> Where they go in the grammar? Similar of type-qualifier?

This is the trouble. Compilers do different things. Some may accept 
alternatives.

But given these examples:

  int foo (void);
  int* foo (void);
  int (*foo) (void);
  int* (*foo) (void);
  (int (*)(void))        // casts
  (int* (*)(void))

then I believe the attribute A goes in these places for /most/ compilers:

  int A foo (void);
  int*  foo (void);
  int (A *foo) (void);
  int* (A *foo) (void);
  (int (A *)(void))
  (int* (A *)(void))

But some compilers will accept different placements of A (which caused 
some of the trouble, as later on others mysteriously rejected those 
forms). Example:

  A int foo (void); // rejected by Pelles C and DMC

I suspect this hasn't been standardised.

-- 
Bartc

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

#94554

On Friday, October 7, 2016 at 10:00:48 AM UTC-3, Bart wrote:
> On 07/10/2016 13:31, Thiago Adams wrote:
> > On Wednesday, September 28, 2016 at 2:39:14 PM UTC-3, Bart wrote:
> > ...
> >>
> >> (However the same syntax doesn't work for __declspec(dllimport), which
> >> still has to be in the (1) format above.
> >>
> >> Now I just have to rewrite my C-type-spec generator to incorporate an
> >> internal attribute as well as a name, and take heed of these different
> >> rules.
> >>
> >> The code generator doesn't know what C compiler is to be used, but it
> >> will know whether one of __stdcall or __declspec is needed, and it looks
> >> like there could be a common syntax subset that is acceptable across all
> >> compilers.)
> >
> >
> > What is this "my C-type-spec generator" ? What it does?
> 
> It's part of my compiler which can translate another language to C 
> source code. It needs to take an internal representation of a type (or a 
> function declaration; the two are distinct in the other language), and 
> write it out in C type declaration syntax.

Are you planning to debug your language?

I also was thinking how to do this.
In my case "other language" would be C11 or C11 plus my experiments and target language is ANSI C.
I did some tests with visual studio and #line directive. I didn't conclude if it was something practical to do. Breakpoints and debugger worked.

> > By coincidence I was searching for grammar of these calling conventions.
> > Where they go in the grammar? Similar of type-qualifier?
> 
> This is the trouble. Compilers do different things. Some may accept 
> alternatives.
> 
> But given these examples:
> 
>   int foo (void);
>   int* foo (void);
>   int (*foo) (void);
>   int* (*foo) (void);
>   (int (*)(void))        // casts
>   (int* (*)(void))
> 
> then I believe the attribute A goes in these places for /most/ compilers:
> 
>   int A foo (void);
>   int*  foo (void);
>   int (A *foo) (void);
>   int* (A *foo) (void);
>   (int (A *)(void))
>   (int* (A *)(void))
> 

Looks like this part on C grammar

pointer:
calling-convention
calling-conventionOpt * type-qualifier-listopt
calling-conventionOpt * type-qualifier-listopt pointer



calling-convention:
__fastcall
etc...

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

#94561

On 07/10/2016 15:48, Thiago Adams wrote:
> On Friday, October 7, 2016 at 10:00:48 AM UTC-3, Bart wrote:
>> On 07/10/2016 13:31, Thiago Adams wrote:

>>> What is this "my C-type-spec generator" ? What it does?
>>
>> It's part of my compiler which can translate another language to C
>> source code. It needs to take an internal representation of a type (or a
>> function declaration; the two are distinct in the other language), and
>> write it out in C type declaration syntax.
>
> Are you planning to debug your language?

That language is fine. Normally it's converted to x64 asm source code 
which is in many ways much easier than generating C!

But C's inside-out type declarations are tricky to get right, to 
minimise the number of parentheses, and to format nicely.

In the source language, I just write:

  ref windows function (int, int)=>ref int p

(declare p as pointer to Windows function taking two ints and returning 
pointer to int)

It currently generates this, where int32 is int32_t:

   int32 * __declspec(dllimport) (*p) (int32, int32);

That declspec thing must go between the "(" and "*" in "(*".

(If you mean, mapping errors lines in the generated C to the original 
source, then that is a separate matter. But once the compiler is 
debugged, errors in the generated C source arising errors in user 
programs are rare.)

> I also was thinking how to do this.
> In my case "other language" would be C11 or C11 plus my experiments and target language is ANSI C.
> I did some tests with visual studio and #line directive. I didn't conclude if it was something practical to do. Breakpoints and debugger worked.

I was thinking of doing the same once with C99 to C89 (and then 
experiment with lots of ideas for enhancements). But I doubt I'm ever 
going to do a C front-end because I would find it difficult to parse a 
syntax I don't care for.

>> then I believe the attribute A goes in these places for /most/ compilers:
>>
>>   int A foo (void);
>>   int*  foo (void);
>>   int (A *foo) (void);
>>   int* (A *foo) (void);
>>   (int (A *)(void))
>>   (int* (A *)(void))
>>
>
> Looks like this part on C grammar
>
> pointer:
> calling-convention
> calling-conventionOpt * type-qualifier-listopt
> calling-conventionOpt * type-qualifier-listopt pointer
>
> calling-convention:
> __fastcall
> etc...

Where is that from? I can't find it in the C99 standard.

-- 
Bartc

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

#94563

On Friday, October 7, 2016 at 1:36:33 PM UTC-3, Bart wrote:
...
> But C's inside-out type declarations are tricky to get right, to 
> minimise the number of parentheses, and to format nicely.

I got it right after to read:

The C Programming Language  - Second edition
Page 102.
5.12 Complicated Declarations
 
...

> > Looks like this part on C grammar
> >
> > pointer:
> > calling-convention
> > calling-conventionOpt * type-qualifier-listopt
> > calling-conventionOpt * type-qualifier-listopt pointer
> >
> > calling-convention:
> > __fastcall
> > etc...
> 
> Where is that from? I can't find it in the C99 standard.

The part that exists in C grammar is: (just)

6.7.6 Declarators

...
pointer:
  * type-qualifier-listopt
  * type-qualifier-listopt pointer

I add the imaginary "calling-convention" just to try to understand where it would be added (if exists) in the C grammar.

Today, for my parser, I add macros 
#define __fastcall 
etc..
If this is something very common for many compilers I was thinking to make it "build-in".

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

#94565

On 07/10/2016 18:38, Thiago Adams wrote:
> On Friday, October 7, 2016 at 1:36:33 PM UTC-3, Bart wrote:
> ...
>> But C's inside-out type declarations are tricky to get right, to
>> minimise the number of parentheses, and to format nicely.
>
> I got it right after to read:
>
> The C Programming Language  - Second edition
> Page 102.
> 5.12 Complicated Declarations

(On page 122 actually.) That section acknowledges that there are 
problems and goes on to demonstrate what may be an early version of 
Cdecl. That is, a program that converts to and from C declarations. It 
doesn't suggest a way of making it easier for for humans! Not without 
using some artificial aid.

I need to tweak my generator to do the conversion then hopefully I never 
need to understand these things again.

>>> Looks like this part on C grammar
>>>
>>> pointer:
>>> calling-convention
>>> calling-conventionOpt * type-qualifier-listopt
>>> calling-conventionOpt * type-qualifier-listopt pointer
>>>
>>> calling-convention:
>>> __fastcall
>>> etc...
>>
>> Where is that from? I can't find it in the C99 standard.
>
> The part that exists in C grammar is: (just)
>
> 6.7.6 Declarators
>
> ...
> pointer:
>   * type-qualifier-listopt
>   * type-qualifier-listopt pointer
>
> I add the imaginary "calling-convention" just to try to understand where it would be added (if exists) in the C grammar.

Type-qualifiers seem be 'const' and 'volatile'. Trouble is I've no idea 
where they go either! Especially in relation to functions as they 
wouldn't make sense there.

> Today, for my parser, I add macros
> #define __fastcall
> etc..
> If this is something very common for many compilers I was thinking to make it "build-in".

(I used to use:

#define function
#define proc void
#define global

Then I could write:

global function int foo(void);
global proc bar(void);

But I've dropped such things from the generator for less clutter (and to 
make the output more C-like. People who know C well apparently can see 
instantly where a function starts and ends).)

Among the calling conventions, I currently have to be aware of these:

__stdcall
__declspec(dllimport)
__attribute__ ((force_align_arg_pointer))

The last one is for call-backs from Windows, and is to do I think with 
keeping the x64 stack-pointer aligned to 16 bytes. It's only for gcc so 
uses this macro:

#ifdef __GNUC__
   #define gcc_callback __attribute__ ((force_align_arg_pointer))
#else
   #define gcc_callback
#endif

Then 'gcc_callback' is used. Since this is only for gcc, the positioning 
is not so critical.

-- 
Bartc

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

#94567

BartC <bc@freeuk.com> writes:
[...]
> Type-qualifiers seem be 'const' and 'volatile'. Trouble is I've no idea 
> where they go either! Especially in relation to functions as they 
> wouldn't make sense there.
[...]

The type qualifiers are const, restrict, volatile, and _Atomic.

The grammar permits "const", for example, on a function type:

    const int func(void);

but it's ignored.  (I think the same is true for the other type
qualifiers, but I haven't checked.)  But a function returning a
pointer-to-const is perfectly sensible:

    const int *func(void);

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

#94568

On Friday, October 7, 2016 at 3:47:54 PM UTC-3, Bart wrote:

> (On page 122 actually.) That section acknowledges that there are 
> problems and goes on to demonstrate what may be an early version of 
> Cdecl. That is, a program that converts to and from C declarations. It 
> doesn't suggest a way of making it easier for for humans! Not without 
> using some artificial aid.

Yes.. I think strange declarations should be style warnings!

int i, f(), (*f2)(), *p, a[1];
typedef int i, k;

I don't use more than one declarator in my code.

I never do this:

int i, k;

struct X
{
  int i, k;
}

This is a very simple warning to implement. 

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

#94570

Thiago Adams <thiago.adams@gmail.com> writes:
> On Friday, October 7, 2016 at 3:47:54 PM UTC-3, Bart wrote:
>
>> (On page 122 actually.) That section acknowledges that there are 
>> problems and goes on to demonstrate what may be an early version of 
>> Cdecl. That is, a program that converts to and from C declarations. It 
>> doesn't suggest a way of making it easier for for humans! Not without 
>> using some artificial aid.
>
> Yes.. I think strange declarations should be style warnings!
>
> int i, f(), (*f2)(), *p, a[1];
> typedef int i, k;
>
> I don't use more than one declarator in my code.

Not a bad policy.

> I never do this:
>
> int i, k;
>
> struct X
> {
>   int i, k;
> }

Why not?  i and k probably aren't very good names, but struct member
names are in their own namespace; there's no real opportunity to confuse
the variable i with the struct member i.

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

#94571

On Friday, October 7, 2016 at 5:10:15 PM UTC-3, Keith Thompson wrote:
> Thiago Adams  writes:
> > On Friday, October 7, 2016 at 3:47:54 PM UTC-3, Bart wrote:
> >
> >> (On page 122 actually.) That section acknowledges that there are 
> >> problems and goes on to demonstrate what may be an early version of 
> >> Cdecl. That is, a program that converts to and from C declarations. It 
> >> doesn't suggest a way of making it easier for for humans! Not without 
> >> using some artificial aid.
> >
> > Yes.. I think strange declarations should be style warnings!
> >
> > int i, f(), (*f2)(), *p, a[1];
> > typedef int i, k;
> >
> > I don't use more than one declarator in my code.
> 
> Not a bad policy.
> 
> > I never do this:
> >
> > int i, k;
> >
> > struct X
> > {
> >   int i, k;
> > }
> 
> Why not?  i and k probably aren't very good names, but struct member
> names are in their own namespace; there's no real opportunity to confuse
> the variable i with the struct member i.

The sample was not about scope..was about multiple declarators.

I think this one is not a good sample:

struct X {
  int *p, p2;
}
The style rule is: just one declarator per declaration.

To fix:
struct X {
  int *p;
  int p2;
}

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

Page 1 of 8  [1] 2 3 4 5 6 7 8  Next page →

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

csiph-web