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

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

Type system protocols rest atop fundamental data

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

Contents

  Type system protocols rest atop fundamental data "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-14 06:14 -0700
    Re: Type system protocols rest atop fundamental data "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-14 06:18 -0700
      Re: Type system protocols rest atop fundamental data mark.bluemel@gmail.com - 2017-06-14 08:00 -0700
        Re: Type system protocols rest atop fundamental data "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-14 08:06 -0700
      Re: Type system protocols rest atop fundamental data bartc <bc@freeuk.com> - 2017-06-14 20:39 +0100
        Re: Type system protocols rest atop fundamental data Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-14 21:51 +0100
          Re: Type system protocols rest atop fundamental data bartc <bc@freeuk.com> - 2017-06-14 22:25 +0100
            Re: Type system protocols rest atop fundamental data Keith Thompson <kst-u@mib.org> - 2017-06-14 14:37 -0700
              Re: Type system protocols rest atop fundamental data bartc <bc@freeuk.com> - 2017-06-15 00:32 +0100
                Re: Type system protocols rest atop fundamental data Keith Thompson <kst-u@mib.org> - 2017-06-14 17:02 -0700
                  Re: Type system protocols rest atop fundamental data bartc <bc@freeuk.com> - 2017-06-15 01:34 +0100
                    Re: Type system protocols rest atop fundamental data Robert Wessel <robertwessel2@yahoo.com> - 2017-06-14 20:28 -0500
                      Re: Type system protocols rest atop fundamental data raltbos@xs4all.nl (Richard Bos) - 2017-06-18 10:49 +0000
                    Re: Type system protocols rest atop fundamental data Keith Thompson <kst-u@mib.org> - 2017-06-14 20:02 -0700
                    Re: Type system protocols rest atop fundamental data David Brown <david.brown@hesbynett.no> - 2017-06-15 10:29 +0200
                      Re: Type system protocols rest atop fundamental data bartc <bc@freeuk.com> - 2017-06-15 10:54 +0100
                        Re: Type system protocols rest atop fundamental data David Brown <david.brown@hesbynett.no> - 2017-06-15 13:15 +0200
                          Re: Type system protocols rest atop fundamental data bartc <bc@freeuk.com> - 2017-06-15 13:51 +0100
                            Re: Type system protocols rest atop fundamental data David Brown <david.brown@hesbynett.no> - 2017-06-15 16:13 +0200
                            Re: Type system protocols rest atop fundamental data Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-15 16:01 +0100
                              Re: Type system protocols rest atop fundamental data Keith Thompson <kst-u@mib.org> - 2017-06-15 09:27 -0700
                      Re: Type system protocols rest atop fundamental data raltbos@xs4all.nl (Richard Bos) - 2017-06-18 10:49 +0000
                  Re: Type system protocols rest atop fundamental data Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-16 23:35 -0700
                    Re: Type system protocols rest atop fundamental data Keith Thompson <kst-u@mib.org> - 2017-06-17 16:10 -0700
                      Re: Type system protocols rest atop fundamental data supercat@casperkitty.com - 2017-06-17 19:23 -0700
                Re: Type system protocols rest atop fundamental data Ian Collins <ian-news@hotmail.com> - 2017-06-16 13:13 +1200
                  Re: Type system protocols rest atop fundamental data "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-15 18:44 -0700
                    Re: Type system protocols rest atop fundamental data David Brown <david.brown@hesbynett.no> - 2017-06-16 13:42 +0200
                      Re: Type system protocols rest atop fundamental data Gareth Owen <gwowen@gmail.com> - 2017-06-16 20:20 +0100
                      Re: Type system protocols rest atop fundamental data Robert Wessel <robertwessel2@yahoo.com> - 2017-06-18 00:32 -0500
                        Re: Type system protocols rest atop fundamental data raltbos@xs4all.nl (Richard Bos) - 2017-06-18 11:06 +0000
                        Re: Type system protocols rest atop fundamental data David Brown <david.brown@hesbynett.no> - 2017-06-18 15:26 +0200
                      Re: Type system protocols rest atop fundamental data bartc <bc@freeuk.com> - 2017-06-18 14:58 +0100
            Re: Type system protocols rest atop fundamental data Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-15 01:42 +0100
              Re: Type system protocols rest atop fundamental data bartc <bc@freeuk.com> - 2017-06-15 11:52 +0100
                Re: Type system protocols rest atop fundamental data Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-15 16:07 +0100
                  Re: Type system protocols rest atop fundamental data Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-16 23:37 -0700
                Re: Type system protocols rest atop fundamental data Keith Thompson <kst-u@mib.org> - 2017-06-15 09:52 -0700
                  Re: Type system protocols rest atop fundamental data supercat@casperkitty.com - 2017-06-15 10:36 -0700
                    Re: Type system protocols rest atop fundamental data scott@slp53.sl.home (Scott Lurndal) - 2017-06-15 17:58 +0000
                      Re: Type system protocols rest atop fundamental data supercat@casperkitty.com - 2017-06-15 11:48 -0700
                        Re: Type system protocols rest atop fundamental data scott@slp53.sl.home (Scott Lurndal) - 2017-06-15 19:01 +0000
                          Re: Type system protocols rest atop fundamental data supercat@casperkitty.com - 2017-06-15 12:29 -0700
                            Re: Type system protocols rest atop fundamental data Ian Collins <ian-news@hotmail.com> - 2017-06-16 13:47 +1200
                              Re: Type system protocols rest atop fundamental data supercat@casperkitty.com - 2017-06-15 19:33 -0700
                          Re: Type system protocols rest atop fundamental data supercat@casperkitty.com - 2017-06-15 13:02 -0700
                            Re: Type system protocols rest atop fundamental data "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-15 13:09 -0700
                            Re: Type system protocols rest atop fundamental data David Brown <david.brown@hesbynett.no> - 2017-06-15 22:25 +0200
                              Re: Type system protocols rest atop fundamental data supercat@casperkitty.com - 2017-06-15 14:23 -0700
                                Re: Type system protocols rest atop fundamental data David Brown <david.brown@hesbynett.no> - 2017-06-15 23:53 +0200
                                  Re: Type system protocols rest atop fundamental data supercat@casperkitty.com - 2017-06-15 15:39 -0700
                                    Re: Type system protocols rest atop fundamental data David Brown <david.brown@hesbynett.no> - 2017-06-16 13:50 +0200
                                      Re: Type system protocols rest atop fundamental data supercat@casperkitty.com - 2017-06-16 08:40 -0700
                                        Re: Type system protocols rest atop fundamental data David Brown <david.brown@hesbynett.no> - 2017-06-18 16:49 +0200
                                          Re: Type system protocols rest atop fundamental data supercat@casperkitty.com - 2017-06-19 10:33 -0700
                                            Re: Type system protocols rest atop fundamental data scott@slp53.sl.home (Scott Lurndal) - 2017-06-19 17:50 +0000
                                              Re: Type system protocols rest atop fundamental data supercat@casperkitty.com - 2017-06-19 12:12 -0700
                                                Re: Type system protocols rest atop fundamental data scott@slp53.sl.home (Scott Lurndal) - 2017-06-19 19:27 +0000
                                            Re: Type system protocols rest atop fundamental data Ike Naar <ike@iceland.freeshell.org> - 2017-06-20 15:18 +0000
                                              Re: Type system protocols rest atop fundamental data supercat@casperkitty.com - 2017-06-20 09:30 -0700
                                      Re: Type system protocols rest atop fundamental data David Kleinecke <dkleinecke@gmail.com> - 2017-06-16 12:05 -0700
                                        Re: Type system protocols rest atop fundamental data supercat@casperkitty.com - 2017-06-16 12:30 -0700
                                          Re: Type system protocols rest atop fundamental data David Brown <david.brown@hesbynett.no> - 2017-06-18 16:54 +0200
                                            Re: Type system protocols rest atop fundamental data supercat@casperkitty.com - 2017-06-19 13:25 -0700
                                              Re: Type system protocols rest atop fundamental data David Brown <david.brown@hesbynett.no> - 2017-06-20 09:27 +0200
                                                Re: Type system protocols rest atop fundamental data supercat@casperkitty.com - 2017-06-20 08:53 -0700
                                                  Re: Type system protocols rest atop fundamental data David Brown <david.brown@hesbynett.no> - 2017-06-20 22:12 +0200
                                                    Re: Type system protocols rest atop fundamental data "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-06-20 13:14 -0700
                                                      Re: Type system protocols rest atop fundamental data "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-06-20 13:16 -0700
                                                    Re: Type system protocols rest atop fundamental data supercat@casperkitty.com - 2017-06-20 14:04 -0700
                                                      Re: Type system protocols rest atop fundamental data David Brown <david.brown@hesbynett.no> - 2017-06-21 15:33 +0200
                                              Re: Type system protocols rest atop fundamental data scott@slp53.sl.home (Scott Lurndal) - 2017-06-20 13:25 +0000
                                        Re: Type system protocols rest atop fundamental data scott@slp53.sl.home (Scott Lurndal) - 2017-06-16 19:42 +0000
                                        Re: Type system protocols rest atop fundamental data David Brown <david.brown@hesbynett.no> - 2017-06-18 16:58 +0200
                                      Re: Type system protocols rest atop fundamental data raltbos@xs4all.nl (Richard Bos) - 2017-06-17 19:18 +0000
                                  Re: Type system protocols rest atop fundamental data Robert Wessel <robertwessel2@yahoo.com> - 2017-06-15 23:40 -0500
                                    Re: Type system protocols rest atop fundamental data David Brown <david.brown@hesbynett.no> - 2017-06-16 13:51 +0200
                                      Re: Type system protocols rest atop fundamental data scott@slp53.sl.home (Scott Lurndal) - 2017-06-16 12:55 +0000
        Re: Type system protocols rest atop fundamental data "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-14 14:23 -0700
          Re: Type system protocols rest atop fundamental data Ian Collins <ian-news@hotmail.com> - 2017-06-16 13:48 +1200
            Re: Type system protocols rest atop fundamental data "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-15 19:03 -0700
              Re: Type system protocols rest atop fundamental data Ian Collins <ian-news@hotmail.com> - 2017-06-16 15:12 +1200
                Re: Type system protocols rest atop fundamental data "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-15 20:20 -0700
                Re: Type system protocols rest atop fundamental data Richard Heathfield <rjh@cpax.org.uk> - 2017-06-16 07:03 +0100
                  Re: Type system protocols rest atop fundamental data Ian Collins <ian-news@hotmail.com> - 2017-06-16 20:01 +1200
                    Re: Type system protocols rest atop fundamental data Richard Heathfield <rjh@cpax.org.uk> - 2017-06-16 19:21 +0100
                      Re: Type system protocols rest atop fundamental data "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-06-16 12:07 -0700
                      Re: Type system protocols rest atop fundamental data Ian Collins <ian-news@hotmail.com> - 2017-06-17 16:18 +1200
                        Re: Type system protocols rest atop fundamental data Richard Heathfield <rjh@cpax.org.uk> - 2017-06-17 07:19 +0100
                    Re: Type system protocols rest atop fundamental data raltbos@xs4all.nl (Richard Bos) - 2017-06-17 19:19 +0000
                      Re: Type system protocols rest atop fundamental data Ian Collins <ian-news@hotmail.com> - 2017-06-18 08:29 +1200
                        Re: Type system protocols rest atop fundamental data supercat@casperkitty.com - 2017-06-17 18:49 -0700
                          Re: Type system protocols rest atop fundamental data Ian Collins <ian-news@hotmail.com> - 2017-06-18 16:18 +1200
                            Re: Type system protocols rest atop fundamental data Öö Tiib <ootiib@hot.ee> - 2017-06-18 06:28 -0700
                  Re: Type system protocols rest atop fundamental data Keith Thompson <kst-u@mib.org> - 2017-06-16 09:11 -0700
                  Re: Type system protocols rest atop fundamental data Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-16 23:37 -0700
                    Re: Type system protocols rest atop fundamental data David Brown <david.brown@hesbynett.no> - 2017-06-18 17:04 +0200
              Re: Type system protocols rest atop fundamental data scott@slp53.sl.home (Scott Lurndal) - 2017-06-16 12:56 +0000
                Re: Type system protocols rest atop fundamental data "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-16 07:10 -0700
                Re: Type system protocols rest atop fundamental data GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-06-16 16:38 +0200
                  Re: Type system protocols rest atop fundamental data scott@slp53.sl.home (Scott Lurndal) - 2017-06-16 15:02 +0000
                    Re: Type system protocols rest atop fundamental data "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-16 08:11 -0700
                      Re: Type system protocols rest atop fundamental data David Brown <david.brown@hesbynett.no> - 2017-06-18 17:13 +0200
        Re: Type system protocols rest atop fundamental data supercat@casperkitty.com - 2017-06-14 14:42 -0700
    Re: Type system protocols rest atop fundamental data Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-14 21:32 +0100
      Re: Type system protocols rest atop fundamental data "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2017-06-14 14:28 -0700

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

