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 1 of 3  [1] 2 3  Next page →

#107728 — Reliable C tutorial for beginners

Hi,

There are many C tutorials on Internet. Which do you think is a good one 
for beginners?


-- 
www.my-c-codes.com/

Farewell.

[toc] | [next] | [standalone]

#107734

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

The best C tutorial for beginners is a *reliable* tutorial.

The most reliable tutorial I know of is Tom Torfs's tutorial, which can 
be found here:

<http://cprog.tomsweb.net/cintro.html>

-- 
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within

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

#107736

W dniu wtorek, 4 kwietnia 2017 15:10:31 UTC+2 użytkownik Richard Heathfield napisał:
> On 04/04/17 11:38, MehdiAmini wrote:
> > Hi,
> >
> > There are many C tutorials on Internet. Which do you think is a good one
> > for beginners?
> 
> The best C tutorial for beginners is a *reliable* tutorial.
> 
> The most reliable tutorial I know of is Tom Torfs's tutorial, which can 
> be found here:
> 
> <http://cprog.tomsweb.net/cintro.html>
> 
watching from this example 

/* prog14-1.c: vararg */

#include <stdio.h>
#include <stdarg.h>

int sumintegers(int numbers, ...)
{
   va_list vl;
   int i;
   int sum;

   va_start(vl,numbers);

   sum = 0;
   for (i=0; i<numbers; i++)
      sum += va_arg(vl,int);

   va_end(vl);

   return sum;
}

int main(void)
{
   int a,b;

   printf("Sum #1 = %d\n",
          sumintegers(10,1,2,3,5,7,9,11,13,17,19));

   a = 100;
   b = 200;

   printf("Sum #2 = %d\n",
          sumintegers(2,a,b));

   return 0;
}

it may be in fact good, (teaching me something i dont know, i usualy used only varargs for strings not for pure ints)

varargs in fact have some undiscovered potential imo, but could be maybe done somewhat nicer for example i would like to write varagr min function that i copuld call just

int a = min(1,2,3,4);
int b = min(4, 3, 1, 2, 3, 4, 8, 10, -3);

to do so one would need maybe a bit other semanting and syntax for passing and accesing thiose passed values (and maybe something for type controll)

int min(int[n] arg)  //this is vararg
{
   int minimal = arg[0];

   for(int i=1; i<n; i++)
   { 
    if(arg[i]<minimal) minimal = arg[i];
   }

  return minimal;
}

this above looks like normal array pasing 
and im not sure if there some other syntax should be used
to emphasize the difference or just the same but
allowing just tp ass ad-hoc arrays like also normal ones

int tab = {4,7,2,5,90};
int m = min(tab);

int n = min({4,7,2,5,90}); // (1)
or
int n = min(4,7,2,5,90); //?  (2)


(1) seems safest as (2) suggests 5 values are passed instead of two (tab adress and count/size) but in fact it can go another way and suggest that (2) should not be treated as passing 5 values but more like those two (so maybe (2) is in fact better, the main diference is only if this given function takes arg statically (always 5 ints) or dynamically (n -ints) or yet hiper dynamically (various stuff))

thiose varargs as it is seen can be in two categories 
1)(arrays of n-items of given statically known type)
2) various 'tuples' on non statically identified type

id those sizes or types are not known statically it
should be pass dynamically, and here are two ways, explicit passes (like there in present c) or implicit
passes (like in the example above)

im like liking both of them, in this int[n] case
it seems that implicit pass is not a problem as this
implicit is somewhat also explicit pass of full array
(which may be also adhoc) so it seems not to be 
to much a violation of 'rules of being explicit'

as to this hiper-mixed case im not sure right now

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

#107756

On 04/04/2017 05:40 PM, Richard Heathfield wrote:
> On 04/04/17 11:38, MehdiAmini wrote:
>> Hi,
>>
>> There are many C tutorials on Internet. Which do you think is a good one
>> for beginners?
>
> The best C tutorial for beginners is a *reliable* tutorial.
>
> The most reliable tutorial I know of is Tom Torfs's tutorial, which can
> be found here:
>
> <http://cprog.tomsweb.net/cintro.html>
>

I searched Internet for "C tutorial", unfortunately this tutorial is not 
on the first page of several search engines that I used.

-- 
www.my-c-codes.com/

Farewell.

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

#107758

