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

#129888

On 27/04/2018 00:23, supercat@casperkitty.com wrote:
> On Thursday, April 26, 2018 at 5:52:45 PM UTC-5, jacobnavia wrote:
>> Using Microsoft system is problematic, as you see, you can't do that on
>> windows.
> 
> I don't think Windows is unique.  Really, the problem is that a lot of
> programs aren't really written in C--they're written in Unix's combination
> of C, scripts, etc.

This is the point that I often try and get across but have consistently 
failed. A project purportedly written in C may have very heavy 
dependencies on:

   C macro language and other preprocessor stuff
   C compiler options
   Makefile syntax
   Bash scripts
   M4 (which I keep seeing)
   A dozen other Unix utilities and commands using /their/ syntax

The pure C code is almost incidental. My C projects have been at least 
99% pure C and required only a C compiler and linker.

(That the application may itself use OS-specific features is a separate 
level of dependency with different solutions, if the app is intended to 
be cross-platform.)


> If a command-line application doesn't do anything not supported by the
> Standard library, why shouldn't it be written to "just work" on pretty
> much any machine that supports 8/16/32/64-bit numeric types, rather than
> only on Unix machines?

All of the bigger programs I'm active with at the moment are effectively 
command-line language tools (Three compilers, one assembler/linker, one 
interpreter.)

OS-neutral versions of those are possible, with some loss of 
functionality, but otherwise the minor differences between Windows and 
Linux, perhaps 3% of all the source code are sequestered into a single 
module. Either the Windows or Linux module is plugged in to the rest of 
the app.

And, funnily enough, pretty much all open source "C" projects I've tried 
to build are very similar. Except that they feel the need to have these 
horrendous Unix-centric build systems (considerably worse than being 
merely gcc-centric).

(And just as bad as Unix build systems is when they provide separate 
Windows solutions based on Visual Studio, which rarely if ever work.)

-- 
bartc

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

#129882

On 26/04/2018 23:52, jacobnavia wrote:
> Le 27/04/2018 à 00:16, bartc a écrit :

> Bart has PROVED that trying to compile Unix software will not work on 
> windows "as is"...

No, this is software that is cross-platform and supposed to build on 
Windows. It is the build systems used that work poorly or not at all on 
Windows. Which is why much simpler build instructions - on top of the 
complex ones if necessary - could be a tremendous help.

Typically, the vital information needed to build manually is not present 
and exists only in scripts and makefiles.

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

#129825

bartc wrote:
> [...]
> Anyway I don't care about other people's gigantic projects; they can use 
> whatever systems they like.
>
> I care about the ones /I/ want to build where this stuff is forced down 
> my throat.

Wait, didn't this thread start with you downloading someone else's
project?

Their project, their choices.


-- 
|_|O|_| Registered Linux user #585947
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: 05CA 9A50 3F2E 1335 4DC5  4AEE 8E11 DDF3 1279 A281

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

#129828

On 26/04/2018 22:40, Dan Purgert wrote:
> bartc wrote:
>> [...]
>> Anyway I don't care about other people's gigantic projects; they can use
>> whatever systems they like.
>>
>> I care about the ones /I/ want to build where this stuff is forced down
>> my throat.
> 
> Wait, didn't this thread start with you downloading someone else's
> project?
> 
> Their project, their choices.

Open source project.

I wanted to use the GMP numeric library a few years back. Binary dlls 
for Windows were elusive. But the source bundle for gmp went down 
exactly this path of configure files and the rest.

I expended considerable efforts following the exact recommendations to 
build this on Windows (download MSYS etc etc). It didn't work. And I 
never managed to produce a .dll.

The configuration script for that - remember this just decides what 
macros to give to the compiler - was 30,000 lines (it would take a whole 
ream of paper printed out). It would be a laugh if all I needed was 
three macros and to then compile half a dozen modules.

So, I wasn't able to use gmp as I didn't want to have an such an erratic 
dependency in my programs.

