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.

Richard Heathfield

2017-04-04 13:10:23 UTC

Post by MehdiAmini
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

fir

2017-04-04 16:12:52 UTC

Post by Richard Heathfield

Post by MehdiAmini
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
<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

MehdiAmini

2017-04-05 12:19:02 UTC

Post by Richard Heathfield

Post by MehdiAmini
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
<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.

Alla

2017-04-05 13:41:33 UTC

Post by MehdiAmini

Post by Richard Heathfield

Post by MehdiAmini
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
<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

Stefan Ram

2017-04-08 21:10:53 UTC

Post by Richard Heathfield
The best C tutorial for beginners is a *reliable* tutorial.

BTW: I have published a German-language C course in the web:

http://www.purl.org/stefan_ram/pub/c-kurs

it has the following special properties:

- it is being written in German,

- it takes special care to slowly teach the
fundamentals for absolute beginners, but many advanced
topics are missing. So its not a complete C course,
but a course only on some fundamental parts of C.

- the first lessons are already more elaborated
(until lesson 720110 [8.3]) while other lessons
sometimes are only notes for the lecturer.

- its beginning (until chapter 11) was "tested" with
real participants in my courses in an adult
education center, so I was able to detect it when
something was not explained clear enough, and I then
tried to improve it by rewriting it or even
restructuring larger parts of the whole course.

Steve Carroll

2017-04-04 17:24:08 UTC

And in response Deplorable has nothing but an attempt to start a circus. Having to suffer the use of Mac is not what most want to do. You don't even have any idea what you are blubbering about. Who are you even talking to? Time to blame the Russians! Learn all about Steven Petruzzellis: <https://www.google.com/#q=Steven+Petruzzellis>. Spoken like a true Libertarian.

Only an idiot would deny the flooder is Deplorable, who is a demonstrable AppleScripter but I don't know if it could be used to get by Google's spam filters. Can you stop begging for my attention? Proof of the website skills of Sandman, Jonas Eklundh: <http://tmp.gallopinginsanity.com/sandman/sandman-archive.pdf>.

Deplorable's posts are nothing but an indecipherable mess.

Well... like I said, Only an idiot would deny the flooder is Deplorable, who is a self professed Automator user but I don't know if it could be used to get by Google's spam filters.

Do you think everyone who points out your trolling is evil?

-
E-commerce Simplified!

http://jonaseklundh.se
Jonas Eklundh Communication AB

Jonas Eklundh

2017-04-04 19:31:04 UTC

You don't even have any idea what you are blubbering about. Can you show the message ID of this post?

This is just an amusement of mine. You refuse to take responsibility for your own actions. Actions that are easily quoted and pointed out. He is as incompetent as KCIR2. Linux offers the least to the least.

What does it take to end this? What I do is certainly more efficient.

--
E-commerce Simplified!

Jonas Eklundh Communication AB

Richard Bos

2017-04-05 11:10:11 UTC

Post by MehdiAmini
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

j***@gmail.com

2017-04-05 12:55:22 UTC

Post by Richard Bos
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

fir

2017-04-05 15:01:21 UTC

Post by j***@gmail.com

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)

s***@casperkitty.com

2017-04-05 16:45:00 UTC

Post by j***@gmail.com
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.

Jean-Marc Bourguet

2017-04-05 18:04:46 UTC

Post by j***@gmail.com
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.

Post by s***@casperkitty.com
[...]

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

David Brown

2017-04-05 18:36:59 UTC

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.

s***@casperkitty.com

2017-04-05 21:26:04 UTC

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.

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.

David Brown

2017-04-06 07:41:48 UTC

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.

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

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

Post by s***@casperkitty.com
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.

Post by s***@casperkitty.com
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.

Post by s***@casperkitty.com
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.

s***@casperkitty.com

2017-04-06 14:53:24 UTC

Post by David Brown
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?

Post by David Brown
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.

Post by David Brown
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?

Scott Lurndal

2017-04-06 15:12:09 UTC

Post by David Brown
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.

Keith Thompson

2017-04-06 16:12:46 UTC

[...]

Post by s***@casperkitty.com
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-***@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"

Scott Lurndal

2017-04-06 16:20:44 UTC

Post by s***@casperkitty.com
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.

Post by Keith Thompson
http://cm.bell-labs.com/cm/cs/who/dmr/cman.pdf

Keith Thompson

2017-04-06 16:26:34 UTC

Post by s***@casperkitty.com
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

2017-04-06 18:53:26 UTC

Post by Keith Thompson

Post by s***@casperkitty.com
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/

Lew Pitcher

2017-04-06 16:26:24 UTC

Post by s***@casperkitty.com
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

Post by Keith Thompson
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

Scott Lurndal

2017-04-06 17:09:20 UTC

Post by Lew Pitcher

Post by s***@casperkitty.com
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".

s***@casperkitty.com

2017-04-06 17:37:24 UTC

Post by Scott Lurndal
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."

Scott Lurndal

2017-04-06 18:50:57 UTC

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

David Brown

2017-04-06 19:46:06 UTC

Post by David Brown
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.

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

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.

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.

Post by s***@casperkitty.com
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.