#112176 — Type system protocols rest atop fundamental data

I think it's important to remember that languages like C or C++ or other
lower-level languages are looking to manipulate data close to the CPU
level, but without consideration given to the CPU they're running on.
They do this through a type system.

The type system is a protocol for data access.  But ultimately, you
must remember that a language like C can process a block of data, and
then pass that data off to another function in another library, and
that other library may have been written in another language that does
not operate as C does on data.  It will manipulate the data using its
own protocols through its own type system, but ultimately, the data is
what's being changed.

Picture a car.  A team of three amateurs comes in with their incomplete
tool set, and tries to remove, rebuild, and reinstall the engine.  If
you had a time lapse camera mounted on the garage you could see their
operations on that process, and let's assume they operate at an optimum
level for their limited set of tools, it would produce a series of steps
which take them from pre-rebuild, to rebuild, to post-rebuild over the
time it takes.

Now envision the same car, same job, but this time it's done with a team
of three professionals, with every tool they'll need, and they go through
the same process.  The time lapse camera would record a different series
of steps to get from A to B to C, but ultimately the same final result is
completed:  the car went from pre-rebuild, to rebuild, to post-rebuild
over the time it took them.

This is similar to what types are like in a language.  You have a set of
tools, a set of operators, a set of exposed abilities through the quirks
of the language, which enable you to process data a particular way.
Other languages operate differently enough that in those languages you
process data potentially similarly or identically in some areas, but also
probably differently in others.  But still the job is being done