On 4/5/17 15:19, MehdiAmini wrote:
> On 04/04/2017 05:40 PM, Richard Heathfield wrote:
>> On 04/04/17 11:38, MehdiAmini wrote:
>>> Hi,
>>>
>>> There are many C tutorials on Internet. Which do you think is a good one
>>> for beginners?
>>
>> The best C tutorial for beginners is a *reliable* tutorial.
>>
>> The most reliable tutorial I know of is Tom Torfs's tutorial, which can
>> be found here:
>>
>> <http://cprog.tomsweb.net/cintro.html>
>>
>
> I searched Internet for "C tutorial", unfortunately this tutorial is not
> on the first page of several search engines that I used.
>

I am sorry for interfering but are you looking for a reliable tutorial, 
and for recommendations from the best professionals in the field, or are 
you looking for a tutorial, or information, that your desirable search 
engine will show as the "top notch" one? Please, be more precise about 
what you are asking about. Also, if you evaluate the quality and 
reliability of any topic based on the results of, for example, google 
search, then why do you ask for recommendations in a professional group?

-- 
Respectfully,
Alla

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

#107755

MehdiAmini <atorrses@gmail.com> wrote:

> There are many C tutorials on Internet. Which do you think is a good one 
> for beginners?

I know of no good C tutorials for beginning programmers, and in fact
IMAO beginning programmers should be learning Pascal or a similarly
hard-structure language, and definitely not C. C was designed for
programmers with a decent amount of experience.

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.

Richard

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

#107757

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?

Yours,

-- 
Jean-Marc

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

#107760

W dniu środa, 5 kwietnia 2017 14:55:46 UTC+2 użytkownik jm.bo...@gmail.com napisał:
> 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?
> 
the book and tutorial that teaches c usualy enumerates/mentions what expressions you van use in c
etc but it also presents some attitude to language 
- and this attitude presented in k&R is imo quite bad
(at least to me, i could say it even boring, heavily boring), 
this tutorial mentioned it far better to me (more lighthweight and not boring)

besides that k&R examples are with quite bad style naming, (and overal bad style uncoherent pieces of partial illustrations on something not real finitecodes ) yet besides that all this not teaches really how to code with c (k&r is sooo sad book to me)

