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

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

Reliable C tutorial for beginners

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

Contents

  Reliable C tutorial for beginners MehdiAmini <atorrses@gmail.com> - 2017-04-04 15:08 +0430
    Re: Reliable C tutorial for beginners Richard Heathfield <rjh@cpax.org.uk> - 2017-04-04 14:10 +0100
      Re: Reliable C tutorial for beginners fir <profesor.fir@gmail.com> - 2017-04-04 09:12 -0700
      Re: Reliable C tutorial for beginners MehdiAmini <atorrses@gmail.com> - 2017-04-05 16:49 +0430
        Re: Reliable C tutorial for beginners Alla <vitale.alla@gmail.com> - 2017-04-05 16:41 +0300
    Re: Reliable C tutorial for beginners raltbos@xs4all.nl (Richard Bos) - 2017-04-05 11:10 +0000
      Re: Reliable C tutorial for beginners jm.bourguet@gmail.com - 2017-04-05 05:55 -0700
        Re: Reliable C tutorial for beginners fir <profesor.fir@gmail.com> - 2017-04-05 08:01 -0700
        Re: Reliable C tutorial for beginners supercat@casperkitty.com - 2017-04-05 09:45 -0700
          Re: Reliable C tutorial for beginners Jean-Marc Bourguet <jm@bourguet.org> - 2017-04-05 20:04 +0200
          Re: Reliable C tutorial for beginners David Brown <david.brown@hesbynett.no> - 2017-04-05 20:36 +0200
            Re: Reliable C tutorial for beginners supercat@casperkitty.com - 2017-04-05 14:26 -0700
              Re: Reliable C tutorial for beginners David Brown <david.brown@hesbynett.no> - 2017-04-06 09:41 +0200
                Re: Reliable C tutorial for beginners supercat@casperkitty.com - 2017-04-06 07:53 -0700
                  Re: Reliable C tutorial for beginners scott@slp53.sl.home (Scott Lurndal) - 2017-04-06 15:12 +0000
                    Re: Reliable C tutorial for beginners Keith Thompson <kst-u@mib.org> - 2017-04-06 09:12 -0700
                      Re: Reliable C tutorial for beginners scott@slp53.sl.home (Scott Lurndal) - 2017-04-06 16:20 +0000
                        Re: Reliable C tutorial for beginners Keith Thompson <kst-u@mib.org> - 2017-04-06 09:26 -0700
                          Re: Reliable C tutorial for beginners Keith Thompson <kst-u@mib.org> - 2017-04-06 11:53 -0700
                      Re: Reliable C tutorial for beginners Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2017-04-06 12:26 -0400
                        Re: Reliable C tutorial for beginners scott@slp53.sl.home (Scott Lurndal) - 2017-04-06 17:09 +0000
                          Re: Reliable C tutorial for beginners supercat@casperkitty.com - 2017-04-06 10:37 -0700
                            Re: Reliable C tutorial for beginners scott@slp53.sl.home (Scott Lurndal) - 2017-04-06 18:50 +0000
                  Re: Reliable C tutorial for beginners David Brown <david.brown@hesbynett.no> - 2017-04-06 21:46 +0200
                    Re: Reliable C tutorial for beginners supercat@casperkitty.com - 2017-04-06 14:51 -0700
                    Re: Reliable C tutorial for beginners raltbos@xs4all.nl (Richard Bos) - 2017-04-09 13:42 +0000
                      Re: Linux and GCC Noob <root@127.0.0.1> - 2017-04-09 16:45 +0200
                        Re: Linux and GCC David Brown <david.brown@hesbynett.no> - 2017-04-09 16:50 +0200
                          Re: Linux and GCC Noob <root@127.0.0.1> - 2017-04-09 17:06 +0200
                          Re: Linux and GCC raltbos@xs4all.nl (Richard Bos) - 2017-04-14 11:39 +0000
                            Re: Linux and GCC Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-16 17:41 -0700
                              Re: Linux and GCC David Brown <david.brown@hesbynett.no> - 2017-04-17 17:46 +0200
                            Re: Linux and GCC David Brown <david.brown@hesbynett.no> - 2017-04-17 17:37 +0200
                              Re: Linux and GCC supercat@casperkitty.com - 2017-04-17 09:19 -0700
        Re: Reliable C tutorial for beginners Keith Thompson <kst-u@mib.org> - 2017-04-05 13:50 -0700
          Re: Reliable C tutorial for beginners supercat@casperkitty.com - 2017-04-05 14:47 -0700
            Re: Reliable C tutorial for beginners David Brown <david.brown@hesbynett.no> - 2017-04-06 09:45 +0200
          Re: Reliable C tutorial for beginners jm.bourguet@gmail.com - 2017-04-06 01:57 -0700
    Re: Reliable C tutorial for beginners Real Troll <real.troll@trolls.com> - 2017-04-05 15:16 -0500
      Re: Reliable C tutorial for beginners GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-04-06 11:56 +0200
    Re: Reliable C tutorial for beginners Spiros Bousbouras <spibou@gmail.com> - 2017-04-06 14:14 +0000
      Re: Reliable C tutorial for beginners "C-bot" <cbot@example.com> - 2017-04-08 01:18 +0000
        Re: Reliable C tutorial for beginners Spiros Bousbouras <spibou@gmail.com> - 2017-04-08 14:54 +0000
        Re: Reliable C tutorial for beginners Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-08 19:01 +0100
          Re: Reliable C tutorial for beginners Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-09 00:04 +0100
          Re: Reliable C tutorial for beginners Jean-Marc Bourguet <jm@bourguet.org> - 2017-04-09 14:03 +0200
            Re: Reliable C tutorial for beginners Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2017-04-09 15:02 -0600
              Re: Reliable C tutorial for beginners "Chris M. Thomasson" <invalid@invalid.invalid> - 2017-04-09 14:13 -0700
              Re: Reliable C tutorial for beginners Real Troll <real.troll@trolls.com> - 2017-04-09 17:30 -0400
          Re: Reliable C tutorial for beginners Richard Heathfield <rjh@cpax.org.uk> - 2017-04-10 18:35 +0100

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