With C, you operate on data through the type system.  Rigid and fixed,
resulting in legal and illegal operations resulting in defined and
undefined behavior.  CAlive's goals intend to allow you to choose the
system you're using to process the underlying data.  You can choose to
use the type system of C, or extend it out to include CAlive's various
extensions, or you can dip down into assembly and process things using
that kind of language (and someone here once mentioned a generic asm
language that allows fundamental operations to be conducted on fundamental
data sizes, and I may go that route for my asm langauge as it allows
a write-once, run-anywhere conversion, which will typically be 1:1 for
machine instructions), and I also intend to allow even higher level
features, such as a direct inclusion of Visual FreePro's VXB++ language,
which is an XBASE language for processing data using that engine.

The whole point of any language is to process data.  The definitions of
a language give it a protocol of enforcement in the manipulation of
that data.  With CAlive, I will allow various options for protocols of
enforcement based on what I, the developer, decide to do, and when, on
the data that's before me for the job at hand.  I can choose to use the
stubby ratchet and 12-point shallow-well socket for processing, or the
6-point deep-well socket and an pneumatic tool for processing.

Type systems enforce protocols, and that's great.  CAlive will allow a
range of type systems to use on data processing, each of which will
enforce their sets of rules, and impose upon the work at hand a set of
relaxations that are the side-effect of their use.

It will not be half-baked or clumsy, but will be appropriate and
proper, and a very powerful tool when completed.

Thank you,
Rick C. Hodgin

[toc] | [next] | [standalone]

#112178

On Wednesday, June 14, 2017 at 9:15:10 AM UTC-4, Rick C. Hodgin wrote:
> I think it's important to remember that languages like C or C++ or other
> lower-level languages are looking to manipulate data close to the CPU
> level, but without consideration given to the CPU they're running on.
> They do this through a type system.
> 
> The type system is a protocol for data access.  But ultimately, you
> must remember that a language like C can process a block of data, and
> then pass that data off to another function in another library, and
> that other library may have been written in another language that does
> not operate as C does on data.  It will manipulate the data using its
> own protocols through its own type system, but ultimately, the data is
> what's being changed.
> 
> Picture a car.  A team of three amateurs comes in with their incomplete
> tool set, and tries to remove, rebuild, and reinstall the engine.  If
> you had a time lapse camera mounted on the garage you could see their
> operations on that process, and let's assume they operate at an optimum
> level for their limited set of tools, it would produce a series of steps
> which take them from pre-rebuild, to rebuild, to post-rebuild over the
> time it takes.
> 
> Now envision the same car, same job, but this time it's done with a team
> of three professionals, with every tool they'll need, and they go through
> the same process.  The time lapse camera would record a different series
> of steps to get from A to B to C, but ultimately the same final result is
> completed:  the car went from pre-rebuild, to rebuild, to post-rebuild
> over the time it took them.
> 
> This is similar to what types are like in a language.  You have a set of
> tools, a set of operators, a set of exposed abilities through the quirks
> of the language, which enable you to process data a particular way.
> Other languages operate differently enough that in those languages you
> process data potentially similarly or identically in some areas, but also
> probably differently in others.  But still the job is being done
> 
> With C, you operate on data through the type system.  Rigid and fixed,
> resulting in legal and illegal operations resulting in defined and
> undefined behavior.  CAlive's goals intend to allow you to choose the
> system you're using to process the underlying data.  You can choose to
> use the type system of C, or extend it out to include CAlive's various
> extensions, or you can dip down into assembly and process things using
> that kind of language (and someone here once mentioned a generic asm
> language that allows fundamental operations to be conducted on fundamental
> data sizes, and I may go that route for my asm langauge as it allows
> a write-once, run-anywhere conversion, which will typically be 1:1 for
> machine instructions), and I also intend to allow even higher level
> features, such as a direct inclusion of Visual FreePro's VXB++ language,
> which is an XBASE language for processing data using that engine.
> 
> The whole point of any language is to process data.  The definitions of
> a language give it a protocol of enforcement in the manipulation of
> that data.  With CAlive, I will allow various options for protocols of
> enforcement based on what I, the developer, decide to do, and when, on
> the data that's before me for the job at hand.  I can choose to use the
> stubby ratchet and 12-point shallow-well socket for processing, or the
> 6-point deep-well socket and an pneumatic tool for processing.
> 
> Type systems enforce protocols, and that's great.  CAlive will allow a
> range of type systems to use on data processing, each of which will
> enforce their sets of rules, and impose upon the work at hand a set of
> relaxations that are the side-effect of their use.
> 
> It will not be half-baked or clumsy, but will be appropriate and
> proper, and a very powerful tool when completed.
> 
> Thank you,
> Rick C. Hodgin