c is not so unappropriate for learning language for beginers (ofc it has some disadvantages, mainly [1] this all problems with wierid &/* passing and problems with alocating dynamic sizes (which was discussed could in fact be totally improved finaly but needs changing tle 
language) 
yet  [2] with lack of standard simple easy library that would allow to code some simple graphics not only c-lib on console (clib is weird lib 2b honest)

improved c oversimple fine library would be ideal hovever

PS getting back to the previous digreesion on how to potentially improve varargs (and talking on this more hyper-variable case (those previous min examples in fact could be treated as not a varargs, but just normal array expecting functions with some adhoc passing mechanism))

with this hyper-variable case some block of memory would be passed as arguments, and also type info should be passed, question if to pass it explicitelly or implicitely.. probbaly both version could be used, i mean programmer should tell eplicitely if to pass it implicitelly or not (i tried to decide something more on this cases but failed, so maybe later ;c)

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

#107762

On Wednesday, April 5, 2017 at 7:55:46 AM UTC-5, jm.bo...@gmail.com wrote:
> 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?

There is no single "C as it is practiced nowadays".  C is the name given to
a set of languages which are diverging into two camps that might be called
"automatically optimizable C" and "low-level C".  There is no reason the two
camps should have had to diverge so badly, since it should have been possible
for a single language to define as optional the features necessary to support
low-level programming (but say that an implementation must *either* support
the features or report that it doesn't do so).  Obviously that hasn't happened
as yet, however.

C was designed as a language where the behavior of "foo->bar = 4" was
*defined* as taking the address in foo, add the offset of "bar", and store
the value 4 at the resulting address via whatever means the underlying
platform would use to store a value of bar's type, and it would do so
without regard for how that storage might have been used for in the past
or future.  Code which know how an underlying platform behaves could make
use of that knowledge to do variety of things that could otherwise not be
done as efficiently, if at all.

Anyone seeking to work with low-level programs needs to understand how
low-level constructs work on platforms that support them, and also learn
the importance of ensuring that a construct will be supported not only by
a hardware platform, but also by whatever compiler one is using.  K&R is
a decent book for learning about how the low-level constructs work, but I
don't know of any book that demonstrates all the constructs that used to
work but aren't reliable on "modern" processors unless optimizations are
disabled.

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

#107764

supercat@casperkitty.com writes:

> On Wednesday, April 5, 2017 at 7:55:46 AM UTC-5, jm.bo...@gmail.com wrote:
>> 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?
>
> There is no single "C as it is practiced nowadays".

Where did I say that there was a single one.  There is a set of practices,
which have common aspects.  An those differ when compared to the common
aspects of the practices of the late 80's early 90's.

> [...]

If you had taken the effort to re-read K&R with the "do I want to recommend
this to new comers to C" mindset, you'd have seen that the points I was
speaking about have nothing to do with your pet peeve.

Yours,

-- 
Jean-Marc

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

#107766

On 05/04/17 18:45, supercat@casperkitty.com wrote:
> On Wednesday, April 5, 2017 at 7:55:46 AM UTC-5, jm.bo...@gmail.com wrote:
>> 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?
>
> There is no single "C as it is practiced nowadays".  C is the name given to
> a set of languages which are diverging into two camps that might be called
> "automatically optimizable C" and "low-level C".  There is no reason the two
> camps should have had to diverge so badly, since it should have been possible
> for a single language to define as optional the features necessary to support
> low-level programming (but say that an implementation must *either* support
> the features or report that it doesn't do so).  Obviously that hasn't happened
> as yet, however.
>
> C was designed as a language where the behavior of "foo->bar = 4" was
> *defined* as taking the address in foo, add the offset of "bar", and store
> the value 4 at the resulting address via whatever means the underlying
> platform would use to store a value of bar's type, and it would do so
> without regard for how that storage might have been used for in the past
> or future.  Code which know how an underlying platform behaves could make
> use of that knowledge to do variety of things that could otherwise not be
> done as efficiently, if at all.
>
> Anyone seeking to work with low-level programs needs to understand how
> low-level constructs work on platforms that support them, and also learn
> the importance of ensuring that a construct will be supported not only by
> a hardware platform, but also by whatever compiler one is using.  K&R is
> a decent book for learning about how the low-level constructs work, but I
> don't know of any book that demonstrates all the constructs that used to
> work but aren't reliable on "modern" processors unless optimizations are
> disabled.
>

There is no such book, because the C language you believe in never 
existed.  These constructs that you think "used to work", only happened 
to work because compilers of years gone by were not as sophisticated as 
modern ones - the language was /never/ designed to work the way you 
think it was.  You are not the only person to think that C was designed 
to be a "portable assembler" and "translate directly to obvious assembly 
code" - but that does not make you right.

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

#107770

On Wednesday, April 5, 2017 at 1:37:12 PM UTC-5, David Brown wrote:
> On 05/04/17 18:45, supercat wrote:
> > On Wednesday, April 5, 2017 at 7:55:46 AM UTC-5, jm.bo...@gmail.com wrote:
> >> 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?
> >
> > There is no single "C as it is practiced nowadays".  C is the name given to
> > a set of languages which are diverging into two camps that might be called
> > "automatically optimizable C" and "low-level C".  There is no reason the two
> > camps should have had to diverge so badly, since it should have been possible
> > for a single language to define as optional the features necessary to support
> > low-level programming (but say that an implementation must *either* support
> > the features or report that it doesn't do so).  Obviously that hasn't happened
> > as yet, however.
> >
> > C was designed as a language where the behavior of "foo->bar = 4" was
> > *defined* as taking the address in foo, add the offset of "bar", and store
> > the value 4 at the resulting address via whatever means the underlying
> > platform would use to store a value of bar's type, and it would do so
> > without regard for how that storage might have been used for in the past
> > or future.  Code which know how an underlying platform behaves could make
> > use of that knowledge to do variety of things that could otherwise not be
> > done as efficiently, if at all.
> >
> > Anyone seeking to work with low-level programs needs to understand how
> > low-level constructs work on platforms that support them, and also learn
> > the importance of ensuring that a construct will be supported not only by
> > a hardware platform, but also by whatever compiler one is using.  K&R is
> > a decent book for learning about how the low-level constructs work, but I
> > don't know of any book that demonstrates all the constructs that used to
> > work but aren't reliable on "modern" processors unless optimizations are
> > disabled.
> >
> 
> There is no such book, because the C language you believe in never 
> existed.  These constructs that you think "used to work", only happened 
> to work because compilers of years gone by were not as sophisticated as 
> modern ones - the language was /never/ designed to work the way you 
> think it was.  You are not the only person to think that C was designed 
> to be a "portable assembler" and "translate directly to obvious assembly 
> code" - but that does not make you right.

How does the 1974 C reference manual describe the behavior of struct member
access?

What is Linux written in?  Or does Linux not exist?

What language is used for code that allocates and recycles memory, or
performs memory moves that involve potentially-overlapping ranges, but
which needs to run on freestanding implementations that do not supply
malloc() or memmove()?  Or do such programs not exist?

You may never have need to do anything that can't be done without using
any behaviors beyond those mandated by the Standard.  Other people do need
to do such things, and many compiler writers recognize such needs.  The
authors of the Standard deliberately refrained from requiring that all
implementations be suitable for low-level programming; a judgment that
there might exist some combinations of platforms and application fields
where the value of defining a behavior would not exceed the cost should
not be taken as a judgment that there are not other combinations where
the value of defining a behavior would vastly exceed the cost.

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

#107772

On 05/04/17 23:26, supercat@casperkitty.com wrote:
> On Wednesday, April 5, 2017 at 1:37:12 PM UTC-5, David Brown wrote:
>> On 05/04/17 18:45, supercat wrote:
>>> On Wednesday, April 5, 2017 at 7:55:46 AM UTC-5, jm.bo...@gmail.com wrote:
>>>> 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?
>>>
>>> There is no single "C as it is practiced nowadays".  C is the name given to
>>> a set of languages which are diverging into two camps that might be called
>>> "automatically optimizable C" and "low-level C".  There is no reason the two
>>> camps should have had to diverge so badly, since it should have been possible
>>> for a single language to define as optional the features necessary to support
>>> low-level programming (but say that an implementation must *either* support
>>> the features or report that it doesn't do so).  Obviously that hasn't happened
>>> as yet, however.
>>>
>>> C was designed as a language where the behavior of "foo->bar = 4" was
>>> *defined* as taking the address in foo, add the offset of "bar", and store
>>> the value 4 at the resulting address via whatever means the underlying
>>> platform would use to store a value of bar's type, and it would do so
>>> without regard for how that storage might have been used for in the past
>>> or future.  Code which know how an underlying platform behaves could make
>>> use of that knowledge to do variety of things that could otherwise not be
>>> done as efficiently, if at all.
>>>
>>> Anyone seeking to work with low-level programs needs to understand how
>>> low-level constructs work on platforms that support them, and also learn
>>> the importance of ensuring that a construct will be supported not only by
>>> a hardware platform, but also by whatever compiler one is using.  K&R is
>>> a decent book for learning about how the low-level constructs work, but I
>>> don't know of any book that demonstrates all the constructs that used to
>>> work but aren't reliable on "modern" processors unless optimizations are
>>> disabled.
>>>
>>
>> There is no such book, because the C language you believe in never 
>> existed.  These constructs that you think "used to work", only happened 
>> to work because compilers of years gone by were not as sophisticated as 
>> modern ones - the language was /never/ designed to work the way you 
>> think it was.  You are not the only person to think that C was designed 
>> to be a "portable assembler" and "translate directly to obvious assembly 
>> code" - but that does not make you right.
> 
> How does the 1974 C reference manual describe the behavior of struct member
> access?

I don't know - I don't have that book.

> 
> What is Linux written in?  Or does Linux not exist?

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

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.

The most common compiler used these days for embedded development is
gcc.  The flag "-fno-strict-alias" is not commonly used.  People write C
code for operating systems that are portable across wide ranges of
systems, from small 8-bit to large 32-bit devices, certified for high
reliability or critical safety systems, using standard portable C for
all but a minimal "target abstraction" layer.  And they do it without
"-fno-strict-alias".

Linux could also be changed to avoid the need of "-fno-strict-alias",
but it would need changes to the style of some parts of the code.  And
Linus Torvalds gets upset when someone tells him to change style.

> 
> What language is used for code that allocates and recycles memory, or
> performs memory moves that involve potentially-overlapping ranges, but
> which needs to run on freestanding implementations that do not supply
> malloc() or memmove()?  Or do such programs not exist?

Such programs are rare - and they rely on implementation-specific
features, not guarantees of the C language (now or in the past).  There
are parts of the C library that cannot be implemented in pure standard C
- you use implementation-specific features.  The same applies to code
like this.  People may write it /assuming/ it works, or /assuming/ it is
portable C, or without checking the implementation-specific details -
you are not the only programmer to be convinced that C works the way
/you/ think it should work.

> 
> You may never have need to do anything that can't be done without using
> any behaviors beyond those mandated by the Standard.  Other people do need
> to do such things, and many compiler writers recognize such needs.  The
> authors of the Standard deliberately refrained from requiring that all
> implementations be suitable for low-level programming; a judgment that
> there might exist some combinations of platforms and application fields
> where the value of defining a behavior would not exceed the cost should
> not be taken as a judgment that there are not other combinations where
> the value of defining a behavior would vastly exceed the cost.
> 

I work all the time with implementation-specific code.  My code
regularly makes assumptions about the implementation - assumptions that
I know to be true on any of the targets (usually just one) that the code
in question will run on.  Much of what I write is, of course, fairly
"normal" portable standard C - but there are bits here and there that
require a close knowledge of the compiler and its implementation
details.  The authors of the C standards, following on from earlier
practice, deliberately made it clear that the /implementation/ can
define the behaviour and features needed to write code such low-level or
maximally efficient code - but that such things are optional, and are
not defined as part of the C language, and can be done in different ways
on different compilers.

C is specifically designed to allow two types of code - general,
portable, high-level code relying only on a common standard, and code
that is tied closely to the machine and a particular implementation of C.

Your key problem is that you think that "in the good old days", common
standard portable C let you write code of this second form - and you are
simply wrong about that.

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

#107779

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?

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

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

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?

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

#107783

supercat@casperkitty.com writes:
>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?

The BSTJ article was in 1978, IIRC, wherein C was introduced to the
world.

The V6 C compiler from that era treated struct member names (MOS) as top-level
symbol table items, so the field name could be used with any pointer,
not just a pointer to the specific structure type that contains the
field.

Hence prefixes such as st_mode et alia in struct stat.

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

#107786

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
    http://cm.bell-labs.com/cm/cs/who/dmr/cman.pdf

[...]

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

#107787

Keith Thompson <kst-u@mib.org> writes:
>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

Hope someone grabbed copies.

$ (cd /tmp; wget http://cm.bell-labs.com/cm/cs/who/dmr/cman74.pdf)
--2017-04-06 09:18:49--  http://cm.bell-labs.com/cm/cs/who/dmr/cman74.pdf
Resolving cm.bell-labs.com (cm.bell-labs.com)... 135.104.24.16
Connecting to cm.bell-labs.com (cm.bell-labs.com)|135.104.24.16|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
2017-04-06 09:18:50 ERROR 404: Not Found.

$ (cd /tmp; wget http://cm.bell-labs.com/cm/cs/who/dmr/cman.pdf)  
--2017-04-06 09:19:38--  http://cm.bell-labs.com/cm/cs/who/dmr/cman.pdf
Resolving cm.bell-labs.com (cm.bell-labs.com)... 135.104.24.16
Connecting to cm.bell-labs.com (cm.bell-labs.com)|135.104.24.16|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
2017-04-06 09:19:38 ERROR 404: Not Found.

>    http://cm.bell-labs.com/cm/cs/who/dmr/cman.pdf

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

#107789

scott@slp53.sl.home (Scott Lurndal) writes:
> Keith Thompson <kst-u@mib.org> writes:
>>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
>
> Hope someone grabbed copies.
[...]

The URLs have changed at least once before.  I'm not sure whether the
ones I posted are current.  I'll check later today.

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

#107793

Keith Thompson <kst-u@mib.org> writes:
> scott@slp53.sl.home (Scott Lurndal) writes:
>> Keith Thompson <kst-u@mib.org> writes:
>>>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
>>
>> Hope someone grabbed copies.
> [...]
>
> The URLs have changed at least once before.  I'm not sure whether the
> ones I posted are current.  I'll check later today.

Those were the wrong URLs.  The current ones are:

Jan 1974 C reference manual:
    https://www.bell-labs.com/usr/dmr/www/cman74.pdf
May 1975 C reference manual (6th Edition Unix):
    https://www.bell-labs.com/usr/dmr/www/cman.ps
    https://www.bell-labs.com/usr/dmr/www/cman.pdf
Kernighan's tutorial:
    https://www.bell-labs.com/usr/dmr/www/ctut.ps
    https://www.bell-labs.com/usr/dmr/www/ctut.pdf

All these links are from the late Dennis Ritchie's home page, currently
available at:

    https://www.bell-labs.com/usr/dmr/www/

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

#107788

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

>     http://cm.bell-labs.com/cm/cs/who/dmr/cman.pdf
Now found at https://www.bell-labs.com/usr/dmr/www/cman.pdf

And, Dennis Ritchie's web page is now found at
  https://www.bell-labs.com/usr/dmr/www/


-- 
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request

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

Page 1 of 3  [1] 2 3  Next page →

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

csiph-web