#107790

Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
>Keith Thompson wrote:
>
>> scott@slp53.sl.home (Scott Lurndal) writes:
>>> supercat@casperkitty.com writes:
>> [...]
>>>>How does the 1974 C Reference Manual define structure member access?
>>>
>>> The BSTJ article was in 1978, IIRC, wherein C was introduced to the
>>> world.
>> 
>> Versions of the C reference manual were published in 1974 and 1975.
>> 
>>     http://cm.bell-labs.com/cm/cs/who/dmr/cman74.pdf
>Now found at https://www.bell-labs.com/usr/dmr/www/cman74.pdf
>

Ah, it would be tempting to argue with published, in this context, as they were internal
Bell Labs technical memorandums; from the world-and-dog standpoint,
the BSTJ article seems to be the earliest.

Regardless, the cman74 also notes that MoS can be used with any
primary lvalue.

7.1.7 primary-lvalue.member-of-structure

  "The object referred to by the lvalue is assumed to have the
   same form as the structure containing the structure member".

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

#107791

On Thursday, April 6, 2017 at 12:09:38 PM UTC-5, Scott Lurndal wrote:
> Regardless, the cman74 also notes that MoS can be used with any
> primary lvalue.
> 
> 7.1.7 primary-lvalue.member-of-structure
> 
>   "The object referred to by the lvalue is assumed to have the
>    same form as the structure containing the structure member".

A major problem with the word "assume", outside of mathematical contexts,
is that it fails to identify what otherwise-unreasonable actions should
be deemed as reasonable in light of the assumption.  As used here, for
example, I would expect that the intended meaning was "A compiler is
under no obligation to check that that the lvalue has the same form as
the structure containing the structure member".  I really doubt that
anyone back then even imagined it might be interpreted to mean "A compiler
may do anything it likes if a structure pointer is used to access a member
of a different aggregate, even accessing the same-offset member of the
other aggregate would be useful."

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

#107792

supercat@casperkitty.com writes:
>On Thursday, April 6, 2017 at 12:09:38 PM UTC-5, Scott Lurndal wrote:
>> Regardless, the cman74 also notes that MoS can be used with any
>> primary lvalue.
>> 
>> 7.1.7 primary-lvalue.member-of-structure
>> 
>>   "The object referred to by the lvalue is assumed to have the
>>    same form as the structure containing the structure member".
>
>A major problem with the word "assume", outside of mathematical contexts,
>is that it fails to identify what otherwise-unreasonable actions should
>be deemed as reasonable in light of the assumption.  As used here, for
>example, I would expect that the intended meaning was "A compiler is
>under no obligation to check that that the lvalue has the same form as
>the structure containing the structure member".  I really doubt that
>anyone back then even imagined it might be interpreted to mean "A compiler
>may do anything it likes if a structure pointer is used to access a member
>of a different aggregate, even accessing the same-offset member of the
>other aggregate would be useful."

That's addressed later in the same document.   It's clear from
the compiler (v6) code itself, which uses a MoS on a pointer
to an int (where the field offset is zero).

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

#107795

On 06/04/17 16:53, supercat@casperkitty.com wrote:
> On Thursday, April 6, 2017 at 2:41:58 AM UTC-5, David Brown wrote:
>> It is written in /C/.  Specifically, C99, plus some extensions, plus
>> some extra guarantees through specific flags.  Not your pretend C, nor
>> plain standard C.
>
> How does the 1974 C Reference Manual define structure member access?  Is
> there any evidence of anything earlier called "C" which only defines the
> behavior in the cases where it would be defined in gcc's interpretation
> of C99?

"gcc's interpretation of C99", in this case, is the way C has always 
been defined since it was standardised.  You are forever interpreting 
"old C did not define this" as meaning "old C worked the way I think", 
when in fact it simply means "this was undefined in old C".

>
>>                         For example, the kernel is compiled with gcc's
>> "-fno-strict-alias" flag.  It uses that for two reasons.  One is that
>> the kernel often needs to access memory in different ways, and the
>> developers have found it convenient to change the rules of C to allow
>> access to objects via incompatible pointers.  Note carefully what I
>> wrote there - they find it /convenient/ to /change the rules of C/.  The
>> second reason is that they are concerned that without that change,
>> people might have written incorrect C code and introduced subtle bugs -
>> they feel that the variation of C with this change is safer for their work.
>
> It is also a variation which, while there is no official standard for it,
> is very widely supported.