Note:  This was all off the top of my head.  I haven't even re-read
       it yet. :-)  As such, any errors or omissions are wholly un-
       intentional.

Thank you,
Rick C. Hodgin

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

#112184

On Wednesday, 14 June 2017 14:18:22 UTC+1, Rick C. Hodgin  wrote:

> Note:  This was all off the top of my head.  I haven't even re-read
>        it yet. :-)  As such, any errors or omissions are wholly un-
>        intentional.

If you can't be bothered to read it before you posted, I think I'll follow suit and not bother reading it after.

(If you just want somewhere to put unfiltered thoughts, have you considered a blog?)

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

#112185

On Wednesday, June 14, 2017 at 11:00:45 AM UTC-4, mark.b...@gmail.com wrote:
> On Wednesday, 14 June 2017 14:18:22 UTC+1, Rick C. Hodgin  wrote:
> 
> > Note:  This was all off the top of my head.  I haven't even re-read
> >        it yet. :-)  As such, any errors or omissions are wholly un-
> >        intentional.
> 
> If you can't be bothered to read it before you posted, I think I'll
> follow suit and not bother reading it after.

It doesn't bother me if you choose not to read it.  I did re-read it
later, so that what I'm reading is outside of my current thinking, and
therefore enters my brain as new knowledge rather than me simply auto-
remembering what I intended to write, even if that's not what it really
says, and overall it's as I wanted, except I forgot a period at the end
of one paragraph.

> (If you just want somewhere to put unfiltered thoughts, have you
> considered a blog?)

Why don't you read it and find out why?  If you don't want to read it,
the title pretty much sums up what the article is about.

I'm not sure many people realize that type systems and language features
are just a way to process data.  They are not fundamentals, but apply
only protocols atop what are truly fundamentals, which is why I wrote it.

Thank you,
Rick C. Hodgin

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

#112217

On 14/06/2017 14:18, Rick C. Hodgin wrote:
> On Wednesday, June 14, 2017 at 9:15:10 AM UTC-4, Rick C. Hodgin wrote:
>> I think it's important to remember that languages like C or C++ or other
>> lower-level languages are looking to manipulate data close to the CPU
>> level, but without consideration given to the CPU they're running on.
>> They do this through a type system.
>>
>> The type system is a protocol for data access.

> Note:  This was all off the top of my head.  I haven't even re-read
>         it yet. :-)  As such, any errors or omissions are wholly un-
>         intentional.

I read it, but didn't understand it.

However, you seem to be under the impression that C imposes some 
high-level types on the underlying data.

But C's type system is minimal: integers, floats and pointers. You can 
hardly get lower than that. Those also correspond to how values in 
registers are operated on in a typical processor.

The nearest to a bare data word is probably an unsigned integer, which 
already exists in C, together with operators that treat it as a 
collection of arbitrary bits (binary & for example).

Other than that, an int type in C can store a number representing 
anything. It has a range which is exactly that of the underlying 
hardware type (so -32768 to 32767 for a 16-bit signed), not that 
required for the application.

So, it is already low-level!

-- 
bartc

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

#112222

bartc <bc@freeuk.com> writes:
<snip>
> But C's type system is minimal: integers, floats and pointers. You can
> hardly get lower than that.

C also has function types, array types, structure types, union types and
_Bool.  Enums hardly qualify but they might get though on a
technicality.  In addition there are type qualifiers that make new,
different types from the unqualified versions.

And some people (some even who post here) would consider it disingenuous
to say that C has "integers" while at the same time describing the type
system as "minimal" given the proliferation of integer types and the
number of rules that have grown up around them.

<snip>
-- 
Ben.

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

#112224

On 14/06/2017 21:51, Ben Bacarisse wrote:
> bartc <bc@freeuk.com> writes:
> <snip>
>> But C's type system is minimal: integers, floats and pointers. You can
>> hardly get lower than that.
> 
> C also has function types, array types, structure types, union types and
> _Bool.  Enums hardly qualify but they might get though on a
> technicality.  In addition there are type qualifiers that make new,
> different types from the unqualified versions.

A function type isn't really tangible, except as a function pointer. And 
that's already covered. Arrays, structs and unions are just collections 
of the basic types, and are limited in what can be done with them 
without indexing or selecting an element or subelement that /is/ a basic 
type.

Enums are not a type. _Bools I haven't played with enough (actually not 
at all); but seem an unnecessary addition to the language. Nor with 
bitfields.

> And some people (some even who post here) would consider it disingenuous
> to say that C has "integers" while at the same time describing the type
> system as "minimal" given the proliferation of integer types and the
> number of rules that have grown up around them.

Current machines seem to have a need for 8 integer types: 8, 16, 32 and 
64 bits, signed and unsigned, and C supplies that need.

Sort of, as it generously (but not very usefully) provides 10 integer 
types instead! (There are five types without explicit widths has 'long' 
is usually the same as 'int', or the same as 'long long'.) Or possibly 
11, if 'plain char' is considered different from unsigned or signed char.

-- 
bartc

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

#112227

bartc <bc@freeuk.com> writes:
[...]
> Enums are not a type.

Incorrect.  For example, given:
    enum foo { zero, one };
`enum foo` is a type.  Perhaps you meant something else.

[...]

> Sort of, as it generously (but not very usefully) provides 10 integer 
> types instead! (There are five types without explicit widths has 'long' 
> is usually the same as 'int', or the same as 'long long'.)

long typically has the same representation as either int or long long,
but it's always a distinct type.

>                                                            Or possibly 
> 11, if 'plain char' is considered different from unsigned or signed char.

No "if" is necessary.  Plain char *is* distinct from both unsigned char
and signed char.

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

#112229

On 14/06/2017 22:37, Keith Thompson wrote:
> bartc <bc@freeuk.com> writes:
> [...]
>> Enums are not a type.
> 
> Incorrect.  For example, given:
>      enum foo { zero, one };
> `enum foo` is a type.  Perhaps you meant something else.