With my work I use all sorts of crappy tools of my own to get my 
development done. But I would not inflict them on anyone else. If the 
requirement is simply to get a working binary, then that should be made 
as straightforward and streamlined and problem-free as possible.

And actually, now I just give out binaries. People have actually 
complained that my one-file sources are too hard to build. I've reduced 
the job of installing a new kitchen to hammering in one nail, but people 
have apparently forgotten how to use a hammer.

Or they just didn't want to acknowledge that it was, actually, quite 
something.

-- 
bartc

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

#129822

On 4/26/2018 1:18 PM, Ian Collins wrote:
> On 04/27/2018 08:08 AM, bartc wrote:
>> On 26/04/2018 20:48, Ian Collins wrote:
>>> On 04/27/2018 05:04 AM, Philipp Klaus Krause wrote:
>>>> On 26/04/2018 12:26, Wouter Verhelst wrote:
>>>>> On 25-04-18 17:21, bartc wrote:
>>>>
>>>>>> All this I find quite typical of open source C code.
>>>>>
>>>>> IME, provided your compiler is recognized by autoconf (which generates
>>>>> the configure script),
>>>>
>>>> My private compiler won't be. But why should it; it's just C code,
>>>> right? The whole point of everyone writing in a standardised 
>>>> language is
>>>> so that you can apply any C compiler to any program.
>>>
>>> Why wouldn't it be recognised?  Autoconf just uses the compiler (which
>>> you can identify with "CC=<your compiler>" to compile test code 
>>> snippets.
>>
>> If I look at the 18,322-line configure file for CPython in github, then
>> there are hundreds of references to gcc, a lighter sprinkling of icc,
>> but remarkably few references to my compiler.
> 
> Did you actually read what I wrote?  How do you think I ported numerous 
> Linux centric open source projects to Solaris building with Sun's 
> compilers?
> 

Remember back when I had to port a lot of my x86 atomics over to 
Solaris. Btw, gotta love the <atomic.h> header. ;^)

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

#129823

On 4/26/2018 2:13 PM, Chris M. Thomasson wrote:
> On 4/26/2018 1:18 PM, Ian Collins wrote:
>> On 04/27/2018 08:08 AM, bartc wrote:
>>> On 26/04/2018 20:48, Ian Collins wrote:
>>>> On 04/27/2018 05:04 AM, Philipp Klaus Krause wrote:
>>>>> On 26/04/2018 12:26, Wouter Verhelst wrote:
>>>>>> On 25-04-18 17:21, bartc wrote:
>>>>>
>>>>>>> All this I find quite typical of open source C code.
>>>>>>
>>>>>> IME, provided your compiler is recognized by autoconf (which 
>>>>>> generates
>>>>>> the configure script),
>>>>>
>>>>> My private compiler won't be. But why should it; it's just C code,
>>>>> right? The whole point of everyone writing in a standardised 
>>>>> language is
>>>>> so that you can apply any C compiler to any program.
>>>>
>>>> Why wouldn't it be recognised?  Autoconf just uses the compiler (which
>>>> you can identify with "CC=<your compiler>" to compile test code 
>>>> snippets.
>>>
>>> If I look at the 18,322-line configure file for CPython in github, then
>>> there are hundreds of references to gcc, a lighter sprinkling of icc,
>>> but remarkably few references to my compiler.
>>
>> Did you actually read what I wrote?  How do you think I ported 
>> numerous Linux centric open source projects to Solaris building with 
>> Sun's compilers?
>>
> 
> Remember back when I had to port a lot of my x86 atomics over to 
> Solaris. Btw, gotta love the <atomic.h> header. ;^)
> 
> 


https://docs.oracle.com/cd/E19253-01/816-5168/atomic-ops-3c/index.html

https://docs.oracle.com/cd/E19253-01/816-5168/membar-ops-3c/index.html

They saved me from having to hand code some ops in SPARC assembly, on a 
SunFire T2000.

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

#129855

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