Yes, it is so widely supported that there are a range of compilers that 
can be used to compile the Linux kernel.  Oh, wait, that's wrong - gcc 
is the /only/ compiler that can be used for the kernel, because it is 
the /only/ compiler to support this particular variant of C.

There are plenty of older and more limited compilers that don't do 
type-based alias analysis - but that is because they are not 
sophisticated enough compilers, not because they intentionally and 
actively support a variant of C that defines access through incompatible 
pointers.  And there are plenty of processors that have so few registers 
that access to objects is always "mindlessly translated", simply because 
there aren't enough registers to hold data anyway.

>
>> This does not mean, in any shape or form, that the C language was
>> "designed" as the "-fno-strict-alias" variant.  Nor does it mean that
>> early C implementations guaranteed that behaviour (some might, but
>> others might not).  Nor does it mean that you /have/ to have this in
>> order to write low-level code.
>
> Low-level memory management code would often invoke UB without it, though
> usually in ways gcc would not exploit.  Most embedded projects never need
> to recycle or reinterpret storage for any reason, rendering the flag
> irrelevant, but the development frameworks I've seen that used gcc set
> -fno-strict-alias as part of their default options.

In most cases, people set that flag because they don't really understand 
how C works and how compilers work, and they fiddle around with 
disabling optimisation until testing shows that the code works.  I have 
seen /lots/ of code - including code delivered under expensive licenses 
- with notes about "disable optimisation for this file".  It is because 
it is /bad/ code.

>
> If one has code that needs to acquire a block of memory that may last have
> been used as some unknown type and treat it as a sequence of uint16_t[]
> values that are initially populated with unspecified bit patterns, is there
> any *efficient* means of accomplishing that without using behavior equivalent
> to -fno-strict-alias (available on many compilers) or else a gcc extension
> which would be available on fewer?
>

That is not what we are talking about here.

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

#107800

On Thursday, April 6, 2017 at 2:46:19 PM UTC-5, David Brown wrote:
> On 06/04/17 16:53, supercat wrote:
> > On Thursday, April 6, 2017 at 2:41:58 AM UTC-5, David Brown wrote:
> >> It is written in /C/.  Specifically, C99, plus some extensions, plus
> >> some extra guarantees through specific flags.  Not your pretend C, nor
> >> plain standard C.
> >
> > How does the 1974 C Reference Manual define structure member access?  Is
> > there any evidence of anything earlier called "C" which only defines the
> > behavior in the cases where it would be defined in gcc's interpretation
> > of C99?
> 
> "gcc's interpretation of C99", in this case, is the way C has always 
> been defined since it was standardised.  You are forever interpreting 
> "old C did not define this" as meaning "old C worked the way I think", 
> when in fact it simply means "this was undefined in old C".


   7.1.7 primary-lvalue . member-of-structure

    An lvalue expression followed by a dot followed by the name of a
    member of a structure is a primary expression.  The object referred
    to by the lvalue is assumed to have the same form as the structure
    containing the structure member.  **The result of the expression is
    an lvalue appropriately offset from the origin of the given lvalue
    whose type is that of the named structure member.**

    The given lvalue is not required to have any particular type.

That certainly sounds like a definition of what foo.bar means.  While
later versions of C added a *syntactic* restriction that a member name
must appear in the name space associated with a structure type, I've
not seen any evidence to suggest that was intended as a *semantic*
restriction, or that code which had exploited the earlier semantics
[e.g. if two or more structures have a common initial sequence, having
code accept pointers to objects of any such type and use members of
the CIS thereof] should not be readily adaptable to the new syntactic
requirement via the use of pointer casts.

> > It is also a variation which, while there is no official standard for it,
> > is very widely supported.
> 
> Yes, it is so widely supported that there are a range of compilers that 
> can be used to compile the Linux kernel.  Oh, wait, that's wrong - gcc 
> is the /only/ compiler that can be used for the kernel, because it is 
> the /only/ compiler to support this particular variant of C.

Not all gcc options are widely supported, and I don't know which exact ones
gcc uses.  Some which should have been in C89 have finally made it to C11,
but were pretty common before C99 came out.  The features that would make C
behave as a low-level programming language seem to be pretty much universally
available among all microprocessors and microcontrollers that have any
conforming C compiler, though.  

> There are plenty of older and more limited compilers that don't do 
> type-based alias analysis - but that is because they are not 
> sophisticated enough compilers, not because they intentionally and 
> actively support a variant of C that defines access through incompatible 
> pointers.  And there are plenty of processors that have so few registers 
> that access to objects is always "mindlessly translated", simply because 
> there aren't enough registers to hold data anyway.

Most of the benefits that would come from type-based aliasing come from
code like the example given in the C89 rationale.  Further, C89 made the
behavior of writing one union member and reading another Implementation-
Defined except in cases involving Common Initial Sequences, and defined
the address-of operator and pointer conversions such that for pointers
received from outside code, writing through a pointer of one type and
reading via another would be equivalent to doing so for union members.  A
compiler could document that union-based type punning will yield
indeterminate values except when certain conditions are met, but if a
compiler documents storage formats and doesn't specify any contrary
behavior, those would together imply cross-type aliasing behavior.

