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

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

gcc_centric C code

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

Contents

  gcc_centric C code bartc <bc@freeuk.com> - 2018-04-25 16:21 +0100
    gcc_centric C code Chad <cdalten@gmail.com> - 2018-04-25 08:34 -0700
    Re: gcc_centric C code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-04-25 16:41 +0100
      Re: gcc_centric C code Spiros Bousbouras <spibou@gmail.com> - 2018-04-25 16:19 +0000
        Re: gcc_centric C code bartc <bc@freeuk.com> - 2018-04-25 18:02 +0100
          Re: gcc_centric C code Nick Bowler <nbowler@draconx.ca> - 2018-04-25 17:15 +0000
            Re: gcc_centric C code Robert Wessel <robertwessel2@yahoo.com> - 2018-04-25 12:33 -0500
            Re: gcc_centric C code bartc <bc@freeuk.com> - 2018-04-25 20:51 +0100
              Re: gcc_centric C code supercat@casperkitty.com - 2018-04-25 13:01 -0700
                Re: gcc_centric C code bartc <bc@freeuk.com> - 2018-04-25 21:21 +0100
              Re: gcc_centric C code jameskuyper@verizon.net - 2018-04-25 13:45 -0700
          Re: gcc_centric C code Spiros Bousbouras <spibou@gmail.com> - 2018-04-25 17:20 +0000
        Re: gcc_centric C code supercat@casperkitty.com - 2018-04-25 10:30 -0700
          Re: gcc_centric C code Robert Wessel <robertwessel2@yahoo.com> - 2018-04-25 12:35 -0500
            Re: gcc_centric C code Keith Thompson <kst-u@mib.org> - 2018-04-25 10:54 -0700
              Re: gcc_centric C code Philipp Klaus Krause <pkk@spth.de> - 2018-04-25 20:27 +0200
                Re: gcc_centric C code Keith Thompson <kst-u@mib.org> - 2018-04-25 12:38 -0700
                Re: gcc_centric C code Robert Wessel <robertwessel2@yahoo.com> - 2018-04-25 19:53 -0500
                  Re: gcc_centric C code Keith Thompson <kst-u@mib.org> - 2018-04-25 18:13 -0700
                    Re: gcc_centric C code Nick Bowler <nbowler@draconx.ca> - 2018-04-26 15:16 +0000
                    Re: gcc_centric C code Tim Rentsch <txr@alumni.caltech.edu> - 2018-04-27 08:17 -0700
                  Re: gcc_centric C code Philipp Klaus Krause <pkk@spth.de> - 2018-04-26 08:03 +0200
                    Re: gcc_centric C code Nick Bowler <nbowler@draconx.ca> - 2018-04-26 14:30 +0000
                    Re: gcc_centric C code jameskuyper@verizon.net - 2018-04-26 08:26 -0700
                      Re: gcc_centric C code Philipp Klaus Krause <pkk@spth.de> - 2018-04-26 19:04 +0200
                        Re: gcc_centric C code Ian Collins <ian-news@hotmail.com> - 2018-04-27 07:48 +1200
                          Re: gcc_centric C code bartc <bc@freeuk.com> - 2018-04-26 21:08 +0100
                            Re: gcc_centric C code Ian Collins <ian-news@hotmail.com> - 2018-04-27 08:18 +1200
                              Re: gcc_centric C code bartc <bc@freeuk.com> - 2018-04-26 21:44 +0100
                                Re: gcc_centric C code Ian Collins <ian-news@hotmail.com> - 2018-04-27 09:01 +1200
                                  Re: gcc_centric C code bartc <bc@freeuk.com> - 2018-04-26 23:16 +0100
                                    Re: gcc_centric C code Ian Collins <ian-news@hotmail.com> - 2018-04-27 10:27 +1200
                                      Re: gcc_centric C code bartc <bc@freeuk.com> - 2018-04-26 23:48 +0100
                                        Re: gcc_centric C code Ian Collins <ian-news@hotmail.com> - 2018-04-27 20:41 +1200
                                          Re: gcc_centric C code bartc <bc@freeuk.com> - 2018-04-27 11:51 +0100
                                            Re: gcc_centric C code Ian Collins <ian-news@hotmail.com> - 2018-04-28 07:32 +1200
                                            Re: gcc_centric C code Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-28 04:34 -0700
                                      Re: gcc_centric C code Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-26 23:05 -0700
                                    Re: gcc_centric C code jacobnavia <jacob@jacob.remcomp.fr> - 2018-04-27 00:52 +0200
                                      Re: gcc_centric C code supercat@casperkitty.com - 2018-04-26 16:23 -0700
                                        Re: gcc_centric C code bartc <bc@freeuk.com> - 2018-04-28 11:24 +0100
                                      Re: gcc_centric C code bartc <bc@freeuk.com> - 2018-04-28 01:42 +0100
                                Re: gcc_centric C code Dan Purgert <dan@djph.net> - 2018-04-26 21:40 +0000
                                  Re: gcc_centric C code bartc <bc@freeuk.com> - 2018-04-26 23:34 +0100
                              Re: gcc_centric C code "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-04-26 14:13 -0700
                                Re: gcc_centric C code "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid> - 2018-04-26 14:16 -0700
              Re: gcc_centric C code Tim Rentsch <txr@alumni.caltech.edu> - 2018-04-27 08:08 -0700
                Re: gcc_centric C code Keith Thompson <kst-u@mib.org> - 2018-04-27 09:11 -0700
                  Re: gcc_centric C code supercat@casperkitty.com - 2018-04-27 09:26 -0700
                  Re: gcc_centric C code Tim Rentsch <txr@alumni.caltech.edu> - 2018-04-27 09:49 -0700
            Re: gcc_centric C code supercat@casperkitty.com - 2018-04-25 12:31 -0700
              Re: gcc_centric C code Nick Bowler <nbowler@draconx.ca> - 2018-04-25 20:13 +0000
                Re: gcc_centric C code supercat@casperkitty.com - 2018-04-25 13:50 -0700
          Re: gcc_centric C code Nick Bowler <nbowler@draconx.ca> - 2018-04-25 18:02 +0000
        Re: gcc_centric C code Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-25 22:39 -0700
      Re: gcc_centric C code bartc <bc@freeuk.com> - 2018-04-25 18:36 +0100
        Re: gcc_centric C code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-04-25 23:15 +0100
          Re: gcc_centric C code bartc <bc@freeuk.com> - 2018-04-26 02:02 +0100
            Re: gcc_centric C code Keith Thompson <kst-u@mib.org> - 2018-04-25 18:28 -0700
            Re: gcc_centric C code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-04-26 11:45 +0100
              Re: gcc_centric C code bartc <bc@freeuk.com> - 2018-04-26 14:53 +0100
                Re: gcc_centric C code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-04-26 23:38 +0100
                  Re: gcc_centric C code bartc <bc@freeuk.com> - 2018-04-27 00:31 +0100
                    Re: gcc_centric C code Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-04-27 00:47 +0100
                      Re: gcc_centric C code bartc <bc@freeuk.com> - 2018-04-27 02:28 +0100
                      Re: gcc_centric C code Thiago Adams <thiago.adams@gmail.com> - 2018-04-27 03:44 -0700
                        Re: gcc_centric C code bartc <bc@freeuk.com> - 2018-05-03 13:57 +0100
                          Re: gcc_centric C code Thiago Adams <thiago.adams@gmail.com> - 2018-05-03 11:02 -0700
                            Re: gcc_centric C code Thiago Adams <thiago.adams@gmail.com> - 2018-05-03 11:07 -0700
                            Re: gcc_centric C code Steven Petruzzellis <frelwizzen@gmail.com> - 2018-05-03 11:13 -0700
                            Re: gcc_centric C code bartc <bc@freeuk.com> - 2018-05-03 19:50 +0100
                              Re: gcc_centric C code Thiago Adams <thiago.adams@gmail.com> - 2018-05-03 13:37 -0700
                                Re: gcc_centric C code Thiago Adams <thiago.adams@gmail.com> - 2018-05-03 13:44 -0700
                                  Re: gcc_centric C code Thiago Adams <thiago.adams@gmail.com> - 2018-05-11 10:25 -0700
              Re: gcc_centric C code Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-26 07:01 -0700
            Re: Clearly everyone else likes to do things the hard way Noob <root@127.0.0.1> - 2018-04-26 14:51 +0200
              Re: Clearly everyone else likes to do things the hard way mark.bluemel@gmail.com - 2018-04-26 07:09 -0700
                Re: Clearly everyone else likes to do things the hard way gazelle@shell.xmission.com (Kenny McCormack) - 2018-04-26 17:05 +0000
                  Re: Clearly everyone else likes to do things the hard way bartc <bc@freeuk.com> - 2018-04-26 18:38 +0100
                    Re: Clearly everyone else likes to do things the hard way 1alvinalbrecht1@gmail.com - 2018-04-26 11:34 -0700
                      Re: Clearly everyone else likes to do things the hard way bartc <bc@freeuk.com> - 2018-04-26 21:36 +0100
                        Re: Clearly everyone else likes to do things the hard way C W Rose <cwr@seckford.org> - 2018-04-27 19:23 +0100
                          Re: Clearly everyone else likes to do things the hard way bartc <bc@freeuk.com> - 2018-04-28 14:34 +0100
                            Re: Clearly everyone else likes to do things the hard way Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-28 10:32 -0700
                            Re: Clearly everyone else likes to do things the hard way supercat@casperkitty.com - 2018-04-30 10:16 -0700
                              Re: Clearly everyone else likes to do things the hard way bartc <bc@freeuk.com> - 2018-04-30 19:41 +0100
                                Re: Clearly everyone else likes to do things the hard way supercat@casperkitty.com - 2018-04-30 12:11 -0700
                                  Re: Clearly everyone else likes to do things the hard way scott@slp53.sl.home (Scott Lurndal) - 2018-04-30 19:14 +0000
                                Re: Clearly everyone else likes to do things the hard way scott@slp53.sl.home (Scott Lurndal) - 2018-04-30 19:12 +0000
                                  Re: Clearly everyone else likes to do things the hard way bartc <bc@freeuk.com> - 2018-04-30 21:19 +0100
                                Re: Clearly everyone else likes to do things the hard way Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-30 19:23 -0700
                  Re: Clearly everyone else likes to do things the hard way Philipp Klaus Krause <pkk@spth.de> - 2018-04-26 19:45 +0200
        Re: gcc_centric C code luser droog <luser.droog@gmail.com> - 2018-04-25 21:56 -0700
          Re: gcc_centric C code bartc <bc@freeuk.com> - 2018-04-26 11:06 +0100
            Re: gcc_centric C code bartc <bc@freeuk.com> - 2018-04-26 11:27 +0100
        Re: gcc_centric C code antispam@math.uni.wroc.pl - 2018-04-26 17:00 +0000
    Re: gcc_centric C code Thiago Adams <thiago.adams@gmail.com> - 2018-04-25 09:26 -0700
    Re: gcc_centric C code Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-04-26 12:39 +0000
      Re: gcc_centric C code gazelle@shell.xmission.com (Kenny McCormack) - 2018-04-26 13:09 +0000
    Re: gcc_centric C code Wouter Verhelst <w@uter.be> - 2018-04-26 13:26 +0200
      Re: gcc_centric C code bartc <bc@freeuk.com> - 2018-04-26 18:03 +0100
      Re: gcc_centric C code Steven Petruzzellis <frelwizzen@gmail.com> - 2018-04-26 14:32 -0700
    Re: gcc_centric C code Tim Rentsch <txr@alumni.caltech.edu> - 2018-04-27 09:41 -0700
      Re: gcc_centric C code bartc <bc@freeuk.com> - 2018-04-27 19:37 +0100

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