> Robert Wessel <robertwessel2@yahoo.com> writes:
>
>> [contrasting __func__ and string-literal predefined macros]
>
> A very minor point:  values yielded by __func__ can be compared for
> pointer equality.

So can values of string-literal predefined macros.

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

#129858

Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> Robert Wessel <robertwessel2@yahoo.com> writes:
>>> [contrasting __func__ and string-literal predefined macros]
>>
>> A very minor point:  values yielded by __func__ can be compared for
>> pointer equality.
>
> So can values of string-literal predefined macros.

Can be *meaningfully* compared.  This:

    printf("%d\n", __FILE__ == __FILE__);

could print either 0 or 1.  The value of __func__ for a given
non-inline function is always the same.

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

#129859

On Friday, April 27, 2018 at 11:12:04 AM UTC-5, Keith Thompson wrote:
> Tim Rentsch <txr@alumni.caltech.edu> writes:
> > Keith Thompson <kst-u@mib.org> writes:
> >> Robert Wessel <robertwessel2@yahoo.com> writes:
> >>> [contrasting __func__ and string-literal predefined macros]
> >>
> >> A very minor point:  values yielded by __func__ can be compared for
> >> pointer equality.
> >
> > So can values of string-literal predefined macros.
> 
> Can be *meaningfully* compared.  This:
> 
>     printf("%d\n", __FILE__ == __FILE__);
> 
> could print either 0 or 1.  The value of __func__ for a given
> non-inline function is always the same.

Would moving string concatenation from the preprocessor to the compiler be
an observable change?  It would seem desirable to guarantee that the
comparison above would yield true, but not to require that all string
literals with equivalent content must always do so.  If concatenation
were allowed to be performed in the compiler, then there would be two
ways for an implementation to guarantee that the above comparison would
always yield true:

1. An implementation could do the concatenation in the preprocessor (as is
   currently done) if it guarantees that strings with identical content
   will get merged.

2. An implementation could have __FILE expand to a compiler intrinsic
   reserved word (e.g. ___FILE) and then have the parsing logic say
   that if the system is looking for a literal quote and it sees
   ___FILE, or if it sees ___FILE followed by a literal quote, then it
   will interpret treat the contents of ___FILE as a literal quote that
   can be concatenated, but otherwise it will treat it as a static
   identifier.

Note that while #2 may be somewhat difficult to describe in a formal
grammar, it would not be particularly difficult to *implement*.  Sometimes
the Standard gets too hung up with trying to specify things as formal
grammars, without recognizing that not all useful constructs should be
expected to fit that mold.

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

#129862

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

> Tim Rentsch <txr@alumni.caltech.edu> writes:
>
>> Keith Thompson <kst-u@mib.org> writes:
>>
>>> Robert Wessel <robertwessel2@yahoo.com> writes:
>>>
>>>> [contrasting __func__ and string-literal predefined macros]
>>>
>>> A very minor point:  values yielded by __func__ can be compared for
>>> pointer equality.
>>
>> So can values of string-literal predefined macros.
>
> Can be *meaningfully* compared.  This:
>
>     printf("%d\n", __FILE__ == __FILE__);
>
> could print either 0 or 1.  The value of __func__ for a given
> non-inline function is always the same.

Sorry, sometimes my sense of humor is perhaps too understated.  I
was only trying to be funny.

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

#129741

On Wednesday, April 25, 2018 at 12:34:59 PM UTC-5, robert...@yahoo.com wrote:
> 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.

I didn't say treating it as a *macro*, I said having it as a *token*.  If
my meaning wasn't clear, the intention was that it be a token like "int"
or "while"--something that is treated by the preprocessor like any other
identifier, but which will be recognized and handled as a token in the
main compilation phase.