s***@casperkitty.com

2017-04-06 21:51:01 UTC

Post by David Brown
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.

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.

Post by s***@casperkitty.com
It is also a variation which, while there is no official standard for it,
is very widely supported.

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.

Post by David Brown
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.

Post by s***@casperkitty.com
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.

Some is, some isn't.

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?

Richard Bos

2017-04-09 13:42:17 UTC

Post by David Brown
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

Noob

2017-04-09 14:45:00 UTC

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

Post by Richard Bos
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.

David Brown

2017-04-09 14:50:07 UTC

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

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

Post by Richard Bos
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.

Post by Noob
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.

Noob

2017-04-09 15:06:03 UTC

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

Post by Richard Bos
I thought Linux and gcc had nothing to do with one another?
Make your mind up.

It's not clear what your point is.

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

Regards.

Richard Bos

2017-04-14 11:39:10 UTC

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

It's not clear what your point is.

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

Tim Rentsch

2017-04-17 00:41:30 UTC

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

It's not clear what your point is.

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

David Brown

2017-04-17 15:46:54 UTC

Post by Tim Rentsch

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

It's not clear what your point is.

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.

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

David Brown

2017-04-17 15:37:52 UTC

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

It's not clear what your point is.

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.

Post by Richard Bos
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.

Post by Richard Bos
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.

Post by Richard Bos
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.

Post by Richard Bos
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).

Post by Richard Bos
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.

s***@casperkitty.com

2017-04-17 16:19:17 UTC

Post by David Brown
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.

Keith Thompson

2017-04-05 20:50:45 UTC

Post by j***@gmail.com

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?

s***@casperkitty.com

2017-04-05 21:47:04 UTC

Post by Keith Thompson
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.

David Brown

2017-04-06 07:45:33 UTC

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.

j***@gmail.com

2017-04-06 08:57:24 UTC

Post by Keith Thompson

Post by j***@gmail.com

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?

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

Real Troll

2017-04-05 20:16:59 UTC

Post by MehdiAmini
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.

GOTHIER Nathan

2017-04-06 09:56:44 UTC

On Wed, 5 Apr 2017 15:16:59 -0500

Post by Real Troll
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

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.

Spiros Bousbouras

2017-04-06 14:14:28 UTC

On Tue, 4 Apr 2017 15:08:06 +0430

Post by MehdiAmini
Hi,
There are many C tutorials on Internet. Which do you think is a good one
for beginners?

To add a bit to this , is there an online tutorial or book which covers well the new
material (especially the multithreading stuff) of C11 ?

C-bot

2017-04-08 01:18:33 UTC

Post by Spiros Bousbouras
On Tue, 4 Apr 2017 15:08:06 +0430

Post by MehdiAmini
Hi,
There are many C tutorials on Internet. Which do you think is a good
one for beginners?

To add a bit to this , is there an online tutorial or book which covers
well the new material (especially the multithreading stuff) of C11 ?

You may want to check out:
http://icube-icps.unistra.fr/img_auth.php/d/db/ModernC.pdf

Spiros Bousbouras

2017-04-08 14:54:36 UTC

On Sat, 08 Apr 2017 01:18:33 GMT

Post by C-bot

Post by Spiros Bousbouras
On Tue, 4 Apr 2017 15:08:06 +0430

Post by MehdiAmini
Hi,
There are many C tutorials on Internet. Which do you think is a good
one for beginners?

To add a bit to this , is there an online tutorial or book which covers
well the new material (especially the multithreading stuff) of C11 ?

http://icube-icps.unistra.fr/img_auth.php/d/db/ModernC.pdf

This looks very nice , thank you. It even has a final chapter where

On this level I will try to give my vision of future developments of C.
The idea is that they should be driven by a need, should be easy to
implement and should only make minimal changes. Certainly these three
criteria are subjective, but my hope is that this will somehow lead to
some consensus of what is to be included and what would be extensions.

I hope it comes out in printed form.

Ben Bacarisse

2017-04-08 18:01:21 UTC

Post by C-bot

Post by Spiros Bousbouras
On Tue, 4 Apr 2017 15:08:06 +0430

Post by MehdiAmini
Hi,
There are many C tutorials on Internet. Which do you think is a good
one for beginners?

To add a bit to this , is there an online tutorial or book which covers
well the new material (especially the multithreading stuff) of C11 ?

http://icube-icps.unistra.fr/img_auth.php/d/db/ModernC.pdf

This is good, but I'm not sure I'd call it a tutorial. If the OP can
get along with it and does not mind the length then it's a fine
resource, but I can see it being hard going for some as well as being
rather intimidatingly long.

--
Ben.

Stefan Ram

2017-04-08 21:05:06 UTC

Post by Ben Bacarisse
This is good, but I'm not sure I'd call it a tutorial. If the OP can
get along with it and does not mind the length then it's a fine
resource, but I can see it being hard going for some as well as being
rather intimidatingly long.

So, a teaching text has to be small to be called "tutorial"?

(I always wondered what the difference between a "tutorial"
and other forms of texts that attempt to teach something is.)

Ben Bacarisse

2017-04-08 23:04:20 UTC