#129717 — gcc_centric C code

These are some observations about the difficulties of getting C source 
code to compile, if you try and do it outside the confines of a 
preferred compiler and build system.

I took one github C project and tried to compile all the 48 C files in 
one subdirectory, but without using makefiles or taking any config 
steps. These are the results trying various Windows C compilers:

gcc            47 files compiled successfully out of 48
Tiny C         40 files
Pelles C       32 files
lccwin         17 files
DMC            24 files
MSVC           38 files
bcc (mine)     36 files (after disabling a code-gen bug)

The one problem file for gcc was a missing header that I couldn't find 
anywhere.

Now, maybe this needs to have some configuration to build some config.h 
which will magically make it all work, or maybe not all files are 
relevant for a particular config.

But if you are using a very non-mainstream and bare compiler like mine, 
then that is unlikely to make a difference.

The fact is, that even after bunches of #ifdefs to cater for GNUC and 
MSCVER and whatever, there are still difficulties in getting code to 
compile.

Among the problems I had to solve to get to my 36/48, was the use of 
__func__, something that doesn't seem to be in the C standard, and 
appears to be a predefined macro to give the current function name. OK, 
I had to implement that (but how many dozens of such ad-hoc extensions 
are there?).

Another, was not recognising 'size_t', which was due to a block of code 
like this:

#ifdef STDC_HEADERS
# include <stdlib.h>
# include <stddef.h>
#else
# ifdef HAVE_STDLIB_H
#  include <stdlib.h>
# endif
#endif

#ifdef HAVE_ALLOCA_H
# include <alloca.h>
#elif !defined alloca
# ifdef __GNUC__
#  define alloca __builtin_alloca
# elif defined _AIX
#  define alloca __alloca
# elif defined _MSC_VER
#  include <malloc.h>
#  define alloca _alloca
# elif !defined HAVE_ALLOCA
#  ifdef  __cplusplus
extern "C"
#  endif
void *alloca (size_t);
# endif
#endif

---------------
The problem was that alloca() declaration, that uses size_t, because the 
needed headers are included after this code. This doesn't affect gcc or 
MSVC because they have their own #elif blocks so this isn't seen.

All this I find quite typical of open source C code. It is 
soul-destroying if you're trying to get an implementation to work, and 
that fact that other compilers including MVSC can also have problems, is 
not much comfort.

(And for that reason, I'm retiring my C compiler for use with existing C 
projects as it would be a never-ending task. It will be for new code.)

-- 
bartc

[toc] | [next] | [standalone]

#129718

Dunno if this relates to anything, but the late Dr. Jan Wolters pulled some magic to get around this. In particular, what he did was have a program automatically generate system specific C code before it got compiled on the target system. 

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