Perhaps the preprocessor joins together adjacent string literals into one,
but there's no particular reason the main compiler couldn't be capable of
doing likewise.  Even if nothing presently in the language exploits this,
it's not hard to imagine a number of constructs which could benefit from
such an ability, including e.g. an intrinsic which would convert a number
into a string literal containing that character.  At present, if one wants
to call a library function that expects a length-prefixed string, it is
necessary for the length to be hard-coded without any validation that it
is correct, e.g. printString("\014Hello there!"); but if there were an
intrinsic __char_string(n) which would behave as a string literal containing
the specified character, one could then use:

#define lpx_string(x) (__char_string(sizeof (x)) x)

  printString(lpx_string("Hello there!"));

without having to manually encode the length as 14 octal.

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

#129745

On Wed, 25 Apr 2018 12:31:34 -0700, supercat wrote:
> On Wednesday, April 25, 2018 at 12:34:59 PM UTC-5, robert...@yahoo.com wrote:
>> On Wed, 25 Apr 2018 10:30:03 -0700 (PDT), supercat@casperkitty.com
>> >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.
> 
> I didn't say treating it as a *macro*, I said having it as a *token*.

There are no tokens in the translation model when string literals are
concatenated.  Only pp-tokens exist in phase 6.

> Perhaps the preprocessor joins together adjacent string literals into one,
> but there's no particular reason the main compiler couldn't be capable of
> doing likewise.

Nobody says this would be impossible or even particularly difficult to
implement.  Only that it doesn't fit the current translation model in
the language specification.  Changing the model is possible but this
is a more invasive change to the language (the translation model has
barely changed at all since the original editions).

Old versions of GCC provided __FUNCTION__ that worked exactly like you
describe.  That was changed years ago and in current versions __FUNCTION__
means exactly the same thing as __func__, which is probably a reasonable
indication of how much people care about this particular issue.

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

#129748

On Wednesday, April 25, 2018 at 3:13:36 PM UTC-5, Nick Bowler wrote:
> There are no tokens in the translation model when string literals are
> concatenated.  Only pp-tokens exist in phase 6.

Is there any particular reason why adjacent string literals couldn't *also*
be combined later?  All it would require is for a compiler that processes
a string literal to check whether the next token is also a string literal.

> > Perhaps the preprocessor joins together adjacent string literals into one,
> > but there's no particular reason the main compiler couldn't be capable of
> > doing likewise.
> 
> Nobody says this would be impossible or even particularly difficult to
> implement.  Only that it doesn't fit the current translation model in
> the language specification.  Changing the model is possible but this
> is a more invasive change to the language (the translation model has
> barely changed at all since the original editions).

Having a rigid boundary between the preprocessor and the compiler, with
an absolute minimum of duplicated functionality, might have made the
language easier to implement, but I don't see anyone trying to make a
C11 implementation that runs natively on a platform with 16K of RAM [as
opposed to writing a cross-compiler that runs on a larger platform but
generates code for a smaller one].

I have no problem with avoiding changes to the compilation model that
would affect the behavior of existing programs, or make the language
impractical on any particular platforms, but having compilers check
whether the token following a string literal is another string literal
would allow for useful extensions without causing either problem.

> Old versions of GCC provided __FUNCTION__ that worked exactly like you
> describe.  That was changed years ago and in current versions __FUNCTION__
> means exactly the same thing as __func__, which is probably a reasonable
> indication of how much people care about this particular issue.

I wonder to what extent people 'trusted' __FUNCTION__ to remain useful for
any particular purpose?

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

#129737

On Wed, 25 Apr 2018 10:30:03 -0700, supercat wrote:
> I wonder if there's any particular advantage to [the way __func__ is
> specified], 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?

String literal concatenation occurs relatively early in the translation
model (phase 6), before preprocessing tokens are converted to tokens.
The names of any functions won't be known until phase 7, when those
tokens are analyzed as a translation unit.  So handling __func__ as
a string literal would require at least some change to the translation
model, but having a declaration that gets automatically added to every
function body is relatively simple to specify and fits entirely within
phase 7.

There is also a very subtle difference between __func__ and similar
literals.  The specification of __func__ as an object with static
storage duration implies that:

  - Within a single function, all uses of __func__ refer to the same
    object.

  - Within any two different functions that both use __func__, the
    resulting char arrays must be disjoint objects.