> > Low-level memory management code would often invoke UB without it, though
> > usually in ways gcc would not exploit.  Most embedded projects never need
> > to recycle or reinterpret storage for any reason, rendering the flag
> > irrelevant, but the development frameworks I've seen that used gcc set
> > -fno-strict-alias as part of their default options.
> 
> In most cases, people set that flag because they don't really understand 
> how C works and how compilers work, and they fiddle around with 
> disabling optimisation until testing shows that the code works.  I have 
> seen /lots/ of code - including code delivered under expensive licenses 
> - with notes about "disable optimisation for this file".  It is because 
> it is /bad/ code.

Some is, some isn't.

> > If one has code that needs to acquire a block of memory that may last have
> > been used as some unknown type and treat it as a sequence of uint16_t[]
> > values that are initially populated with unspecified bit patterns, is there
> > any *efficient* means of accomplishing that without using behavior equivalent
> > to -fno-strict-alias (available on many compilers) or else a gcc extension
> > which would be available on fewer?
> 
> That is not what we are talking about here.

That sort of requirement would hardly seem atypical for an embedded memory
manager, and I would suggest that implementations that can't handle such a
thing efficiently should not be considered suitable for writing low-level
memory management code.  Can you suggest any way it might be guaranteed
to work without using either -fno-strict-aliasing or gcc-specific
extensions?

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

#107932

David Brown <david.brown@hesbynett.no> wrote:

> Yes, it is so widely supported that there are a range of compilers that 
> can be used to compile the Linux kernel.  Oh, wait, that's wrong - gcc 
> is the /only/ compiler that can be used for the kernel, because it is 
> the /only/ compiler to support this particular variant of C.

I thought Linux and gcc had nothing to do with one another?

Make your mind up.

Richard

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

#107937 — Re: Linux and GCC

On 09/04/2017 15:42, Richard Bos wrote:

> David Brown wrote:
> 
>> Yes, it is so widely supported that there are a range of compilers that 
>> can be used to compile the Linux kernel.  Oh, wait, that's wrong - gcc 
>> is the /only/ compiler that can be used for the kernel, because it is 
>> the /only/ compiler to support this particular variant of C.

It might be possible to compile (most of) the Linux kernel
with clang or icc.

> I thought Linux and gcc had nothing to do with one another?
> Make your mind up.

It's not clear what your point is.

Linux developers have decided to use some GCC extensions.
e.g. -fno-strict-aliasing, sizeof(void *) = 1, ({ }) compound statements

Other compilers are free to adopt these extensions
(as clang and icc projects have done).

Linux and GCC are two separate projects, with very little
interaction between them.

Regards.

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

#107940 — Re: Linux and GCC

On 09/04/17 16:45, Noob wrote:
> On 09/04/2017 15:42, Richard Bos wrote:
>
>> David Brown wrote:
>>
>>> Yes, it is so widely supported that there are a range of compilers that
>>> can be used to compile the Linux kernel.  Oh, wait, that's wrong - gcc
>>> is the /only/ compiler that can be used for the kernel, because it is
>>> the /only/ compiler to support this particular variant of C.
>
> It might be possible to compile (most of) the Linux kernel
> with clang or icc.

It is - but only "most of", last I heard.

>
>> I thought Linux and gcc had nothing to do with one another?
>> Make your mind up.
>
> It's not clear what your point is.

His point is that he doesn't like gcc, Linux, or (I think) any sort of 
free or open source software.  So he likes to point out possible 
inconsistencies when people have said nice things about such software.

I already explained roughly what gcc and Linux have to do with each 
other, and I'm sure Richard has read it.  There is little point in 
repeating it for him here.

>
> Linux developers have decided to use some GCC extensions.
> e.g. -fno-strict-aliasing, sizeof(void *) = 1, ({ }) compound statements
>
> Other compilers are free to adopt these extensions
> (as clang and icc projects have done).
>
> Linux and GCC are two separate projects, with very little
> interaction between them.
>
> Regards.
>

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

#107942 — Re: Linux and GCC

On 09/04/2017 16:50, David Brown wrote:

> On 09/04/17 16:45, Noob wrote:
>
>> On 09/04/2017 15:42, Richard Bos wrote:
>>
>>> David Brown wrote:
>>>
>>>> Yes, it is so widely supported that there are a range of compilers that
>>>> can be used to compile the Linux kernel.  Oh, wait, that's wrong - gcc
>>>> is the /only/ compiler that can be used for the kernel, because it is
>>>> the /only/ compiler to support this particular variant of C.
>>
>> It might be possible to compile (most of) the Linux kernel
>> with clang or icc.
> 
> It is - but only "most of", last I heard.

There are patches to make Linux source more "clang-friendly".
Some might even get accepted upstream.

For example, clang is supposed to work on this v4.11-rc1 branch:
https://android-git.linaro.org/kernel/hikey-clang.git/log/?h=master-clang


>>> I thought Linux and gcc had nothing to do with one another?
>>> Make your mind up.
>>
>> It's not clear what your point is.
> 
> His point is that he doesn't like gcc, Linux, or (I think) any sort of 
> free or open source software.  So he likes to point out possible 
> inconsistencies when people have said nice things about such software.

Richard, are you a BSD fan? Do you run FreeBSD or OpenBSD?

Regards.

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

#108123 — Re: Linux and GCC

David Brown <david.brown@hesbynett.no> wrote:

> On 09/04/17 16:45, Noob wrote:
> > On 09/04/2017 15:42, Richard Bos wrote:
> >
> >> David Brown wrote:
> >>
> >>> Yes, it is so widely supported that there are a range of compilers that
> >>> can be used to compile the Linux kernel.  Oh, wait, that's wrong - gcc
> >>> is the /only/ compiler that can be used for the kernel, because it is
> >>> the /only/ compiler to support this particular variant of C.

> >> I thought Linux and gcc had nothing to do with one another?
> >> Make your mind up.
> >
> > It's not clear what your point is.
> 
> His point is that he doesn't like gcc, Linux, or (I think) any sort of 
> free or open source software.  So he likes to point out possible 
> inconsistencies when people have said nice things about such software.

Bullshit, and you know it. I have made it quite clear quite often before
that what I dislike is not OSS itself but the hypocrisy of its adherents
and the lack of criticism it, and in particularly gcc, gets in this
newsgroup where commercialisms are roundly slated and even mocked for
similare, and often the very same, faults.

If Microsoft makes its API easy to use for MSVC, and harder for gcc,
that's Microsoft's fault. If Linux makes its API easy to use for gcc and
harder for other compilers, that's because it's the best design. If M$
makes the compiler use the system DLLs, that's poor practice and
introduces dependencies. If gcc separates the compiler and the library
and refuses to acknowledge that they are the two halves of one
implementation, that's just how it works.
I'm sorry that your ego is bruised by this, but that's _not_ how it
works. You cannot praise Linux and the OSS milieu for the same things
you criticise M$, Apple and other vendors for. That's nothing to do with
liking one or the other, that's plain hypocrisy.

I'm not playing King Lear, here, or even Alceste; I'm playing Mercutio.
Both, indeed all, your houses deserve the plague, and if I curse Linux
more often it's only because Linux is more often blindly defended here.

Richard

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

#108184 — Re: Linux and GCC

raltbos@xs4all.nl (Richard Bos) writes:

> David Brown <david.brown@hesbynett.no> wrote:
>
>> On 09/04/17 16:45, Noob wrote:
>>> On 09/04/2017 15:42, Richard Bos wrote:
>>>
>>>> David Brown wrote:
>>>>
>>>>> Yes, it is so widely supported that there are a range of compilers that
>>>>> can be used to compile the Linux kernel.  Oh, wait, that's wrong - gcc
>>>>> is the /only/ compiler that can be used for the kernel, because it is
>>>>> the /only/ compiler to support this particular variant of C.
>>>>
>>>> I thought Linux and gcc had nothing to do with one another?
>>>> Make your mind up.
>>>
>>> It's not clear what your point is.
>>
>> His point is that he doesn't like gcc, Linux, or (I think) any sort of
>> free or open source software.  So he likes to point out possible
>> inconsistencies when people have said nice things about such software.
>
> Bullshit, and you know it.  I have made it quite clear quite often before
> that what I dislike is not OSS itself but the hypocrisy of its adherents
> and the lack of criticism it, and in particularly gcc, gets in this
> newsgroup where commercialisms are roundly slated and even mocked for
> similare, and often the very same, faults.
>
> If Microsoft makes its API easy to use for MSVC, and harder for gcc,
> that's Microsoft's fault.  If Linux makes its API easy to use for gcc and
> harder for other compilers, that's because it's the best design.  If M$
> makes the compiler use the system DLLs, that's poor practice and
> introduces dependencies.  If gcc separates the compiler and the library
> and refuses to acknowledge that they are the two halves of one
> implementation, that's just how it works.
> I'm sorry that your ego is bruised by this, but that's _not_ how it
> works.  You cannot praise Linux and the OSS milieu for the same things
> you criticise M$, Apple and other vendors for.  That's nothing to do with
> liking one or the other, that's plain hypocrisy.  

I sort of agree with you, but I think there's an important
difference here that should be noted.  Microsoft go out of their
way to introduce interdependencies that promote lock-in to their
platforms, even when they know they are making choices that are
technically flawed.  I see no indication that Linux developers or
the GNU/FSF people do this.  Sometimes the GNU or Linux crowd
make decisions that seem to me technically misguided (eg, info
files in place of man pages), but AFAIK their intentions are
sincere and not malicious.  The same cannot be said of Microsoft.
(And I feel confident in saying that based on first-hand
experience.)

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

#108208 — Re: Linux and GCC