#129720

bartc <bc@freeuk.com> writes:

> I took one github C project

Which one?

> and tried to compile all the 48 C files in
> one subdirectory, but without using makefiles or taking any config
> steps. These are the results trying various Windows C compilers:

Does the project have a makefile and/or configuration script?  If it
does, what do you think your data shows?

> gcc            47 files compiled successfully out of 48
> Tiny C         40 files
> Pelles C       32 files
> lccwin         17 files
> DMC            24 files
> MSVC           38 files
> bcc (mine)     36 files (after disabling a code-gen bug)

All with no flags, presumably?  (But I should not have to guess.)

> The one problem file for gcc was a missing header that I couldn't find
> anywhere.

Why do you want to keep it secret?

> Now, maybe this needs to have some configuration to build some
> config.h which will magically make it all work, or maybe not all files
> are relevant for a particular config.

That may be.  Why won't you let anyone know?

> Among the problems I had to solve to get to my 36/48, was the use of
> __func__, something that doesn't seem to be in the C standard

It is -- since C99, I think.  But you might be calling one or more
compiler in a mode which does not include any C99 features.

> , and
> appears to be a predefined macro to give the current function
> name. OK, I had to implement that (but how many dozens of such ad-hoc
> extensions are there?).

It's standard C.

-- 
Ben.

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

#129722

On Wed, 25 Apr 2018 16:41:37 +0100
Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> bartc <bc@freeuk.com> writes:
> > Among the problems I had to solve to get to my 36/48, was the use of
> > __func__, something that doesn't seem to be in the C standard
> 
> It is -- since C99, I think.

Yes and I use it all the time for error messages. But it's not a macro ,
it's an identifier :

  6.4.2.2 Predefined identifiers
  Semantics

    1 The identifier __func__ shall be implicitly declared by the
      translator as if, immediately following the opening brace of each
      function definition, the declaration
             static const char __func__[] = "function-name";
      appeared, where function-name is the name of the lexically-enclosing
      function.61)

    2 This name is encoded as if the implicit declaration had been written
      in the source character set and then translated into the execution
      character set as indicated in translation phase 5.

> But you might be calling one or more
> compiler in a mode which does not include any C99 features.
> 
> > , and
> > appears to be a predefined macro to give the current function
> > name. OK, I had to implement that (but how many dozens of such ad-hoc
> > extensions are there?).
> 
> It's standard C.

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

#129727