(This contrasts with string literals that may, or may not, be merged).

Probably nobody writes programs that depend on these properties
though, outside of conformance test suites.

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

#129766

On Wednesday, April 25, 2018 at 9:19:27 AM UTC-7, 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
>       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.



Bit Twister is repeatedly seen posting "I KNOW BETTER" when it comes to information on a site where it is written with other words... but Bit Twister is just too dim or distracted to deduce any information he finds. Berners-Lee and Bit Twister had their duds and their erratum. One played it dishonestly and didn't do anything too outrageous that could not be backed with peer reviews. Just rubbish from Bit Twister. But Bit Twister has completely left objectivity behind and is merely holding me culpable for the words of himself. Frankly I do not really care. 

See: I quoted specific examples of Bit Twister stating quotable lies -- lying, etc. His response: to double down on your lies. 

It was Bit Twister who flooded Jesus Christ's site thousands of times and denied it. Taking time potentially researching a problem isn't a waste. Claiming you know all and working to convince others that it's true? THAT is a waste. 

After the latest update I no longer want to gouge out my eyeballs from the flicker of the screen. 

--
What Every Entrepreneur Must Know!
https://www.reddit.com/r/linux/comments/6sfhq6/what_desktop_tasks_does_linux_handle_better_than/
https://groups.google.com/forum/#!topic/comp.lang.c/KDQrv8appR8
Jonas Eklundh

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

#129734

On 25/04/2018 16:41, Ben Bacarisse wrote:
> bartc <bc@freeuk.com> writes:
> 
>> I took one github C project
> 
> Which one?

I was reluctant to link to it as it was written by a poster here. But I 
don't think I've said anything that doesn't apply to most open source 
projects, so just google for for 'luser postscript'; I think it was the 
second hit. The directory was src/lib.

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

It shows that it likes to be compiled with gcc.

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

Yes, of course. It's C code, and these are C compilers. They have no 
other purpose than to process C code.

>> The one problem file for gcc was a missing header that I couldn't find
>> anywhere.
> 
> Why do you want to keep it secret?

Keep what a secret? I've said there are build systems, including an M4 
file, and stuff for MSVC, and all sorts of things I've got no clue about.

I'm just looking at what happens when you take an arbitrary C file, 
which are supposed to be self-contained and compilable in any order (one 
of the few advantages of C I will admit to), and run it through the 
nearest C compiler to hand. It should not matter which one.

Even if I went through the normal channels, what does it know about my 
compiler? Nothing.

C sources should just work. If I take one of my now rare one-file C 
projects, bcc64.c, it compiles without errors with bcc (mine), Tiny C, 
Pelles C, DMC, gcc, and MSVC.

lccwin had a problem. While DMC was only 32-bits so I had to suppress 
the #error message for a non-64-bit compile: this is the only special 
requirements but that is because it's generated code.

Unless the compiler has a problem of its own (and I've seen a few), it 
wouldn't take much extra effort to have managed 7/7 instead of 6/7.

-- 
bartc

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

#129753

bartc <bc@freeuk.com> writes:

> On 25/04/2018 16:41, Ben Bacarisse wrote:
>> bartc <bc@freeuk.com> writes:
>>
>>> I took one github C project
>>
>> Which one?
>
> I was reluctant to link to it as it was written by a poster here. But
> I don't think I've said anything that doesn't apply to most open
> source projects, so just google for for 'luser postscript'; I think it
> was the second hit. The directory was src/lib.

I doubt he or she would be worried.  It's a good piece of work and your
results have no bearing on that, since you chose to ignore the build
system.

>>> 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?
>
> It shows that it likes to be compiled with gcc.

I think you missed the conditional (and you certainly ignored the
question).  Given that the project uses a configuration/build system
(which you chose not to use), the results don't show very much at all.

>>> 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.)
>
> Yes, of course. It's C code, and these are C compilers. They have no
> other purpose than to process C code.