Post by Stefan Ram

So, a teaching text has to be small to be called "tutorial"?

I'd say so, yes. I'd call a really long tutorial a textbook.

<snip>

--
Ben.

Jean-Marc Bourguet

2017-04-09 12:03:34 UTC

Post by Stefan Ram

So, a teaching text has to be small to be called "tutorial"?
(I always wondered what the difference between a "tutorial"
and other forms of texts that attempt to teach something is.)

For me tutorial is not related to length, but to the style. A tutorial has
an hand on approach and will usually explain little more than what is
needed for the current sub-task and quite often will not even explain
everything for that. They are usuful for two purposes:

- for people who have absolutely no experience, it gives a feeling of the
whole, but afterwards one need to come back in a more structured way on
each of the aspects. It's a way of breaking dependency loops in
explanations.

- for people having experience: they are able to guess the missing parts or
directly understand the reference documentation

Contrast this with an other style for teaching material which is to explain
first the concepts and how they relate, before showing how that is
articulated in the system. That's usually too abstract if you have no
experience and if you have experience, it is quite tedious to follow yet
another explanation of concepts you already master. Thus the success of
tutorials. Sadly far too often the structured explanation that you'd like
to have after a tutorial if you have no experience is missing. And that
leave you without good sources as reference materials tend to digg into all
the details while omiting the concept explanation which would allow you to
understand those details.

Yours,

--
Jean-Marc

Joe Pfeiffer

2017-04-09 21:02:29 UTC

For me, a tutorial is more of a self-contained how-to for a particular
task or concept. A single tutorial covering all of C seems like an odd
idea to me; I could imagine a series of a bunch of tutorials covering
the language, though.

Chris M. Thomasson

2017-04-09 21:13:35 UTC

Post by Joe Pfeiffer
For me, a tutorial is more of a self-contained how-to for a particular
task or concept. A single tutorial covering all of C seems like an odd
idea to me; I could imagine a series of a bunch of tutorials covering
the language, though.

Fwiw, I created a tutorial for a form of fractal encryption, but its not
enough to teach the reader wrt knowing the ins and outs of the deeper
details wrt whats going on:

https://github.com/ChrisMThomasson/fractal_cipher/blob/master/FFE/Pre-Alpha%20Rough%20Draft%20FFE%20Tutorial.pdf

This is not enough.

Real Troll

2017-04-09 21:30:00 UTC

A Tutorial is something that teaches you how to do things rather than
getting bogged down into why you do things. You want new learners to
start doing things without knowing why they are doing it. That is how
children learn and I don't see why adults can't learn the same way.

Richard Heathfield

2017-04-10 17:35:45 UTC

Post by Stefan Ram

So, a teaching text has to be small to be called "tutorial"?

I wouldn't say so. Tutorials generally err on the side of being too
short. For printed books this is understandable. For online tutorials
it's incomprehensible.

Post by Stefan Ram
(I always wondered what the difference between a "tutorial"
and other forms of texts that attempt to teach something is.)

I suspect that a more important distinction is that of "tutorial"
against "reference".

Both are important.

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

Steve Carroll

2017-04-08 19:44:05 UTC

That's right Silver Slimer!

How Snit screwed up: <http://www.5z8.info/php-start_GPS_tracking-user_f8h9lv_-OPEN-WEBCAM---START-RECORD-->. Marek created at least twenty virtual machines in the last year or so. I bet nobody else has ever done that. Why would you want to limit all programs on Linux to what can be done on on Windows and macOS? I suspect you do not even know what is wrong with the MSM. Silver Slimer just wiped his ass with Snit. You likely think Mint handles the desktop well. Nope. Not compared to the competition.

This is just an amusement of mine.

--
I Left My Husband & Daughter At Home And THIS happened!!
https://www.facebook.com/JonasEklundh
Jonas Eklundh

Steven Petruzzellis

2017-04-09 19:48:40 UTC

Usenet is a self-governing institution based on the honor system. Invalid CSS shown on sandman.net

<div style="padding: 3px; align: center;">

Same errors noted at the time (proving not from WBM changes):

Message-ID: <C0A30BB5.502C7%***@CABLE0NE.NET.INVALID>
-----
Line: 373
Property align doesn't exist : center
Line: 412
Property align doesn't exist : center
Line: 431
Property align doesn't exist : center
-----

Jonas Eklundh lied. Period.

Marek's computer has more hard drives than Snit's. Marek wins. Snit loses. So take that, Snit. Marek's computer has more hard drives than Snit's. Marek wins. Snit loses. Any questions?

And in response you have nothing but an attempt to start a circus. Do you even believe the nonsense you are spewing?

You're clueless!

Someone's passed old text through Google translate with the Viterbi algorithm to regurgitate posts which are hard to distinguish from my posts. Proof of the website skills of Sandman, Jonas Eklundh: <Loading Image...

>.

Puppy Videos
http://www.5z8.info/hateminorities_t7l3gt_linked-in-of-sex
http://www.5z8.info/freeanimalporn.com-start-download_s9j7do_dogporn
Jonas Eklundh Communication

Jonas Eklundh

2017-04-10 02:05:32 UTC