On 25/04/2018 17:19, Spiros Bousbouras wrote:
> On Wed, 25 Apr 2018 16:41:37 +0100
> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>> bartc <bc@freeuk.com> writes:
>>> Among the problems I had to solve to get to my 36/48, was the use of
>>> __func__, something that doesn't seem to be in the C standard
>>
>> It is -- since C99, I think.
> 
> Yes and I use it all the time for error messages. But it's not a macro ,
> it's an identifier :
> 
>    6.4.2.2 Predefined identifiers
>    Semantics
> 
>      1 The identifier __func__ shall be implicitly declared by the

Strangely, if I do a search for __func__ in a PDF of the C standard, it 
can't find it, even if positioned just before it.

The underscore character used seems be that different from that typed 
into the search box via the keyboard, perhaps a special typographical 
version.

That it wasn't in the list of predefined macros either made it rather 
hard to find.

-- 
bartc

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

#129729

On Wed, 25 Apr 2018 18:02:03 +0100, bartc wrote:
> Strangely, if I do a search for __func__ in a PDF of the C standard, it 
> can't find it, even if positioned just before it.

The PDF search in files like n1570.pdf is not very great.  Consecutive
underscores never show up in search results.  You can often simplify
the search query to find things; for example, searching for _func_
should locate relevant text successfully.

> The underscore character used seems be that different from that typed 
> into the search box via the keyboard, perhaps a special typographical 
> version.

The underscores are not different, but there is a space between them in
the searchable text, probably an artifact of how the document was typeset.
(the same thing happens if you copy+paste from the document).

> That it wasn't in the list of predefined macros either made it rather 
> hard to find.

No kidding, because it's not a macro, let alone a predefined one.
Of course it's not in the list of predefined macros.

The standard has a proper index.  You should use it, and you will find
__func__ in it easily.

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

#129732

On Wed, 25 Apr 2018 17:15:31 -0000 (UTC), Nick Bowler
<nbowler@draconx.ca> wrote:

>On Wed, 25 Apr 2018 18:02:03 +0100, bartc wrote:
>> Strangely, if I do a search for __func__ in a PDF of the C standard, it 
>> can't find it, even if positioned just before it.
>
>The PDF search in files like n1570.pdf is not very great.  Consecutive
>underscores never show up in search results.  You can often simplify
>the search query to find things; for example, searching for _func_
>should locate relevant text successfully.


Presumably because in almost all typefaces, consecutive underscores
will join together, and make a single longer line.  The space is there
to make the one vs. two underscore distinction clear.  And obviously
there are other ways to skin that cat, although none of them quite as
easy as an extra space.  Yes, it does have an annoying impact on
searches, especially with Acrobat (other PDF readers have search
engines that do rather better).

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

#129743

On 25/04/2018 18:15, Nick Bowler wrote:
> On Wed, 25 Apr 2018 18:02:03 +0100, bartc wrote:
>> Strangely, if I do a search for __func__ in a PDF of the C standard, it
>> can't find it, even if positioned just before it.
> 
> The PDF search in files like n1570.pdf is not very great.  Consecutive
> underscores never show up in search results.  You can often simplify
> the search query to find things; for example, searching for _func_
> should locate relevant text successfully.
> 
>> The underscore character used seems be that different from that typed
>> into the search box via the keyboard, perhaps a special typographical
>> version.
> 
> The underscores are not different, but there is a space between them in
> the searchable text, probably an artifact of how the document was typeset.
> (the same thing happens if you copy+paste from the document).
> 
>> That it wasn't in the list of predefined macros either made it rather
>> hard to find.
> 
> No kidding, because it's not a macro, let alone a predefined one.
> Of course it's not in the list of predefined macros.

If you've never seen it before, but it looks and behaves just a like a 
predefined macro apart from being lower case, why would you even 
consider that it might be something else?