Are any of these C compilers in default mode?  The ones I know are not,
but I don't know them all.  And for those that are, what version of C do
they compile?

>>> The one problem file for gcc was a missing header that I couldn't find
>>> anywhere.
>>
>> Why do you want to keep it secret?
>
> Keep what a secret?

The missing header file.

-- 
Ben.

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

#129760

On 25/04/2018 23:15, Ben Bacarisse wrote:
> bartc <bc@freeuk.com> writes:

>> It shows that it likes to be compiled with gcc.
> 
> I think you missed the conditional (and you certainly ignored the
> question).  Given that the project uses a configuration/build system
> (which you chose not to use),

I didn't choose not to. I just can't because I don't know how, and when 
I've tried in the past, the results were hit and miss, usually miss, so 
now I don't even bother.

(On this particular project, all readme/install files seem to mention 
only Linux commands, nothing about Windows.

There is a Visual Studio directory with .sln files for various VS 
versions. If I open the latest, then 2 minutes of disk activity later, I 
get an empty window with a panel at the bottom showing retargetting 
results, as this is VS17. What now? If I say Build, things happen, but 
at the end it says '1 succeeded, 3 failed', with one message saying it 
could't open 'config.h'.

At this point I have absolutely no idea what worked or what didn't, what 
should have worked, what output files should have been generated or how 
to run them (were they even .exes or .dlls?), or what I can do about any 
failures because the important details are buried behind automated 
systems. All I know is the project has no new .exe or .dll files anywhere.

THIS is why I insist on ultra-simple builds with instructions preferably 
in English.)

> Are any of these C compilers in default mode?  The ones I know are not,
> but I don't know them all.  And for those that are, what version of C do
> they compile?

If you run any of those compilers with the name of a C file, they will 
compile that file. I don't think specifying the C version to be compiled 
would fix any of the errors I was seeing. Here's one such error:


#ifdef _WIN32
  static int
  mkstemp_fill(HCRYPTPROV provider, char *template)
                                 ^
c:\ps\src\lib\xpost_compat.c(185) : Error: ')' expected to close 
function parameter list with
     buf = template;
                   ^
(HCRYPTPROV is a typedef for ULONG_PTR, which is in turn a typedef for 
unsigned long long, but a typedef with __extension__ in front, whatever 
that means.

I don't have a way of knowing if DMC can see those declarations, but if 
I replace HCRYPTPROV with 'unsigned long long', then it skips that error.)

Using Pellec C on the same file:

c:\ps\src\lib\xpost_compat.c(217): error #2168: Operands of '=' have 
incompatible types 'unsigned long long int' and 'void *'.

Same error on lccwin32, and similar on MSVC. Line 217 is:

    HCRYPTPROV provider = NULL;

If HCRYPTPROV is unsigned long long, then this is an error because the 
RHS is a void*, and the LHS is an int.

In gcc apparently this is normally just a warning, but in this context, 
I didn't even get that for some reason.

Anyway, I'd be interested in how you think using the recommended build 
process can get around problems like this other than just suppressing 
such problems.

(BTW my compiler fails because it doesn't have wincrypt.h. This file 
varies from 5,000 to 20,000 lines, not including other nested includes. 
I think another part requires winsock2.h. This is why I started to lose 
interest in providing a viable C compiler.

Providing versions of all these headers is a huge effort, while making 
use of other compilers' headers doesn't work as they are full of 
features specific to that compiler.)

-----------------

Just as a reminder of how it should be done IMO; pcc64.c is a byte-code 
interpreter expressed as C code (about 1/4 the line count of the src\lib 
.c and .h files); pasted from actual output with no editing other than 
the indents:

   c:\cx>bcc pcc64
   BCC Compiling pcc64.c to pcc64.asm

   c:\cx>mxa pcc64
   Assembling/linking pcc64.asm... to pcc64.exe

   c:\cx>pcc64 hello
   Hello, World!