On 17/04/17 02:41, Tim Rentsch wrote:
> raltbos@xs4all.nl (Richard Bos) writes:
>
>> David Brown <david.brown@hesbynett.no> wrote:
>>
>>> On 09/04/17 16:45, Noob wrote:
>>>> On 09/04/2017 15:42, Richard Bos wrote:
>>>>
>>>>> David Brown wrote:
>>>>>
>>>>>> Yes, it is so widely supported that there are a range of compilers that
>>>>>> can be used to compile the Linux kernel.  Oh, wait, that's wrong - gcc
>>>>>> is the /only/ compiler that can be used for the kernel, because it is
>>>>>> the /only/ compiler to support this particular variant of C.
>>>>>
>>>>> I thought Linux and gcc had nothing to do with one another?
>>>>> Make your mind up.
>>>>
>>>> It's not clear what your point is.
>>>
>>> His point is that he doesn't like gcc, Linux, or (I think) any sort of
>>> free or open source software.  So he likes to point out possible
>>> inconsistencies when people have said nice things about such software.
>>
>> Bullshit, and you know it.  I have made it quite clear quite often before
>> that what I dislike is not OSS itself but the hypocrisy of its adherents
>> and the lack of criticism it, and in particularly gcc, gets in this
>> newsgroup where commercialisms are roundly slated and even mocked for
>> similare, and often the very same, faults.
>>
>> If Microsoft makes its API easy to use for MSVC, and harder for gcc,
>> that's Microsoft's fault.  If Linux makes its API easy to use for gcc and
>> harder for other compilers, that's because it's the best design.  If M$
>> makes the compiler use the system DLLs, that's poor practice and
>> introduces dependencies.  If gcc separates the compiler and the library
>> and refuses to acknowledge that they are the two halves of one
>> implementation, that's just how it works.
>> I'm sorry that your ego is bruised by this, but that's _not_ how it
>> works.  You cannot praise Linux and the OSS milieu for the same things
>> you criticise M$, Apple and other vendors for.  That's nothing to do with
>> liking one or the other, that's plain hypocrisy.
>
> I sort of agree with you, but I think there's an important
> difference here that should be noted.  Microsoft go out of their
> way to introduce interdependencies that promote lock-in to their
> platforms, even when they know they are making choices that are
> technically flawed.  I see no indication that Linux developers or
> the GNU/FSF people do this.  Sometimes the GNU or Linux crowd
> make decisions that seem to me technically misguided (eg, info
> files in place of man pages), but AFAIK their intentions are
> sincere and not malicious.  The same cannot be said of Microsoft.
> (And I feel confident in saying that based on first-hand
> experience.)
>

"Dos ain't done 'til Lotus won't run"  :-)

To play the devil's advocate a little, and show that I am not /totally/ 
biased, I'd add a couple of points here.  One is that MS seems to be a 
lot better at playing with others now than it used to be - the days of 
secret Windows API's that are only available to the MS Office 
development team, and similar tactics, are mostly in the past.  The 
other is that the FSF do try to introduce dependencies on the GPL that 
are not technically justified, such as by encouraging libraries to use 
the GPL license rather than the LGPL.  Their motivations are not 
malicious - they sincerely believe that the license is better for end 
users, and therefore a good thing even for such libraries - but it is 
certainly not a technical motivation.

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

#108205 — Re: Linux and GCC

On 14/04/17 13:39, Richard Bos wrote:
> David Brown <david.brown@hesbynett.no> wrote:
>
>> On 09/04/17 16:45, Noob wrote:
>>> On 09/04/2017 15:42, Richard Bos wrote:
>>>
>>>> David Brown wrote:
>>>>
>>>>> Yes, it is so widely supported that there are a range of compilers that
>>>>> can be used to compile the Linux kernel.  Oh, wait, that's wrong - gcc
>>>>> is the /only/ compiler that can be used for the kernel, because it is
>>>>> the /only/ compiler to support this particular variant of C.
>
>>>> I thought Linux and gcc had nothing to do with one another?
>>>> Make your mind up.
>>>
>>> It's not clear what your point is.
>>
>> His point is that he doesn't like gcc, Linux, or (I think) any sort of
>> free or open source software.  So he likes to point out possible
>> inconsistencies when people have said nice things about such software.
>
> Bullshit, and you know it. I have made it quite clear quite often before
> that what I dislike is not OSS itself but the hypocrisy of its adherents
> and the lack of criticism it, and in particularly gcc, gets in this
> newsgroup where commercialisms are roundly slated and even mocked for
> similare, and often the very same, faults.

I am not a fan of hypocrisy either - few people are.  If you were to dig 
through all the posts I have made (I am not suggestion you do so - it's 
not worth the effort), you'd see some posts I have made that are 
critical to gcc.  But it just so happens that I think it is an excellent 
tool, and far and away the best compiler for /my/ needs.  Clearly, I 
have a lot more good things to say about it than bad things - that is 
not hypocrisy, it is merely being fond of a good tool.  And most of the 
criticisms against gcc in this newsgroup have been things that are, 
IMHO, of very little relevance.

>
> If Microsoft makes its API easy to use for MSVC, and harder for gcc,
> that's Microsoft's fault.

Of course it would be Microsoft's /fault/ - who wrote the API and the 
MSVC compiler?  Whether it is a problem or not is another matter, and 
there could well be good technical reasons for the API being the way it 
is.  And it is perfectly reasonable for MS to emphasis support for their 
own tools.  But if I think it is technically a poor choice of API, I 
don't see it as unreasonable to say so.

> If Linux makes its API easy to use for gcc and
> harder for other compilers, that's because it's the best design.

The Linux kernel is written using gcc extensions - and currently, that 
is the only compiler that supports everything the Linux kernel needs. 
But the API is made to work with any compiler and any programming 
language that can follow a pretty standard ABI calling convention.

In the early days of the Linux kernel, there were no other compilers 
that could be considered for compiling it - so it made perfect sense to 
use gcc extensions if they helped the code.  Now, there /are/ other 
candidates such as clang and icc, and it makes sense to minimise the 
dependencies on extensions that are not also supported on these compilers.