(And actually, why WASN'T it a macro?)

> The standard has a proper index.  You should use it, and you will find
> __func__ in it easily.

Hmm, the index is 25 pages and you have to navigate there first; yet 
you're using a computer with a text search function to read the file; 
why would you bother with the index as a start point?

If you don't KNOW that there's a bug in the search function, and it 
can't find __func__ anywhere in the file, why would you think you might 
have better luck with the index?

-- 
bartc

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

#129744

On Wednesday, April 25, 2018 at 2:51:52 PM UTC-5, Bart wrote:
> If you've never seen it before, but it looks and behaves just a like a 
> predefined macro apart from being lower case, why would you even 
> consider that it might be something else?
> 
> (And actually, why WASN'T it a macro?)

It can't be a *macro*--at least not one that expands to a string literal--
because the preprocessor knows nothing about function boundaries.  It
could have been a reserved word token which behaves like a quoted string
literal, but is processed by the compiler rather than the preprocessor,
but doing that would have made the construct harder to describe (even if
it would make it more useful and be unlikely to cause any real problems
with implementations).

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

#129746

On 25/04/2018 21:01, supercat@casperkitty.com wrote:
> On Wednesday, April 25, 2018 at 2:51:52 PM UTC-5, Bart wrote:
>> If you've never seen it before, but it looks and behaves just a like a
>> predefined macro apart from being lower case, why would you even
>> consider that it might be something else?
>>
>> (And actually, why WASN'T it a macro?)
> 
> It can't be a *macro*--at least not one that expands to a string literal--
> because the preprocessor knows nothing about function boundaries.

Oh, OK.

My implementation treats it as a predefined macro (as the mechanism for 
those was in place), and the preprocessor knows about functions as 
tokenising, preprocessing and parsing are done in near-parallel).

-- 
bartc

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

#129747

On Wednesday, April 25, 2018 at 3:51:52 PM UTC-4, Bart wrote:
> On 25/04/2018 18:15, Nick Bowler wrote:
> > On Wed, 25 Apr 2018 18:02:03 +0100, bartc wrote:
> >> Strangely, if I do a search for __func__ in a PDF of the C standard, it
> >> can't find it, even if positioned just before it.
...
> >> The underscore character used seems be that different from that typed
> >> into the search box via the keyboard, perhaps a special typographical
> >> version.
> > 
> > The underscores are not different, but there is a space between them in
> > the searchable text, probably an artifact of how the document was typeset.
> > (the same thing happens if you copy+paste from the document).
> > 
> >> That it wasn't in the list of predefined macros either made it rather
> >> hard to find.
> > 
> > No kidding, because it's not a macro, let alone a predefined one.
> > Of course it's not in the list of predefined macros.
> 
> If you've never seen it before, but it looks and behaves just a like a 
> predefined macro apart from being lower case, why would you even 
> consider that it might be something else?

It doesn't look like a macro to me. The C language itself provides no
way of distinguishing, just by looking at an identifier, whether it
identifies "an object; a function; a tag or a member of a structure,
union, or enumeration; a typedef name; a label name; a macro name; or a
macro parameter" (6.2.1p1).
However, the common convention is that macros are all uppercase (a
convention which is occasionally violated by the standard itself, partly
because the standard predates that convention). __func__ doesn't fit that
convention, and was invented after that convention became conventional.

Also, it doesn't work like a predefined macro. It get replaced with a 0
if it occurs in a #if statement, it doesn't trigger #ifdef, it does
trigger #ifndef (unless a macro with the same name is #defined). It
doesn't undergo string concatenation the way a string macro would.
However, I will concede the point that if you don't know what it was,
you might not know enough about any of those points to rule out the
possibility that it could be a macro. However, if you know that little
about it, you should also not rule out the possibility that it's not a
macro.

> (And actually, why WASN'T it a macro?)

Because macros disappear during translation phase 4, having been
replaced by their expansions (6.10.3), or used in pre-processing
directives that are deleted at the end of phase 4 (5.1.1.2p4). Function
definitions cannot be reliably identified as such until the parsing that
occurs during translation phase 7, partly because the code
rearrangements that are allowed during translation phase 4 can affect
whether or not something is parsed as a function definition.

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

#129730

On Wed, 25 Apr 2018 18:02:03 +0100
bartc <bc@freeuk.com> wrote:
> On 25/04/2018 17:19, Spiros Bousbouras wrote:
> > On Wed, 25 Apr 2018 16:41:37 +0100
> > Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> >> bartc <bc@freeuk.com> writes:
> >>> Among the problems I had to solve to get to my 36/48, was the use of
> >>> __func__, something that doesn't seem to be in the C standard
> >>
> >> It is -- since C99, I think.
> > 
> > Yes and I use it all the time for error messages. But it's not a macro ,
> > it's an identifier :
> > 
> >    6.4.2.2 Predefined identifiers
> >    Semantics
> > 
> >      1 The identifier __func__ shall be implicitly declared by the
> 
> Strangely, if I do a search for __func__ in a PDF of the C standard, it 
> can't find it, even if positioned just before it.

Same for me ; but I knew it was there so I went to the index to see where
in the text appears. I don't know if it's a problem with the PDF file or
with my reader. It happens every now and again with other strings (I don't
remember specific examples) so if I want to be sure whether something is
in the standard or not , I go to the index.

> The underscore character used seems be that different from that typed 
> into the search box via the keyboard, perhaps a special typographical 
> version.
> 
> That it wasn't in the list of predefined macros either made it rather 
> hard to find.

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

#129731

On Wednesday, April 25, 2018 at 11:19:27 AM UTC-5, Spiros Bousbouras wrote:
> Yes and I use it all the time for error messages. But it's not a macro ,
> it's an identifier :
> 
>   6.4.2.2 Predefined identifiers
>   Semantics
> 
>     1 The identifier __func__ shall be implicitly declared by the
>       translator as if, immediately following the opening brace of each
>       function definition, the declaration
>              static const char __func__[] = "function-name";
>       appeared, where function-name is the name of the lexically-enclosing
>       function.61)
> 
>     2 This name is encoded as if the implicit declaration had been written
>       in the source character set and then translated into the execution
>       character set as indicated in translation phase 5.

I wonder if there's any particular advantage to doing that, versus saying
having it be a token which behaves like a string literal?  Being able to
combine the other built-ins that yield strings, e.g.

    const char build_info[] = "Version 1.3 " __DATE__ " " __TIME__;

is certainly useful, and I see no reason that giving __func__ such
abilities would not be similarly useful.

Would having __func__ be a token that behaves like a quoted string literal
cause any "translation phase" issue?

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

#129733

On Wed, 25 Apr 2018 10:30:03 -0700 (PDT), supercat@casperkitty.com
wrote:

>On Wednesday, April 25, 2018 at 11:19:27 AM UTC-5, Spiros Bousbouras wrote:
>> Yes and I use it all the time for error messages. But it's not a macro ,
>> it's an identifier :
>> 
>>   6.4.2.2 Predefined identifiers
>>   Semantics
>> 
>>     1 The identifier __func__ shall be implicitly declared by the
>>       translator as if, immediately following the opening brace of each
>>       function definition, the declaration
>>              static const char __func__[] = "function-name";
>>       appeared, where function-name is the name of the lexically-enclosing
>>       function.61)
>> 
>>     2 This name is encoded as if the implicit declaration had been written
>>       in the source character set and then translated into the execution
>>       character set as indicated in translation phase 5.
>
>I wonder if there's any particular advantage to doing that, versus saying
>having it be a token which behaves like a string literal?  Being able to
>combine the other built-ins that yield strings, e.g.
>
>    const char build_info[] = "Version 1.3 " __DATE__ " " __TIME__;
>
>is certainly useful, and I see no reason that giving __func__ such
>abilities would not be similarly useful.
>
>Would having __func__ be a token that behaves like a quoted string literal
>cause any "translation phase" issue?


Yes, expanding those macros and the concatenation of adjacent string
literals happens long before the boundaries of functions are
determined.

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

#129736

Robert Wessel <robertwessel2@yahoo.com> writes:
> On Wed, 25 Apr 2018 10:30:03 -0700 (PDT), supercat@casperkitty.com
> wrote:
>>On Wednesday, April 25, 2018 at 11:19:27 AM UTC-5, Spiros Bousbouras wrote:
>>> Yes and I use it all the time for error messages. But it's not a macro ,
>>> it's an identifier :
>>> 
>>>   6.4.2.2 Predefined identifiers
>>>   Semantics
>>> 
>>>     1 The identifier __func__ shall be implicitly declared by the
>>>       translator as if, immediately following the opening brace of each
>>>       function definition, the declaration
>>>              static const char __func__[] = "function-name";
>>>       appeared, where function-name is the name of the lexically-enclosing
>>>       function.61)
>>> 
>>>     2 This name is encoded as if the implicit declaration had been written
>>>       in the source character set and then translated into the execution
>>>       character set as indicated in translation phase 5.
>>
>>I wonder if there's any particular advantage to doing that, versus saying
>>having it be a token which behaves like a string literal?  Being able to
>>combine the other built-ins that yield strings, e.g.
>>
>>    const char build_info[] = "Version 1.3 " __DATE__ " " __TIME__;
>>
>>is certainly useful, and I see no reason that giving __func__ such
>>abilities would not be similarly useful.
>>
>>Would having __func__ be a token that behaves like a quoted string literal
>>cause any "translation phase" issue?
>
> Yes, expanding those macros and the concatenation of adjacent string
> literals happens long before the boundaries of functions are
> determined.