No hassle; no fuss; IT JUST WORKS. If I put those 3 lines into a batch 
file (compile, assemble, link and run) and time it, it takes 0.17 
seconds (and all those programs are unoptimised!).

Clearly everyone else likes to do things the hard way.

>>>> The one problem file for gcc was a missing header that I couldn't find
>>>> anywhere.
>>>
>>> Why do you want to keep it secret?
>>
>> Keep what a secret?
> 
> The missing header file.

It's xcb/xcb.h. There is no xcb directory anywhere in the project. But 
this is in one of a set of _dev_ files so may depend on the presence of 
an external library. (The other _dev_ files compile however.)

-- 
bartc

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

#129762

bartc <bc@freeuk.com> writes:
[...]
> Using Pellec C on the same file:
>
> c:\ps\src\lib\xpost_compat.c(217): error #2168: Operands of '=' have 
> incompatible types 'unsigned long long int' and 'void *'.
>
> Same error on lccwin32, and similar on MSVC. Line 217 is:
>
>     HCRYPTPROV provider = NULL;
>
> If HCRYPTPROV is unsigned long long, then this is an error because the 
> RHS is a void*, and the LHS is an int.
>
> In gcc apparently this is normally just a warning, but in this context, 
> I didn't even get that for some reason.

NULL can be of type void* or of any integer type.  If the standard
headers have
    #define NULL 0
then
    unsigned long long provider = NULL;
is legal (but a bad idea, since NULL should be used only in a pointer
context).

[...]

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

#129779

bartc <bc@freeuk.com> writes:

> On 25/04/2018 23:15, Ben Bacarisse wrote:
>> bartc <bc@freeuk.com> writes:
>
>>> It shows that it likes to be compiled with gcc.
>>
>> I think you missed the conditional (and you certainly ignored the
>> question).  Given that the project uses a configuration/build system
>> (which you chose not to use),
>
> I didn't choose not to. I just can't because I don't know how, and
> when I've tried in the past, the results were hit and miss, usually
> miss, so now I don't even bother.

Ah, I see.  That means you have no idea what the build system might
bring to the party, and thus no idea what your numbers show.  For all
you know the files you took a copy of may include complete or partial
configuration for one or other compiler, yes?

>> Are any of these C compilers in default mode?  The ones I know are not,
>> but I don't know them all.  And for those that are, what version of C do
>> they compile?
>
> If you run any of those compilers with the name of a C file, they will
> compile that file. I don't think specifying the C version to be
> compiled would fix any of the errors I was seeing.

I was commenting on the incorrect statement that you cut.  (It's your
style to remove text with out any indication and you prefer me to do
that in my replies -- which I have done -- but it does not add to the
clarity of the discussion.)

> Here's one such error:

The errors you get on an un-configured or partially configured source
are not interesting (well, not to me, you seem to be interested in
them).  In particular they don't help answer the questions I asked.

> Just as a reminder of how it should be done IMO; pcc64.c

Can you link to this file?  It would be interesting so see just how much
simpler this program is than the one you posted about.

> is a
> byte-code interpreter expressed as C code (about 1/4 the line count of
> the src\lib .c and .h files); pasted from actual output with no
> editing other than the indents:
>
>   c:\cx>bcc pcc64
>   BCC Compiling pcc64.c to pcc64.asm
>
>   c:\cx>mxa pcc64
>   Assembling/linking pcc64.asm... to pcc64.exe
>
>   c:\cx>pcc64 hello
>   Hello, World!
>
> No hassle; no fuss; IT JUST WORKS.

It doesn't work for me.

>>>>> The one problem file for gcc was a missing header that I couldn't find
>>>>> anywhere.
>>>>
>>>> Why do you want to keep it secret?
>>>
>>> Keep what a secret?
>>
>> The missing header file.
>
> It's xcb/xcb.h. There is no xcb directory anywhere in the project.

Indeed.  Why did you think there would be?

-- 
Ben.

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

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

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

csiph-web