I considered enum to be just an int. But out of 5 compilers, 3 flag an 
error when assigning an enum foo* to a float*.

Given these enums:

  typedef enum colours {red,green,blue} Colour;
  typedef enum days {mon, tue, wed} Day;

Then only 2 of those 5 reject assigning a Day* to a Colour*.

And when calling:

  void fn(Colour x){}

then none of those compilers say anything when passing a Day type to 
such a function:

  Day d;
  fn(d);

Of course, none of them /can/ say anything when fn(wed) is used, as I 
don't think 'wed' has anything but int type.

So the effort to make enums a type is rather half-hearted, and doesn't 
go very far.
                                                    Or possibly
>> 11, if 'plain char' is considered different from unsigned or signed char.
> 
> No "if" is necessary.  Plain char *is* distinct from both unsigned char
> and signed char.

This:

  char *a;
  signed char *b;
  unsigned char *c;

  a=b;
  b=c;
  a=c;

doesn't raise any errors with gcc. But does with some other compilers.

(Another quirk for my collection I think. What possible use is having 
/three/ kinds of char? And why aren't there three kinds of int?)

-- 
bartc

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

#112230

bartc <bc@freeuk.com> writes:
> On 14/06/2017 22:37, Keith Thompson wrote:
>> bartc <bc@freeuk.com> writes:
>> [...]
>>> Enums are not a type.
>> 
>> Incorrect.  For example, given:
>>      enum foo { zero, one };
>> `enum foo` is a type.  Perhaps you meant something else.
>
> I considered enum to be just an int.

You were wrong.  Enumerated types are integer types.  `enum foo`
is a distinct type.

> Given these enums:
>
>   typedef enum colours {red,green,blue} Colour;
>   typedef enum days {mon, tue, wed} Day;
>
> Then only 2 of those 5 reject assigning a Day* to a Colour*.

Each enum type is compatible with some integer type.  gcc treats Colour
and Day as compatible with unsigned int, but not with each other (which
is valid, type compatibility is not necessarily transitive).

My understanding is that Colour and Day are *not* compatible, even
if they're both compatible with the same integer type, and that
any conforming compiler must diagnose the assignment.  (gcc does
in conforming mode.)  I'm not 100% confident in that conclusion.

Did you invoke those 5 compilers in a standard-conforming mode?
If not, your results are meaningless.

> And when calling:
>
>   void fn(Colour x){}
>
> then none of those compilers say anything when passing a Day type to 
> such a function:
>
>   Day d;
>   fn(d);

There's an implicit conversion.  That doesn't imply the types are the
same.  Try passing an int to a function that with a double argument;
does the lack of a diagnostic imply that int and double are the same
type?

> Of course, none of them /can/ say anything when fn(wed) is used, as I 
> don't think 'wed' has anything but int type.

Enumeration constants are of type int.

> So the effort to make enums a type is rather half-hearted, and doesn't 
> go very far.

Nevertheless, enumerated types are types.  N1570 6.2.5p16.

>                                                     Or possibly
>>> 11, if 'plain char' is considered different from unsigned or signed char.
>> 
>> No "if" is necessary.  Plain char *is* distinct from both unsigned char
>> and signed char.
>
> This:
>
>   char *a;
>   signed char *b;
>   unsigned char *c;
>
>   a=b;
>   b=c;
>   a=c;
>
> doesn't raise any errors with gcc. But does with some other compilers.

I get 3 warnings with "gcc -std=c11 -pedantic".  Any results without
those options, or something similar, are irrelevant.

> (Another quirk for my collection I think. What possible use is having
> /three/ kinds of char? And why aren't there three kinds of int?)

At the moment, I'm not interested in discussing whether it's useful.
The fact is there are three character types.

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

#112231

On 15/06/2017 01:02, Keith Thompson wrote:
> bartc <bc@freeuk.com> writes:

> Did you invoke those 5 compilers in a standard-conforming mode?
> If not, your results are meaningless.

It's 2017. Why should a recent compiler default to compiling a standard 
that is nearly 30 years out of date?

But, whatever, that's how I invoke my compilers, and that's how a 
newcomer will do so. And they're the ones who are going to be confused 
as to what is valid and what isn't, when compilers can't make up their 
own minds about it.

>> (Another quirk for my collection I think. What possible use is having
>> /three/ kinds of char? And why aren't there three kinds of int?)
> 
> At the moment, I'm not interested in discussing whether it's useful.

OK, I take it you can't think of any useful applications of it!

-- 
bartc

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

#112236

On Thu, 15 Jun 2017 01:34:14 +0100, bartc <bc@freeuk.com> wrote:

>On 15/06/2017 01:02, Keith Thompson wrote:
>> bartc <bc@freeuk.com> writes:
>
>> Did you invoke those 5 compilers in a standard-conforming mode?
>> If not, your results are meaningless.
>
>It's 2017. Why should a recent compiler default to compiling a standard 
>that is nearly 30 years out of date?


Usually it's for backwards compatibility.  Release N+1 of a compiler
compiles programs with more-or-less the same semantics as release N
did.

After enough releases, and changes to the standard, what you're doing
for historical reasons might well not be the same as what you'd do if
you were able to start from scratch.

But, of course, you already knew that.


>But, whatever, that's how I invoke my compilers,


So really, why are you here then?  Are we just a handy audience for
your carping about random topics not really related to the purposes of
this group?

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

#112450

Robert Wessel <robertwessel2@yahoo.com> wrote:

> On Thu, 15 Jun 2017 01:34:14 +0100, bartc <bc@freeuk.com> wrote:
> 
> >But, whatever, that's how I invoke my compilers,
> 
> So really, why are you here then?

To troll. And you're rising to the bait.

Richard

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

#112238

bartc <bc@freeuk.com> writes:
> On 15/06/2017 01:02, Keith Thompson wrote:
>> bartc <bc@freeuk.com> writes:
>> Did you invoke those 5 compilers in a standard-conforming mode?
>> If not, your results are meaningless.
>
> It's 2017. Why should a recent compiler default to compiling a
> standard that is nearly 30 years out of date?

I meant the current standard.  Or any standard (I think the relevant
rules for enumerated types are unchanged).  What made you think I was
talking about C89/C90?

> But, whatever, that's how I invoke my compilers, and that's how a
> newcomer will do so. And they're the ones who are going to be confused
> as to what is valid and what isn't, when compilers can't make up their
> own minds about it.

I thought we were talking about the language rules, such as the one that
says an enumerated type is a distinct type.  Compilers invoked in a
non-conforming mode tell us nothing about that.

>>> (Another quirk for my collection I think. What possible use is having
>>> /three/ kinds of char? And why aren't there three kinds of int?)
>>
>> At the moment, I'm not interested in discussing whether it's useful.
>
> OK, I take it you can't think of any useful applications of it!

Stop pretending I said things I didn't say.

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

#112244

On 15/06/17 02:34, bartc wrote:
> On 15/06/2017 01:02, Keith Thompson wrote:
>> bartc <bc@freeuk.com> writes:
> 
>> Did you invoke those 5 compilers in a standard-conforming mode?
>> If not, your results are meaningless.
> 
> It's 2017. Why should a recent compiler default to compiling a standard
> that is nearly 30 years out of date?
> 

Some compilers default to older standards, some to newer standards.
Backwards compatibility makes compiler developers reluctant to change
the default behaviour when invoking without flags.

Some compilers don't support newer standards at all - there are still
compilers made and sold that are stuck at (roughly) C90, and a good many
that don't support C11.  Some compilers have only partial support for
some of the standards, and some don't even bother specifying which
standards they approximate.  And many compiler writers make subtle
mistakes in understanding the C standards - they are often written by
one or two people that have no particular qualifications that don't
discuss the details with others.

Almost all compilers default to allowing some extensions or enhancements
that the writers feel give the user a better tool.

If you want to complain about this state of affairs, do so to the
compiler manufacturers - they are the only ones that can change it.
Most people, however, are quite happy with this arrangement - otherwise
the manufacturers would already have changed it.  Some people use the
compilers as they are by default, but most use at least some compiler
flags.  Any confused newcomer can get the information they need from a
quick google, and will no longer be confused.


But really, you know all this already.  Why you continue to run
compilers in default modes and use the results as though they explain
the C standards is a mystery to me.

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

#112245

On 15/06/2017 09:29, David Brown wrote:
> On 15/06/17 02:34, bartc wrote:
>> On 15/06/2017 01:02, Keith Thompson wrote:
>>> bartc <bc@freeuk.com> writes:
>>
>>> Did you invoke those 5 compilers in a standard-conforming mode?
>>> If not, your results are meaningless.
>>
>> It's 2017. Why should a recent compiler default to compiling a standard
>> that is nearly 30 years out of date?
>>
> 
> Some compilers default to older standards, some to newer standards.

No, all the ones I've tried seem to default to old standards, or don't 
take certain error conditions seriously. (I've given plenty of examples.)

> But really, you know all this already.  Why you continue to run
> compilers in default modes and use the results as though they explain
> the C standards is a mystery to me.

The mystery is why modern C compilers default to those modes.

BTW I don't actually know how to tell any C compiler how to support a 
modern mode, except for gcc. And even there, if I use -std=c11 on:


  int main(void) {
     issspace(0,0,0,0);
     isspace("abcd");
  }

I only get a warning about implicit declarations, on what is obviously 
an error. So what do you suggest, going through the hundreds of possibly 
warnings, and add hundreds of options to turn those into errors? Or 
having a single option to turn EVERY warning into an error? Apart from 
not knowing that that is, that sounds a bad idea.

With Tiny C, it doesn't appear to have such an option. That said nothing 
at all.

With DMC, I couldn't see such an option either (only -A for strict 
ANSI). That's quite an old compiler, but still released 5 years after 
1999. That said nothing at all about this code.

With Pelles C, it's /std:{C11}, but it says that is the default mode. 
Yet it gives only warnings.

With lccwin64, I couldn't figure out how to show all the options. With 
lccwin32, there is an option -ansic90 which disables C99, so it sounds 
like the latter is already the default. Yet it still gives warnings only.

With MSVC, I can only use that from inside Visual Studio, so don't want 
to spend all morning figuring what the options are and how to set them. 
But I would be surprised if such a modern compiler (used from VS2017) 
disabled C99 and C11 features.

So a newcomer using one of these compilers, even with an explicit 
standards option, will not see anything particular untoward about the 
above code.

Even if applied to correct code, such is isspace('A'), they will see the 
same message, and the program will still work. The impression is that 
this doesn't really matter.


-- 
bartc

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

#112248

On 15/06/17 11:54, bartc wrote:
> On 15/06/2017 09:29, David Brown wrote:
>> On 15/06/17 02:34, bartc wrote:
>>> On 15/06/2017 01:02, Keith Thompson wrote:
>>>> bartc <bc@freeuk.com> writes:
>>>
>>>> Did you invoke those 5 compilers in a standard-conforming mode?
>>>> If not, your results are meaningless.
>>>
>>> It's 2017. Why should a recent compiler default to compiling a standard
>>> that is nearly 30 years out of date?
>>>
>>
>> Some compilers default to older standards, some to newer standards.
> 
> No, all the ones I've tried seem to default to old standards, or don't
> take certain error conditions seriously. (I've given plenty of examples.)
> 

gcc changed to a default of "gnu11" rather than "gnu89" with version 5
released about 2 years ago.  (Note that the default standard includes
gcc extensions.)  clang currently also has "gnu11" as its default
standard, but I don't know how recent that is.

As for your other compilers, I have no idea.

>> But really, you know all this already.  Why you continue to run
>> compilers in default modes and use the results as though they explain
>> the C standards is a mystery to me.
> 
> The mystery is why modern C compilers default to those modes.
> 
> BTW I don't actually know how to tell any C compiler how to support a
> modern mode, except for gcc. 

Here's an idea.  You could see if the compilers have a /manual/, or some
sort of documentation.  Maybe that will tell you?

As an alternative, you could also try a web search.

Or, of course, you could boast about your wilful ignorance in a public
newsgroup.

> And even there, if I use -std=c11 on:
> 
> 
>  int main(void) {
>     issspace(0,0,0,0);
>     isspace("abcd");
>  }
> 
> I only get a warning about implicit declarations, on what is obviously
> an error. So what do you suggest, going through the hundreds of possibly
> warnings, and add hundreds of options to turn those into errors? Or
> having a single option to turn EVERY warning into an error? Apart from
> not knowing that that is, that sounds a bad idea.

I suggest you learn to use your compilers, and also that you learn what
compilers actually /do/ and what they are used for.

There is no point in anyone giving you suggestions of flags here - it
has been done before, and you will ignore them or forget them within
seconds.

> 
> With Tiny C, it doesn't appear to have such an option. That said nothing
> at all.

Hey, imagine that - a C compiler that is designed to be as small and
simple as possible has fewer features than a big and comprehensive one.

> 
> With DMC, I couldn't see such an option either (only -A for strict
> ANSI). That's quite an old compiler, but still released 5 years after
> 1999. That said nothing at all about this code.
> 
> With Pelles C, it's /std:{C11}, but it says that is the default mode.
> Yet it gives only warnings.
> 
> With lccwin64, I couldn't figure out how to show all the options. With
> lccwin32, there is an option -ansic90 which disables C99, so it sounds
> like the latter is already the default. Yet it still gives warnings only.
> 
> With MSVC, I can only use that from inside Visual Studio, so don't want
> to spend all morning figuring what the options are and how to set them.
> But I would be surprised if such a modern compiler (used from VS2017)
> disabled C99 and C11 features.

Yes, MSVC is famous for its solid and timely support for C99 and C11.
/Really/ famous.

> 
> So a newcomer using one of these compilers, even with an explicit
> standards option, will not see anything particular untoward about the
> above code.
> 
> Even if applied to correct code, such is isspace('A'), they will see the
> same message, and the program will still work. The impression is that
> this doesn't really matter.
> 
> 

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

#112250

On 15/06/2017 12:15, David Brown wrote:
> On 15/06/17 11:54, bartc wrote:

> gcc changed to a default of "gnu11" rather than "gnu89" with version 5
> released about 2 years ago.

In 2015? OK....


>> BTW I don't actually know how to tell any C compiler how to support a
>> modern mode, except for gcc.
> 
> Here's an idea.  You could see if the compilers have a /manual/, or some
> sort of documentation.  Maybe that will tell you?

Read my post. I checked the displayed options of all compilers except 
for lccwin64.

> As an alternative, you could also try a web search.
> 
> Or, of course, you could boast about your wilful ignorance in a public
> newsgroup.

I shouldn't need to search the web to find out how to goad a compiler 
into doing its job properly.

> I suggest you learn to use your compilers, and also that you learn what
> compilers actually /do/ and what they are used for.

> There is no point in anyone giving you suggestions of flags here - it
> has been done before, and you will ignore them or forget them within
> seconds.

>>
>> With Tiny C, it doesn't appear to have such an option. That said nothing
>> at all.
> 
> Hey, imagine that - a C compiler that is designed to be as small and
> simple as possible has fewer features than a big and comprehensive one.

Which, funnily enough, gives the same results as the big and 
comprehensive one.

>> With DMC, I couldn't see such an option either (only -A for strict
>> ANSI). That's quite an old compiler, but still released 5 years after
>> 1999. That said nothing at all about this code.
>>
>> With Pelles C, it's /std:{C11}, but it says that is the default mode.
>> Yet it gives only warnings.
>>
>> With lccwin64, I couldn't figure out how to show all the options. With
>> lccwin32, there is an option -ansic90 which disables C99, so it sounds
>> like the latter is already the default. Yet it still gives warnings only.
>>
>> With MSVC, I can only use that from inside Visual Studio, so don't want
>> to spend all morning figuring what the options are and how to set them.
>> But I would be surprised if such a modern compiler (used from VS2017)
>> disabled C99 and C11 features.
> 
> Yes, MSVC is famous for its solid and timely support for C99 and C11.
> /Really/ famous.

You're starting to take the piss now.

Give me an example of a freely available C compiler (other than DMC 
which is the only line that notices the mismatched arguments), which out 
of the box and with default options, diagnoses:

   randommadeupfunction(1,2,3,"blah");
   randommadeupfunction(1e37);

as an error. And tell me how to get all the compilers I've mentioned - 
apart from Tiny C and DMC - to report that as error.

Or is it too much effort? If so, that is exactly the problem. They 
should just work.

According to you, it is all MY fault:

* That Tiny C is so limited

* That the massive MSVC is so limited

* That gcc doesn't do these checks by default and that EVERYBODY who 
uses gcc (not just me) has to browse 1200 different options to find the 
one that will turn this check on. You're also assume that everybody 
KNOWS about all the errors that a compiler will just let through unless 
prodded to report them properly.

Sorry, but you're getting close to personal insults.

 From what I can see, this is an endemic problem with C and with C 
compilers, in carrying over sloppy standards from the last century into 
this one. You CANNOT put the blame on an individual.

Compilers should report errors by default, not let errors through by 
default.

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

#112256

On 15/06/17 14:51, bartc wrote:
> On 15/06/2017 12:15, David Brown wrote:
>> On 15/06/17 11:54, bartc wrote:
> 
>> gcc changed to a default of "gnu11" rather than "gnu89" with version 5
>> released about 2 years ago.
> 
> In 2015? OK....
> 

I guess you still don't understand what "backwards compatibility" means,
or why C (and C compilers) change slowly.

> 
>>> BTW I don't actually know how to tell any C compiler how to support a
>>> modern mode, except for gcc.
>>
>> Here's an idea.  You could see if the compilers have a /manual/, or some
>> sort of documentation.  Maybe that will tell you?
> 
> Read my post. I checked the displayed options of all compilers except
> for lccwin64.
> 
>> As an alternative, you could also try a web search.
>>
>> Or, of course, you could boast about your wilful ignorance in a public
>> newsgroup.
> 
> I shouldn't need to search the web to find out how to goad a compiler
> into doing its job properly.
> 

Yes, why try to read manuals or search for information when you can use
a random "try it and see" approach, followed by loud complaints in an
inappropriate place when something doesn't match /your/ idea of "obvious".


>> I suggest you learn to use your compilers, and also that you learn what
>> compilers actually /do/ and what they are used for.
> 
>> There is no point in anyone giving you suggestions of flags here - it
>> has been done before, and you will ignore them or forget them within
>> seconds.
> 
>>>
>>> With Tiny C, it doesn't appear to have such an option. That said nothing
>>> at all.
>>
>> Hey, imagine that - a C compiler that is designed to be as small and
>> simple as possible has fewer features than a big and comprehensive one.
> 
> Which, funnily enough, gives the same results as the big and
> comprehensive one.

Except that it doesn't, according to your own tests.  And it does not
have the options to change that - again, according to your own tests.

> 
>>> With DMC, I couldn't see such an option either (only -A for strict
>>> ANSI). That's quite an old compiler, but still released 5 years after
>>> 1999. That said nothing at all about this code.
>>>
>>> With Pelles C, it's /std:{C11}, but it says that is the default mode.
>>> Yet it gives only warnings.
>>>
>>> With lccwin64, I couldn't figure out how to show all the options. With
>>> lccwin32, there is an option -ansic90 which disables C99, so it sounds
>>> like the latter is already the default. Yet it still gives warnings
>>> only.
>>>
>>> With MSVC, I can only use that from inside Visual Studio, so don't want
>>> to spend all morning figuring what the options are and how to set them.
>>> But I would be surprised if such a modern compiler (used from VS2017)
>>> disabled C99 and C11 features.
>>
>> Yes, MSVC is famous for its solid and timely support for C99 and C11.
>> /Really/ famous.
> 
> You're starting to take the piss now.
> 

Well spotted.

> Give me an example of a freely available C compiler (other than DMC
> which is the only line that notices the mismatched arguments), which out
> of the box and with default options, diagnoses:
> 
>   randommadeupfunction(1,2,3,"blah");
>   randommadeupfunction(1e37);
> 
> as an error. And tell me how to get all the compilers I've mentioned -
> apart from Tiny C and DMC - to report that as error.
> 

No - do your own homework and find which compilers can be set to give an
error here.  I know how to use the compilers /I/ use, and all the
compilers I use regularly will give errors here with the settings /I/
use.  I haven't the slightest interest in investigating some irrelevant
little windows-only decades old compiler just because /you/ seem to
think it is important enough to post about it here, yet not important
enough to learn about or to contact the author about problems or missing
features.

> Or is it too much effort? If so, that is exactly the problem. They
> should just work.

No, it would not be too much effort for the compilers I use.  But I have
no interest in helping you here - experience has shown you to be
ungrateful and wilfully ignorant.  You will just weep dramatically about
how hard this all is for a simple user, then in a couple of weeks you
will complain about it again in a new thread and ask for the same help.

> 
> According to you, it is all MY fault:

It is /your/ fault if you haven't read the manual or done the web search
to see if a particular compiler supports a feature you want.  It is
/your/ fault if you expect an ancient little toy tool to support an
optional feature, or comprehensive warnings.  It is /your/ fault if you
expect a compiler to stick strictly to a particular C standard without
asking it to, or if you expect a very limited compiler to be fully
conforming.  It is /your/ fault if you expect to learn about what the
standard says by trial and error with a random collection of compilers
of variable quality, and consider them equally weighted.  It is /your/
fault if you complain about missing features or incompatibilities in
tools here, rather than in a manner appropriate for the tool in question.

> 
> * That Tiny C is so limited

It is /your/ fault if you take a compiler that is specifically designed
to be as small as possible, and you get upset because it is limited.

> 
> * That the massive MSVC is so limited

It is /your/ fault if you expect MSVC to be good for C standards,
warnings, features and compatibility - everyone and his dog knows MSVC
is poor at C.  /MS/ knows so too, which is why they have moved to using
clang for C.  MSVC concentrates on C++ features, not C.

And it is /your/ fault if you don't know how to use the compiler and its
options, or don't know how to use it from the command line instead of
the IDE.

> 
> * That gcc doesn't do these checks by default and that EVERYBODY who
> uses gcc (not just me) has to browse 1200 different options to find the
> one that will turn this check on. You're also assume that everybody
> KNOWS about all the errors that a compiler will just let through unless
> prodded to report them properly.

No, a great many people who use gcc find no problem in getting the most
useful common options for it.  And a great many people who use gcc do so
without invoking the compiler directly from the command line - they use
an IDE with convenient checkboxes for the common options, or Makefiles
with common options picked.  And most people who are capable of
programming in C are also capable of googling for "common gcc options"
or "gcc getting started" or "gcc tutorial".

> 
> Sorry, but you're getting close to personal insults.

I am sorry, but I believe I have stepped over that line - but I hope you
see it as constructive criticism.  You are making a complete fool of
yourself.

> 
> From what I can see, this is an endemic problem with C and with C
> compilers, in carrying over sloppy standards from the last century into
> this one. You CANNOT put the blame on an individual.

There is plenty wrong - or at least suboptimal - with C, C compilers, C
programmers and the way C is used.  And certainly there are plenty of
things about the way C works that you would not do in a new, modern
language.  But as usual you are inventing new issues that are /not/ real
problems - or at least, not important or serious problems.  Only /you/
have these sorts of troubles, and they are mostly self-inflicted.

The thing I cannot comprehend at all, is why you use C in the first
place.  You clearly hate the language, you clearly hate the tools.  You
are clearly incapable of using it properly, and totally resistant to
learning it.  There are endless numbers of programming languages to
choose from - surely you can find one that you like.

> 
> Compilers should report errors by default, not let errors through by
> default.
> 

I would prefer my compilers to treat potential errors more seriously by
default - but then folks like Supercat would get his knickers in a twist
when the compiler tried to stop his code that he thinks used to be
valid, and which still works in the compiler's /default/ mode.
Backwards compatibility is king in the world of C.

And I have no problem writing "-Wall -Werror" in my Makefiles, so the
default settings don't affect me.

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

#112263

bartc <bc@freeuk.com> writes:
<snip>
> Give me an example of a freely available C compiler (other than DMC
> which is the only line that notices the mismatched arguments), which
> out of the box and with default options, diagnoses:
>
>   randommadeupfunction(1,2,3,"blah");
>   randommadeupfunction(1e37);
>
> as an error.

You need to say a bit more for that even to be an error.  In C90 and up
a declaration can make those lines correct (though not necessarily very
useful) and in K&R C they are OK without one.  Only in C90 code with no
declaration in scope is this definitely an error.

I don't think compiler authors will have put much effort into that slim
wedge of code.  Modern C compilers (C99 and up) diagnose the problem (if
there is one) whether there is no prototype in scope or not, and old C
must not diagnose a problem.  It's an historic issue of little interest
to most C programmers today.

<snip>
-- 
Ben.

[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