A very minor point: values yielded by __func__ can be compared for
pointer equality.  (I've never seen code that relies on this.)

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

#129738

Am 25.04.2018 um 19:54 schrieb Keith Thompson:
> 
> A very minor point: values yielded by __func__ can be compared for
> pointer equality.  (I've never seen code that relies on this.)
> 

The interaction of that with inline is problematic.

Philipp

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

#129742

Philipp Klaus Krause <pkk@spth.de> writes:
> Am 25.04.2018 um 19:54 schrieb Keith Thompson:
>> A very minor point: values yielded by __func__ can be compared for
>> pointer equality.  (I've never seen code that relies on this.)
>
> The interaction of that with inline is problematic.

Good point.  (That applies to more generally to any static objects
defined within a function definition.)

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

#129759

On Wed, 25 Apr 2018 20:27:32 +0200, Philipp Klaus Krause <pkk@spth.de>
wrote:

>Am 25.04.2018 um 19:54 schrieb Keith Thompson:
>> 
>> A very minor point: values yielded by __func__ can be compared for
>> pointer equality.  (I've never seen code that relies on this.)
>> 
>
>The interaction of that with inline is problematic.


Why?  Why should it be any different than any inlined function that
contains a static data item?  All inlined copies, as well as a
separately built copy (assuming it exists) would use the same (static)
item.

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

#129761

Robert Wessel <robertwessel2@yahoo.com> writes:
> On Wed, 25 Apr 2018 20:27:32 +0200, Philipp Klaus Krause <pkk@spth.de>
> wrote:
>>Am 25.04.2018 um 19:54 schrieb Keith Thompson:
>>> 
>>> A very minor point: values yielded by __func__ can be compared for
>>> pointer equality.  (I've never seen code that relies on this.)
>>> 
>>
>>The interaction of that with inline is problematic.
>
> Why?  Why should it be any different than any inlined function that
> contains a static data item?  All inlined copies, as well as a
> separately built copy (assuming it exists) would use the same (static)
> item.

N1570 6.7.4p7:

    Any function with internal linkage can be an inline function. For a
    function with external linkage, the following restrictions apply:
    [snip]
    It is unspecified whether a call to the function uses the inline
    definition or the external definition.

with a footnote:

    Since an inline definition is distinct from the corresponding
    external definition and from any other corresponding inline
    definitions in other translation units, all corresponding objects
    with static storage duration are also distinct in each of the
    definitions.

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

#129794

On Wed, 25 Apr 2018 18:13:10 -0700, Keith Thompson wrote:

> Robert Wessel <robertwessel2@yahoo.com> writes:
>> On Wed, 25 Apr 2018 20:27:32 +0200, Philipp Klaus Krause <pkk@spth.de>
>> wrote:
>>>Am 25.04.2018 um 19:54 schrieb Keith Thompson:
>>>> 
>>>> A very minor point: values yielded by __func__ can be compared for
>>>> pointer equality.  (I've never seen code that relies on this.)
>>>> 
>>>
>>>The interaction of that with inline is problematic.
>>
>> Why?  Why should it be any different than any inlined function that
>> contains a static data item?  All inlined copies, as well as a
>> separately built copy (assuming it exists) would use the same (static)
>> item.
> 
> N1570 6.7.4p7:
> 
>     Any function with internal linkage can be an inline function. For a
>     function with external linkage, the following restrictions apply:
>     [snip]
>     It is unspecified whether a call to the function uses the inline
>     definition or the external definition.

Just to note that "inline definition" is a special case of inline
function (which is described in the snipped section). This last
sentence does not apply generally to all kinds of inline functions.

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

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

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

csiph-web