But the key difference here is that no one expects to compile /Windows/ 
using gcc - they just want to compile user-mode code for Windows with 
gcc.  There has never been any problem compiling user-mode code for 
Linux with other compilers.


> If M$
> makes the compiler use the system DLLs, that's poor practice and
> introduces dependencies. If gcc separates the compiler and the library
> and refuses to acknowledge that they are the two halves of one
> implementation, that's just how it works.

You must be getting your ideas from some other gcc or Linux fan.  I 
criticise the MS C library for being old (poor C99 support), though its 
C++ support is top class.  This means that any C compiler on Windows 
that relies on the system DLL's and/or MSVC's DLL's for the C runtime 
library will necessarily be limited.  As for the separation of library 
and compiler for gcc - I think it is usually a good thing.  I am a big 
user of gcc - but a very small user of glibc (in my own code), and I am 
glad that I have a selection of libraries to use with gcc for different 
purposes.

However, this separation - like many things about gcc - seems to confuse 
certain people in this group, and needs to be explained again and again.

> I'm sorry that your ego is bruised by this, but that's _not_ how it
> works. You cannot praise Linux and the OSS milieu for the same things
> you criticise M$, Apple and other vendors for. That's nothing to do with
> liking one or the other, that's plain hypocrisy.

And you cannot tar every gcc and/or *nix user with the same brush.  I am 
a happy user of gcc and Linux - and a less happy user of Windows (and 
mostly happy to avoid Apple OS's).  So I am most vocal in arguing 
against unreasonable criticism of gcc or Linux, or promoting their good 
points - because I think they are technically better in many ways than 
the alternatives.  But I don't think they are perfect, nor do I shy from 
criticising them or saying when I think something else is a technically 
better choice.  And I try to make it clear that I write /my/ opinions, 
for /my/ uses - these may not be the same as other people's.

Note that what may appear to be hypocrisy, may be differences that were 
not clearly explained (such as the difference between the compiler(s) 
used for building the operating system, and the compiler(s) used for 
applications on the operating system).

>
> I'm not playing King Lear, here, or even Alceste; I'm playing Mercutio.
> Both, indeed all, your houses deserve the plague, and if I curse Linux
> more often it's only because Linux is more often blindly defended here.
>

OK, fair enough.

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

#108217 — Re: Linux and GCC

On Monday, April 17, 2017 at 10:38:09 AM UTC-5, David Brown wrote:
> You must be getting your ideas from some other gcc or Linux fan.  I 
> criticise the MS C library for being old (poor C99 support), though its 
> C++ support is top class.  This means that any C compiler on Windows 
> that relies on the system DLL's and/or MSVC's DLL's for the C runtime 
> library will necessarily be limited.  As for the separation of library 
> and compiler for gcc - I think it is usually a good thing.  I am a big 
> user of gcc - but a very small user of glibc (in my own code), and I am 
> glad that I have a selection of libraries to use with gcc for different 
> purposes.

I think the biggest DOS/Win problem is that there has never been a standard
convention via which a library that buffers data that should get written
to a file can notify the OS of the buffer's existence and ensure that the
buffer will get written before anything else goes to the file.  The lack of
such a feature means that if a project contains two or more components that
need to write to a file and either uses standard-C-library buffering, then
either each will have to ensure that the file is flushed before any calls
are made to the other, or both will have to use the same version of the C
runtime library.

If there had been a call to request a special kind of memory allocation from
DOS that would be used as a file buffer, then libraries could coexist smoothly
if before writing to their buffer they did something like:

    if (!theFile->bufferDescriptor->isOwned)
      someDosCall(theFile->bufferDescriptor);

that call could then direct DOS to write out whatever data was in the buffer
of whatever library presently owned the file, clear its isOwned flag, and set
the isOwned flag of the calling library.  I don't fault Microsoft for not
having built such a thing into the library initially, but it would have been
helpful if DOS/Win had included some special hooks to check whether code was
using an old C runtime library and patch its behavior if so; such a thing
would also have allowed the system to ensure that programs which output to
both stdout and stderr will flush the contents of one any time code writes
to the other.  When the runtime was first written, it would have been rare
for those to be connected to two different real-time streams, but in Windows
it would often be useful to have them do so were it not for the broken
buffering behavior.

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

#107769

jm.bourguet@gmail.com writes:
> Le mercredi 5 avril 2017 13:10:17 UTC+2, Richard Bos a écrit :
>> For someone who is already a programmer, but is a beginner at C, IYAM
>> the best tutorial is still the original: Kernignan and Ritchie's The C
>> Programming Language. But that's not legally available on-line.
>
> That's what I used to say until a few years ago I reread it and
> noticed that although the second edition was not describing C as it is
> practiced nowadays but K&R C with minimal syntax update to make it
> syntactically acceptable to a C++ compiler used to compensate the lack
> of C compilers accepting the language described by the then-future
> standard.  It's a book of the 70's updated in the 80's and it feels.
> Read it again and ask yourself: do you really recommend it to someone
> who does not know C?

K&R2 was published about the same time the 1989 ANSI C standard
was published.  Of course it doesn't cover C99 or C11, but I think
it generally does a good job of covering ANSI C89.  Can you give
an example where it doesn't?

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

#107771

On Wednesday, April 5, 2017 at 3:50:51 PM UTC-5, Keith Thompson wrote:
> K&R2 was published about the same time the 1989 ANSI C standard
> was published.  Of course it doesn't cover C99 or C11, but I think
> it generally does a good job of covering ANSI C89.  Can you give
> an example where it doesn't?

IIRC, the book says that on a typical platform, a "short" will be stored as
two bytes and a "long" will be stored as four.  Nothing in the book suggests
that writing to an aligned "long*" on such a platform will do anything
other than storing a value in four bytes starting at the given address,
or that reading an aligned "short*" will do anything other than reading
a value from two bytes starting at the given address.  The mention of
word "typical" does imply that there may exist non-typical platforms which
behave differently, but does not suggest that such behavior is should not
be expected even when code is known to be running on typical platforms.

The definition of the address-of operator implies that if the address-of
operator is applied to an lvalue, then throughout the lifetime of the
lvalue in question applying the * operator to the resulting pointer value
will yield an lvalue equivalent to the original.  Nothing suggests that
applying the address-of operator to a union may yield a pointer which
won't behave that way even if all uses of the resulting pointer come before
any other accesses to the object.

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

#107773

On 05/04/17 23:47, supercat@casperkitty.com wrote:
> On Wednesday, April 5, 2017 at 3:50:51 PM UTC-5, Keith Thompson wrote:
>> K&R2 was published about the same time the 1989 ANSI C standard
>> was published.  Of course it doesn't cover C99 or C11, but I think
>> it generally does a good job of covering ANSI C89.  Can you give
>> an example where it doesn't?
> 
> IIRC, the book says that on a typical platform, a "short" will be stored as
> two bytes and a "long" will be stored as four.  Nothing in the book suggests
> that writing to an aligned "long*" on such a platform will do anything
> other than storing a value in four bytes starting at the given address,
> or that reading an aligned "short*" will do anything other than reading
> a value from two bytes starting at the given address.  

Nothing in the book suggests that picking your nose and flicking it at
the teacher will get you thrown out of class.

The book defines a lot of things, but it leaves vastly more unsaid -
since it is a single small book and not a library.  Messing around with
accessing objects via pointers of different sizes is undefined
behaviour.  Modern C standards say so explicitly, K&R left it implicitly
undefined.

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

#107774

Le mercredi 5 avril 2017 22:50:51 UTC+2, Keith Thompson a écrit :
> Jean-Marc writes:
> > Le mercredi 5 avril 2017 13:10:17 UTC+2, Richard Bos a écrit :
> >> For someone who is already a programmer, but is a beginner at C, IYAM
> >> the best tutorial is still the original: Kernignan and Ritchie's The C
> >> Programming Language. But that's not legally available on-line.
> >
> > That's what I used to say until a few years ago I reread it and
> > noticed that although the second edition was not describing C as it is
> > practiced nowadays but K&R C with minimal syntax update to make it
> > syntactically acceptable to a C++ compiler used to compensate the lack
> > of C compilers accepting the language described by the then-future
> > standard.  It's a book of the 70's updated in the 80's and it feels.
> > Read it again and ask yourself: do you really recommend it to someone
> > who does not know C?
> 
> K&R2 was published about the same time the 1989 ANSI C standard
> was published.  Of course it doesn't cover C99 or C11, but I think
> it generally does a good job of covering ANSI C89.  Can you give
> an example where it doesn't?

I've not looked again at the book, so this is from memory.

What I remember was mainly not a bad description of the language(*), Although the use of reimplementation of standard library functions as example using their standard name will probably confuse a new comer and is one reason for which makes me consider that the revisions for the second edition were relatively minimal; and I remember a qsort with another prototype than the standard one.

My issues were mainly on the style of the examples, I remember that there was lot of things which I'd not want to be mimicked: main without return type nor parameters, declaring functions inside other functions, abuse of global variables and arbitrary limits.

(*) But I learned C years beforehand and in K&R.  With my initial background in basic, assembly and Fortran, I've the background expected by K&R and I'm a bad judge of the clarity of the description for people having a background in Java and Python which would be the current public.

Yours,

-- 
Jean-Marc

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

#107767

On 04/04/2017 11:38, MehdiAmini wrote:
> Hi,
>
> There are many C tutorials on Internet. Which do you think is a good 
> one for beginners?
>
>

For a beginner nothing can replace a good C, C++ or C# programming 
book.  You need to get your hands dirty and make mistakes to learn from 
these mistakes.  If you want to learn C# then Microsoft has 25 free 
videos which you can start with:

<https://mva.microsoft.com/en-US/training-courses/c-fundamentals-for-absolute-beginners-16169?l=Lvld4EQIC_2706218949>

Good luck.

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

#107775

On Wed, 5 Apr 2017 15:16:59 -0500
Real Troll <real.troll@trolls.com> wrote:

> For a beginner nothing can replace a good C, C++ or C# programming 
> book.  You need to get your hands dirty and make mistakes to learn from 
> these mistakes.  If you want to learn C# then Microsoft has 25 free 
> videos which you can start with:

Indeed. The best professor to learn the C programming language is your own
collection of mistakes with a book of authority such as K&R. There's no way to
learn anything without effort. The genius isn't a gift of nature, it's a work
of pleasure.

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

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

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

csiph-web