I need your advices about C prg.

[Dogukan Bayraktar]

Hi there!

Firstly, sorry for my bad English :/

I'm only 17 and I want to learn C and write perfect codes in C. I'm not so good in C programming, but I want to become a good C programmer.

My English is not enough to read the programming articles or anything.
What should I do to become a good C programmer?

- Do you think is English needed for programming?
- What should I learn in C to become a good programmer?
- Should I read the example C codes in the web?
- etc ... ?

I've been waiting your answers.. Please answer to my questions as soon as possible..

* Thanks ~ !

[Jens Stuckelberger]

As a non-native English speaker myself I have to say that your
written English is not so bad; mine was certainly worse when I was 17. If
you can read English as you can write it you should be able to learn from
any standard textbook on C. Don't be afraid and try it. I am sure other
members of this forum, far more C-knowledgeable than me, will give you
relevant references.

[James Kuyper]

On 04/24/2013 03:30 PM, Dogukan Bayraktar wrote:
> Hi there!
>
> Firstly, sorry for my bad English :/
>
> I'm only 17 and I want to learn C and write perfect codes in C. I'm not so good in C programming, but I want to become a good C programmer.

Trying for "perfect" is just setting yourself up for a lifetime of
disappointment. "good", on the other hand, is quite feasible. I
recommend trying to become an "expert" C programmer; it's an achievable
but challenging goal.

> My English is not enough to read the programming articles or anything.
> What should I do to become a good C programmer?

Finding a forum in your native language devoted to C programming would
be best. Depending upon what language that is, that might be difficult,
bordering on impossible. You might have to improve your English. My
wife's native language is Mandarin, and she's studying accounting. The
hardest part for her isn't the math, but the fact that all of the text
books are written in a very advanced, technically oriented dialect of
English. I suspect you'll have similar trouble with C if you can't find
good text books in your native language.

> - Do you think is English needed for programming?

It shouldn't be - but as I'm a native speaker of English I wouldn't have
noticed if there are serious barriers for non-English speakers. I gather
that there's a fair number of French, German, Russian, Chinese and
Japanese C programmers, so it should be possible to find good texts in
any of those languages, but I can't tell you which ones. There's a lot
of Indian programmers out there, but as far as I can tell they all seem
to have bad things to say about the opportunities for learning
programming that were available to them in India. I'm not sure about any
other languages. I've no idea whether the standard is available in other
languages - as an International standard, it should be, but I can't
remember having ever heard of a translation into any other language.

> - What should I learn in C to become a good programmer?

In the beginning, you'll be spending a lot of time learning how C works,
but that's just learning what the tools of your trade are. To become
good at programming, you need to know the best things to do with those
tools. I think that the most important things are good design and a
disciplined product development cycle. That's true for any programming
language, it isn't specific to C. A good developer will use C only for
tasks for which it's a good choice, and will adapt the design to take
into account the ways that C differs from other languages, but the most
basic principles of good design are pretty much language independent.

> - Should I read the example C codes in the web?

Example code is useful only if you have good reason to believe it's well
written. Badly written C code can teach you a lot of bad habits, and
there's a lot more badly written C code out there, than well-written.

[Dogukan Bayraktar]

24 Nisan 2013 Çarşamba 23:00:51 UTC+3 tarihinde Jens Stuckelberger yazdı:

Thanks for your comment :)

[Dogukan Bayraktar]

24 Nisan 2013 Çarşamba 23:35:58 UTC+3 tarihinde James Kuyper yazdı:

Thank you so much! I have learned a lot of things about English and C Programming :D

Your comment is so helpful for me..
~~ Thanks again :) ~~

[Keith Thompson]

Dogukan Bayraktar <dg28...@gmail.com> writes:
> Firstly, sorry for my bad English :/

It's certainly better than my anything-other-than-English.

Q: What do you call someone who speaks two languages?
A: Bilingual.
Q: What do you call someone who speaks only one language?
A: American.

> I'm only 17 and I want to learn C and write perfect codes in C. I'm
> not so good in C programming, but I want to become a good C
> programmer.
>
> My English is not enough to read the programming articles or anything.
> What should I do to become a good C programmer?
>
> - Do you think is English needed for programming?
> - What should I learn in C to become a good programmer?
> - Should I read the example C codes in the web?
> - etc ... ?

One small piece of advice: if a book or tutorial tells you that

void main()

is correct, avoid it. It's not a huge deal by itself (many
compilers will accept it, and it's easy enough to change to the
correct "int main(void)" in your own code), but it's a sign that
the author really doesn't know the language very well.

("void main()" can actually be valid in some circumstances,
particularly for embedded systems, but you're not likely to be
using such systems.)

--
Keith Thompson (The_Other_Keith) ks...@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"

[David Brown]

"void main(void)" is preferable in most embedded systems - you want to
explicitly say it has no arguments. Of course, it's a different matter
if you intend to return from main or pass arguments to it, but in most
small embedded systems main() never exits.

Depending on the situation, I would say you are actually quite likely to
be working on embedded systems if you are programming in C. After all,
the great majority of embedded systems are coded in C (followed by C++),
and there are a great many embedded systems out there. In the PC world,
other languages are often used - there are relatively few situations
where C is the best choice of language on a PC.

[David Brown]

English is not needed for programming - but it /is/ needed to be an
expert as will then have to read technical texts, standards, etc., as
well as work with existing source code and documentation from around the
world. Fair or not, English is the standard here. Even for programming
languages created and developed outside

But judging from your post here, your English is already better than
many adult native speakers, so don't worry about it. I'm sure there is
room for improvement, but that will come as you get more education, and
read and write more.

Incidentally, what is your native language?

As for becoming a good C programmer, the first question is /why/? If
you want to become a good programmer, C is not necessarily a good choice
for starting. The field of programming is vast - C is only suitable for
a small part of that. What sort of programming are you actually
interested in?

[Johannes Bauer]

On 25.04.2013 11:44, David Brown wrote:

> "void main(void)" is preferable in most embedded systems - you want to
> explicitly say it has no arguments. Of course, it's a different matter
> if you intend to return from main or pass arguments to it, but in most
> small embedded systems main() never exits.

"main" has a return parameter which is an int. Always.

> Depending on the situation, I would say you are actually quite likely to
> be working on embedded systems if you are programming in C. After all,
> the great majority of embedded systems are coded in C (followed by C++),
> and there are a great many embedded systems out there.

So because most embedded systems are programmed in C you conclude that
most C programms are for embedded systems? Something is seriously wrong
with your logic.

Regards,
Johannes

--
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?
> Zumindest nicht öffentlich!
Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
- Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$1...@speranza.aioe.org>

[James Kuyper]

On 04/25/2013 08:42 AM, Johannes Bauer wrote:
> On 25.04.2013 11:44, David Brown wrote:
>
>> "void main(void)" is preferable in most embedded systems - you want to
>> explicitly say it has no arguments. Of course, it's a different matter
>> if you intend to return from main or pass arguments to it, but in most
>> small embedded systems main() never exits.
>
> "main" has a return parameter which is an int. Always.

He was responding to a comment Keith made that was specifically about
the fact (and it is a fact) that some compilers do accept void main(),
despite what it says to the contrary in the C standard.

>> Depending on the situation, I would say you are actually quite likely to
>> be working on embedded systems if you are programming in C. After all,
>> the great majority of embedded systems are coded in C (followed by C++),
>> and there are a great many embedded systems out there.
>
> So because most embedded systems are programmed in C you conclude that
> most C programms are for embedded systems? Something is seriously wrong
> with your logic.

Only because you left out a key step in that logic: "there are a great
many embedded systems out there". That's not enough to prove that most C
programs are for embedded systems, but depending upon the number
corresponding to "a great many", it could be strong supporting evidence
for that claim.

In this newsgroup I've talked with a number of people who thought that
most, if not all, current C programming is being done for embedded
platforms. When challenged, none have been able to provide hard numbers
in support of their claim. To be fair, I know of no good source of
numbers to disprove the claim, either. But the simple fact that anybody
believes it is, in itself, evidence for the existence of a fairly large
amount of embedded C programming going on.
--
James Kuyper

[Stephen Sprunk]

On 24-Apr-13 16:39, Keith Thompson wrote:
> Dogukan Bayraktar <dg28...@gmail.com> writes:
>> Firstly, sorry for my bad English :/
>
> It's certainly better than my anything-other-than-English.
>
> Q: What do you call someone who speaks two languages?
> A: Bilingual.
> Q: What do you call someone who speaks only one language?
> A: American.

American monolingualism is overstated; the commonly-cited statistic from
the Census Bureau tracks only languages spoken at home (18% not
English), not how many languages people are _capable_ of speaking.

One of the problems that English-speaking countries have is there is no
obvious choice of second language for our students, whereas English is
an obvious (and now by far the most common) choice in other countries.
There are only a handful of other languages spoken by enough people to
be useful, and these days most people in those countries are learning
English now, so why bother?

The main exception to that is for people who achieve fluency in two (or
more) languages, which enables a career as a translator or diplomat. In
the US, that is generally limited to second-generation immigrants
because our schools (a) start students on foreign languages too late and
(b) can't provide a critical mass of native speakers for them to
practice with.

>> I'm only 17 and I want to learn C and write perfect codes in C. I'm
>> not so good in C programming, but I want to become a good C
>> programmer.
>>
>> My English is not enough to read the programming articles or
>> anything. What should I do to become a good C programmer?

Whether we like it or not, the programming world (and tech industry in
general) is dominated by English. If you don't know it at least well
enough to read articles, then working on that is essential, regardless
of which programming language you intend to use. User documentation and
interfaces are often localized, but systems and API documentation rarely
are.

On the plus side, you probably only need to learn to read and write
English, not speak it--though that would open up a huge number of job
opportunities for other reasons. I work with many programmers whose
accents are nearly incomprehensible to me, but their emails are clear
enough that it's not a barrier, and live conversations with them are
rare anyway due to time zone differences.

S

--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking

[Dogukan Bayraktar]

25 Nisan 2013 Perşembe 14:30:47 UTC+3 tarihinde David Brown yazdı:

Thanks for you comment :)

I'm from Turkey. So my native language is Turkish. But I want to learn English so much :)

I've been learning C for 5 months. But I want to improve my skills for C programming. I love C/C++ languages more than other languages like Java and C#.

I'm interested in C/C++, Python, PHP.

I hope you understand me :)

[Rui Maciel]

Stephen Sprunk wrote:

> One of the problems that English-speaking countries have is there is no
> obvious choice of second language for our students, whereas English is
> an obvious (and now by far the most common) choice in other countries.
> There are only a handful of other languages spoken by enough people to
> be useful, and these days most people in those countries are learning
> English now, so why bother?

From where I'm from, a foreign language (english) is included in the
national curriculum from the 1st grade, and a second foreign language from
the 7th grade onward.

For the second foreign language, students are free (technically*) to pick
from three available options -- german, french and spanish.

These choices are far from being "obvious", for a number of reasons. Yet,
people still choose and no one is harmed by it.

Regarding english-speaking countries, it can be argued that each one has its
glaring obvious choice.

- US: According to wikipedia[1], the country has 45 million people who speak
spanish as a first or second language. If we take into account that almost
all neighbouring countries to the south have spanish as their official
language, spanish does appear to be an obvious choice.
- Canada: it has two official languages: english and french.
- UK: even when ignoring their "regional" languages, the british isles do
have significant ties with France and Germany.

On top of that, if only less than 6% of the world are native english
speakers while over 14% speak Mandarin[2], in addition to China's increasing
prominence, Mandarin becomes a rather glaring choice.

Therefore, there are no obvious choices only to those who never bothered to
think about it.


Rui Maciel

[1] http://en.wikipedia.org/wiki/Spanish_language_in_the_United_States
[2]
http://en.wikipedia.org/wiki/List_of_languages_by_number_of_native_speakers

[David Brown]

On 25/04/13 14:42, Johannes Bauer wrote:
> On 25.04.2013 11:44, David Brown wrote:
>
>> "void main(void)" is preferable in most embedded systems - you want to
>> explicitly say it has no arguments. Of course, it's a different matter
>> if you intend to return from main or pass arguments to it, but in most
>> small embedded systems main() never exits.
>
> "main" has a return parameter which is an int. Always.

No, "main" does not always have a return parameter - "main" does not
always return, and therefore a return parameter is meaningless. In most
(small) embedded systems, main() never exits. Including a return
parameter may mean wasted code, and will mean your compiler and/or
static code checker will warn about unreachable code (if you include a
return value) or missing return values (if you don't).

Is such a "void main(void)" declaration valid according to the strictest
C conformance? Perhaps not - but then, most (probably all) embedded
compilers and embedded programs are non-conforming in at least a few
small ways. They often have C libraries with limitations, floating
point implementations that are not fully IEEE, extra keywords for
special memory handling, etc.

I also found this reference:
<http://c0x.coding-guidelines.com/5.1.2.2.1.html>

I don't know whether this is from an official standards document, but
point 167 clearly says that "main" can be defined "in some other
implemention-defined manner".

>
>> Depending on the situation, I would say you are actually quite likely to
>> be working on embedded systems if you are programming in C. After all,
>> the great majority of embedded systems are coded in C (followed by C++),
>> and there are a great many embedded systems out there.
>
> So because most embedded systems are programmed in C you conclude that
> most C programms are for embedded systems? Something is seriously wrong
> with your logic.

The error, I believe, is in your reading. I said there are a great many
programmers writing C for embedded systems.

There are a lot of embedded systems around, and hobby-level systems are
getting steadily more popular - it is now very easy to get started at
embedded programming in C. On the other hand, C programming on PC's or
other "big" systems is getting proportionally less popular - other
languages are taking a bigger slice of the market, and with good reason.

Do I think that most C programs are written for embedded systems? No, I
don't - that's why I did not say so.

But if someone tells me he wants to learn to program and asks what
language to use, I would only say "C" if it was for embedded systems.
If someone asks me what language is appropriate for a given project,
then the answer is seldom "C" - unless it is an embedded system, a very
low-level program, a high-speed library, or a very time-critical program
(even then C is often not the best choice).

I think this difference is particularly apparent in newer, younger
programmers. There was a time when people used C for everything from
small scripts or utilities to large applications - and people who are
used to that, continue to do so. But for a new developer, you would be
better off with Python, Java, Ruby, C++, etc.

Of course, being good at C programming is an essential skill for /any/
expert programmer, even if you do most of your work in other languages.
It's like having a good understanding of assembly is essential for
being an expert C programmer, especially on embedded systems.


>
> Regards,
> Johannes
>

[osmium]

"Rui Maciel" wrote:

> On top of that, if only less than 6% of the world are native english
> speakers while over 14% speak Mandarin[2], in addition to China's
> increasing
> prominence, Mandarin becomes a rather glaring choice.
>
> Therefore, there are no obvious choices only to those who never bothered
> to
> think about it.

As I understand it, your obvious choice is Mandarin. ISTM your reasoning is
valid for someone from outer space expecting to land at some random spot on
the earth of this planet. It loses a lot of its' obviousness when you
factor in the practicalities of already being an earth dweller. So far I
don't think I have *ever* encountered a Chinese peasant - or whatever they
call them nowadays.

A good friend of mine is Indian; he had to learn a new language to go to
University. He told me the only thing the Indian people have in common is
black hair.

[Johannes Bauer]

On 25.04.2013 18:00, David Brown wrote:

>> "main" has a return parameter which is an int. Always.
>
> No, "main" does not always have a return parameter

Well, if the code conforms to the C standard, it should return int.

>- "main" does not
> always return, and therefore a return parameter is meaningless.

It's mandated by the C standard. So if you want to have a standard
compliant program, it is very meaningful. Not in a way that transports
any information (because the return value itself may be discarded).

> In most
> (small) embedded systems, main() never exits.

I disagree completely. Is a 4 bit microcontroller small enoguh to
qualify as "small"? Because these are the smallest I've programmed (in
C). And nowhere, ever, have I encountered an environment that has no
main somewhere (sure, maybe hidden from the application developer, but
it is indeed there when you look for it).

> Including a return
> parameter may mean wasted code, and will mean your compiler and/or
> static code checker will warn about unreachable code (if you include a
> return value) or missing return values (if you don't).

Any smart compiler will optimize that away. And standard compliance is
more important than that one instruction (even on a 8 bit MCU!) that
sets the return value.

> Is such a "void main(void)" declaration valid according to the strictest
> C conformance? Perhaps not - but then, most (probably all) embedded
> compilers and embedded programs are non-conforming in at least a few
> small ways. They often have C libraries with limitations, floating
> point implementations that are not fully IEEE, extra keywords for
> special memory handling, etc.

Actually, many deeply embedded systems have no floating point support at
all (because the sheer soft-float library is so large that it would
completely fill the ROM. I'm actually not sure if float support is
required by the standard, but would guess that it might be the case.

> I also found this reference:
> <http://c0x.coding-guidelines.com/5.1.2.2.1.html>
>
> I don't know whether this is from an official standards document, but
> point 167 clearly says that "main" can be defined "in some other
> implemention-defined manner".

Hm, interesting. Would be interesting to know what is meant by that.
Because "implementation-defined manner" can also mean that nothing
(neither the prototype nor the name 'main' itself is required).

> Do I think that most C programs are written for embedded systems? No, I
> don't - that's why I did not say so.

Gotcha. Misunderstood you there, sorry about that.

> But if someone tells me he wants to learn to program and asks what
> language to use, I would only say "C" if it was for embedded systems.
> If someone asks me what language is appropriate for a given project,
> then the answer is seldom "C" - unless it is an embedded system, a very
> low-level program, a high-speed library, or a very time-critical program
> (even then C is often not the best choice).

I agree.

> I think this difference is particularly apparent in newer, younger
> programmers. There was a time when people used C for everything from
> small scripts or utilities to large applications - and people who are
> used to that, continue to do so. But for a new developer, you would be
> better off with Python, Java, Ruby, C++, etc.

Couldn't agree more.

> Of course, being good at C programming is an essential skill for /any/
> expert programmer, even if you do most of your work in other languages.
> It's like having a good understanding of assembly is essential for
> being an expert C programmer, especially on embedded systems.

Couldn't agree more here as well.

Best regards,

Johannes

--
>> Wo hattest Du das Beben nochmal GENAU vorhergesagt?

> Zumindest nicht �ffentlich!
Ah, der neueste und bis heute genialste Streich unsere gro�en
Kosmologen: Die Geheim-Vorhersage.
- Karl Kaos �ber R�diger Thomas in dsa <hidbv3$om2$1...@speranza.aioe.org>

[James Kuyper]

On 04/25/2013 12:00 PM, David Brown wrote:
...

> Is such a "void main(void)" declaration valid according to the strictest
> C conformance? Perhaps not - but then, most (probably all) embedded
> compilers and embedded programs are non-conforming in at least a few
> small ways. They often have C libraries with limitations, floating
> point implementations that are not fully IEEE, extra keywords for
> special memory handling, etc.

The C standard doesn't require IEEE conformance. Even if the
implementation pre#defines __STDC_IEC_60559__, that doesn't require full
conformance with IEC 60559 (== IEEE 754). It only requires conformance
with Annex F. Annex F cross-references a large part of IEC 60559, but
not all of it.

Extra keywords are also not a problem, so long as care is taken to
ensure that they are from the name space reserved to the implementation.

> I also found this reference:
> <http://c0x.coding-guidelines.com/5.1.2.2.1.html>
>
> I don't know whether this is from an official standards document, but

According to <http://c0x.coding-guidelines.com/>, the citations are from
N1256.pdf. That's an unofficial committee draft based upon four official
documents: the C99 standard and three Technical Corrigenda, which were
written as corrections to C99 itself. n1256.pdf combines those
documents, applying the specified corrections to C99, something that has
not been done in any official version of the standard. As a result, it's
actually more useful than any official version of C99. If there's a
discrepancy between what n1256.pdf says and what the official documents
say, then it's the official ones that are correct, but as far as I know,
there's only one such discrepancy known, and it's a rather obscure one.
The only other error it's known to possess is that on every single page
of the document, the date on which the document was completed has
"September" misspelled as "Septermber".

> point 167 clearly says that "main" can be defined "in some other
> implemention-defined manner".

It can, but what 5.1.2.2.1 says is "It shall be defined with a return
type of int and [details of one permitted form] or [details of a second
permitted form] or equivalent; or in some other implementation-defined
manner."

It has been argued that "A and B or C or D; or E" should be parsed as
"(A and B) or C or D; or E", but that doesn't make sense. The intended
parse was "A and (B or C or D; or E)" (I'm not sure what affect the ';'
should have on the parse). If that weren't the case, A (== "it shall be
defined with a return type of int") would be redundant, since the two
explicitly specified forms already give a return type of 'int'. If that
clause wasn't intended to apply to the "other implementation-defined
manner", it could simply have been dropped.

[James Dow Allen]

On Apr 25, 4:39 am, Keith Thompson <ks...@mib.org> wrote:
> ("void main()" can actually be valid in some circumstances,
> particularly for embedded systems, but you're not likely to be
> using such systems.)

I click on c.l.c every now and then just to see
if any interesting code snippets are posted.
(Or to see if any of the worst pedants ever
get enlightenment.)
A straightforward general question is asked here
... and almost half the posts deal with the pressing
issue:
To void main or not to void; that is the question.

Wow. Just ... Wow!
Perhaps the best immediate advice to Dogukan
will be to explain killfiles.

James

[James Kuyper]

On 04/25/2013 01:00 PM, Johannes Bauer wrote:
> On 25.04.2013 18:00, David Brown wrote:
>
>>> "main" has a return parameter which is an int. Always.
>>
>> No, "main" does not always have a return parameter
>
> Well, if the code conforms to the C standard, it should return int.

No, that's not actually required. The standard's definition of a
"conforming program" was determined by politics, not technical
considerations. It's so broad that the only feature a program could
possess that would render it non-conforming is a correctly (sic!)
formatted #error directive that survives conditional compilation. The
book of Genesis (in the original Hebrew!) is a conforming C program,
since it doesn't contain any of the characters needed to write #error.

"strict conformance" is a different matter. A strictly conforming C
program must indeed use a declaration for main() that is equivalent to
one of the two methods given explicitly in 5.1.2.2.1. It's
implementation-defined whether any other forms are supported, and
strictly conforming code is not allowed to depend upon
implementation-defined features.

> Actually, many deeply embedded systems have no floating point support at
> all (because the sheer soft-float library is so large that it would
> completely fill the ROM. I'm actually not sure if float support is
> required by the standard, but would guess that it might be the case.

Support for floating point math is required. However, library support of
floating point is optional for freestanding implementations of C.

[James Kuyper]

On 04/25/2013 10:56 AM, Dogukan Bayraktar wrote:
> 25 Nisan 2013 Perşembe 14:30:47 UTC+3 tarihinde David Brown yazdı:
>> On 24/04/13 21:30, Dogukan Bayraktar wrote:
>>> Hi there!
>>>
>>> Firstly, sorry for my bad English :/
>>>
>>> I'm only 17 and I want to learn C and write perfect codes in C. I'm not so good in C programming, but I want to become a good C programmer.
>>>
>>> My English is not enough to read the programming articles or anything.
>>> What should I do to become a good C programmer?
>>
>>> - Do you think is English needed for programming?

...

>> Incidentally, what is your native language?

...

> I'm from Turkey. So my native language is Turkish. But I want to learn English so much :)

Try
<https://groups.google.com/forum/?fromgroups#!forum/cprogramlama>. I
can't read it, but Google claims it's a Turkish newsgroup, and the name
sounds appropriate.

[Rui Maciel]

osmium wrote:

> As I understand it, your obvious choice is Mandarin.

To some, it is. I know of a university whose student body offers paid
Mandarin classes.

> ISTM your reasoning
> is valid for someone from outer space expecting to land at some random
> spot on the earth of this planet. It loses a lot of its' obviousness when
> you factor in the practicalities of already being an earth dweller.

I can only speak from personal experience. English is not my native
language, and when I was growing up odds were that for the average joe
understanding it was only useful if you really wanted to know what pop
singers were blabbering about. In practical terms, people were better off
learning french or german. Then the internet happened, and English became
the de facto Esperanto.

But this is the past.

Considering that the world's economy is steadily migrating to China in
particular and Asia in general, not to mention the amount of academic
production, its highly probable that knowing Mandarin will end up being a
required skill. I know people who already invested in learning it and
proudly advertise it on their CV.


Rui Maciel

[Keith Thompson]

Johannes Bauer <dfnson...@gmx.de> writes:
> On 25.04.2013 11:44, David Brown wrote:
>> "void main(void)" is preferable in most embedded systems - you want to
>> explicitly say it has no arguments. Of course, it's a different matter
>> if you intend to return from main or pass arguments to it, but in most
>> small embedded systems main() never exits.
>
> "main" has a return parameter which is an int. Always.

That's incorrect.

Here's what the standard says about the main function for a conforming
hosted implementation:

It shall be defined with a return type of int and with no parameters:

int main(void) { /* ... */ }

or with two parameters (referred to here as argc and argv,
though any names may be used, as they are local to the function
in which they are declared):

int main(int argc, char *argv[]) { /* ... */ }

or equivalent; or in some other implementation-defined manner.

The phrase "implementation-defined" means that the implementation must
document it.

So if your compiler's documentation says you can define

void main(void) { /* ... */ }

then you can do that, and your program is conforming *for that
implementation*. And if it doesn't, then your program violates a
"shall" that appears outside a constraint, which means that its
behavior is undefined -- which means that it *can* behave just as
if you had defined it with a return type of int.

But for a hosted implementation, there's very little *reason* to define
main as a void function. And if you're writing a book about C,
suggesting that "void main" is valid for hosted implementations without
explaining how and why it might not be valid is malpractice.

Also quoting the standard:

In a freestanding environment (in which C program execution
may take place without any benefit of an operating system),
the name and type of the function called at program startup
are implementation-defined.

Depending on the choices made by the authors of the implementation,
the entry point might be "void main(void)", or it might be "double
foobar(double complex*)". "int main(void)" might even be invalid
in such an environment.

>> Depending on the situation, I would say you are actually quite likely to
>> be working on embedded systems if you are programming in C. After all,
>> the great majority of embedded systems are coded in C (followed by C++),
>> and there are a great many embedded systems out there.
>
> So because most embedded systems are programmed in C you conclude that
> most C programms are for embedded systems? Something is seriously wrong
> with your logic.

You're assuming, among other things, that his conclusion follows only
from those other statements. And he didn't say that *most* C programs
are for embedded systems, only that "you are actually quite likely to be
working on embedded systems if you are programming in C" ("quite likely"
needn't imply more than 50%).

I suspect, without proof, that his conclusion is correct. (I work on
embedded systems myself, but they're embedded systems with an OS.)

In any case, I think that most *introductory* C tutorials are likely to
deal with hosted implementations such as Linux, MacOS, or Windows.

[Keith Thompson]

James Kuyper <james...@verizon.net> writes:
> On 04/25/2013 08:42 AM, Johannes Bauer wrote:
>> On 25.04.2013 11:44, David Brown wrote:
>>
>>> "void main(void)" is preferable in most embedded systems - you want to
>>> explicitly say it has no arguments. Of course, it's a different matter
>>> if you intend to return from main or pass arguments to it, but in most
>>> small embedded systems main() never exits.
>>
>> "main" has a return parameter which is an int. Always.
>
> He was responding to a comment Keith made that was specifically about
> the fact (and it is a fact) that some compilers do accept void main(),
> despite what it says to the contrary in the C standard.

[...]

Actually the C standard doesn't say anything to the contrary. Though it
doesn't mention "void main" explicitly, the form of a program's entry
point can be implementation-defined for hosted implementations, and is
*always* implementation-defined for freestanding implementations.

[Rui Maciel]

James Dow Allen wrote:

> A straightforward general question is asked here
> ... and almost half the posts deal with the pressing
> issue:
> To void main or not to void; that is the question.
>
> Wow. Just ... Wow!

The void main issue is actually relevant. It is a Litmus test to infer if a
publication actually complies with the standard or instead is a broken mess.
If someone delves into the language by relying on a broken mess of a manual
then odds are they are bound to experience problems caused by broken code
being passed off as working examples.


Rui Maciel

[Malcolm McLean]

There aren't many jobs for non-embedded C programmers. Virtually everyone
seems to specify C++ at least, and normally they are far more interested
in high level languages like Python or the various web, database, and
Windows only languages.
I think the reason is that the guts of a program, the central algorithm
that makes it work, is usually best written in C. So if the program is
essentially a Fourier transform, you'll write the FFT in C, if it's Huffman
compression you'll write the Huffman code in C, if it's a 2D image displayer,
all the code to draw triangles and rotate images will be written in C.
But most programmers don't work with the guts of a program. The work is in
hooking up code written by other people and integrating it and giving it user
interfaces. So C isn't particularly useful for that.

[Tim Rentsch]

David Brown <da...@westcontrol.removethisbit.com> writes:

> On 25/04/13 14:42, Johannes Bauer wrote:
>> On 25.04.2013 11:44, David Brown wrote:
>>
>>> "void main(void)" is preferable in most embedded systems - you want to
>>> explicitly say it has no arguments. Of course, it's a different matter
>>> if you intend to return from main or pass arguments to it, but in most
>>> small embedded systems main() never exits.
>>
>> "main" has a return parameter which is an int. Always.
>
> No, "main" does not always have a return parameter - "main"
> does not always return, and therefore a return parameter is
> meaningless. In most (small) embedded systems, main() never
> exits. Including a return parameter may mean wasted code, and
> will mean your compiler and/or static code checker will warn
> about unreachable code (if you include a return value) or

> missing return values (if you don't). [snip unrelated]

Both these problems can be avoided by writing main() this
way:

int
main( void ){

/* ... */
/* whatever main does in its loop body */
/* ... */

return main();
}

Of course I'm not completely serious, but neither is it
completely a joke. Presented with such a program, gcc
compiles it (under -O2) as a simple loop, not a call, and
with no generated return opcode or any other extra clutter.

[Malcolm McLean]

On Thursday, April 25, 2013 3:56:05 PM UTC+1, Dogukan Bayraktar wrote:
> 25 Nisan 2013 Perşembe 14:30:47 UTC+3 tarihinde David Brown yazdı:
>

>

> I'm from Turkey. So my native language is Turkish. But I want to learn English > so much :)
>
> I've been learning C for 5 months. But I want to improve my skills for C
> programming. I love C/C++ languages more than other languages like Java and
> C#.
>
>

Well keep on posting. The best way to learn English is to use it for real,
and you can kill two birds with one stone.

[Dogukan Bayraktar]

25 Nisan 2013 Perşembe 20:44:06 UTC+3 tarihinde James Kuyper yazdı:

Thanks but that link is not useful for me because nobody didn't share anything about C programming on that link. Nothing to do with C programming. I don't want to write/listen/read/speak in Turkish, because of its that I want to improve my English. So I want to write/listen/read/speak in English to improve it.

I have got a file of .PDF about C programming called "K&D C Programming".
In this e-book, i understand means of sentences. But I don't know too vocabulary. So I don't understand some sentences. I really want to read like that e-books.

* By the way, forgive me for my English :/
* I hope everyone understand me..

Thanks everyone for comments.

[Dogukan Bayraktar]

25 Nisan 2013 Perşembe 21:12:11 UTC+3 tarihinde Malcolm McLean yazdı:

Thank you for advice! I`ll keep on posting and reading!

[James Kuyper]

On 04/25/2013 02:17 PM, Dogukan Bayraktar wrote:
> 25 Nisan 2013 Perşembe 20:44:06 UTC+3 tarihinde James Kuyper yazdı:

...

>> Try
>>
>> <https://groups.google.com/forum/?fromgroups#!forum/cprogramlama>. I
>>
>> can't read it, but Google claims it's a Turkish newsgroup, and the name
>>
>> sounds appropriate.
>
>

> Thanks but that link is not useful for me because nobody didn't share anything about C programming on that link. Nothing to do with C programming. ..

The group description translates to English as "Cprogramlama
This group is C, C + +, C #, Java, Php, such as languages ​​with C-like
syntax, and was established as a discussion and helping the environment.
General programming issues, algorithms, and other programming languages,
jobs and so on. correspondence related issues, too." That sounded
appropriate, I'm sorry that it wasn't.

> .. I don't want to write/listen/read/speak in Turkish, because of its that I want to improve my English. So I want to write/listen/read/speak in English to improve it.

That makes sense - but from my own experience with discussing technical
subjects in foreign languages, I think you should also have a fall-back
source of advice where you can use the language you understand best.

> I have got a file of .PDF about C programming called "K&D C Programming".

That should be "K&R", standing for "Kernighan and Ritchie", the authors.

[Tim Rentsch]

Dogukan Bayraktar <dg28...@gmail.com> writes:

> [snip]

>
> I have got a file of .PDF about C programming called "K&D C
> Programming".

> In this e-book, i understand means of sentences.

I expect you mean: you understand the _meaning_ of (some) sentences...

> But I don't know too vocabulary.

and that you don't know too _much_ vocabulary..

> So I don't understand some sentences. I really want to read like
> that e-books.

I think you mean you want to be able to read e-books like
the one you have. "I really want to be able to read other
e-books like that one." Is this what you meant, or did
you mean something else?

> * By the way, forgive me for my English :/
> * I hope everyone understand me..

I applaud your efforts, and your results. You're doing great!
("Applaud" is clapping hands, showing praise.)

> Thanks everyone for comments.

Two suggestions:

One: when you find a passage you don't understand, post it
here and ask about it. You should get an explanation that
will help both with understanding C and with learning English.

Two: if you are up to a challenge, get a copy of the official
defining document for C, such as

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf

This may be difficult for you, because it is more formal
English, but I think you'll be okay, and it has the advantage
that you can ask about it in the newsgroup here and lots of
people will be able to explain what it says. You will get
great practice for your English, and you will learn C much
more completely. (And if this document is too hard it is
always okay to go back to simpler stuff for a while.)

Good luck!

[Jorgen Grahn]

On Thu, 2013-04-25, James Kuyper wrote:
...

> In this newsgroup I've talked with a number of people who thought that
> most, if not all, current C programming is being done for embedded
> platforms. When challenged, none have been able to provide hard numbers
> in support of their claim. To be fair, I know of no good source of
> numbers to disprove the claim, either. But the simple fact that anybody
> believes it is, in itself, evidence for the existence of a fairly large
> amount of embedded C programming going on.

There's also a lot of confusion about what "embedded programming" is.
My employers call what I do embedded programming, but it's really
for the most part ordinary Unix server programming.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Tim Rentsch]

James Kuyper <james...@verizon.net> writes:

> On 04/25/2013 12:00 PM, David Brown wrote:

> ... [snip] ...

>
>> point 167 clearly says that "main" can be defined "in some other
>> implemention-defined manner".
>
> It can, but what 5.1.2.2.1 says is "It shall be defined with a
> return type of int and [details of one permitted form] or [details
> of a second permitted form] or equivalent; or in some other
> implementation-defined manner."
>
> It has been argued that "A and B or C or D; or E" should be parsed
> as "(A and B) or C or D; or E", but that doesn't make sense. The
> intended parse was "A and (B or C or D; or E)" (I'm not sure what
> affect the ';' should have on the parse).

That's wrong. The intended parse was ((A and (B or C)) or D) or E.
The footnote makes evident the wider applicability of D, and IIRC
Larry Jones has remarked in comp.std.c about case E being outside
all the previous conditions.

> If that weren't the case, A (== "it shall be defined with a return
> type of int") would be redundant, since the two explicitly specified
> forms already give a return type of 'int'. If that clause wasn't
> intended to apply to the "other implementation-defined manner", it
> could simply have been dropped.

That's a plausible line of reasoning, but certainly it is not the only
plausible line of reasoning. More importantly, it doesn't agree with
the views of many (or most?) other people who read the Standard,
and AFAIAA it does not agree with the views of the people who wrote
it.

[Jorgen Grahn]

On Thu, 2013-04-25, David Brown wrote:
...

> As for becoming a good C programmer, the first question is /why/?

Yes.

> If you want to become a good programmer, C is not necessarily a good choice
> for starting. The field of programming is vast - C is only suitable for
> a small part of that.

But it has to be pointed out that small part can be large enough. For
example, C + Unix + some scripting languages can be enough for many
years of hobby use. You can also make a living off it.

[Keith Thompson]

Johannes Bauer <dfnson...@gmx.de> writes:
> On 25.04.2013 18:00, David Brown wrote:
>>> "main" has a return parameter which is an int. Always.
>>
>> No, "main" does not always have a return parameter
>
> Well, if the code conforms to the C standard, it should return int.

I suggest you read the actual C standard, or at least a draft of it.
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf is the lastest
publicly available draft; take a look at section 5.1.2.2.1.

For hosted implemenatations, I agree that it *should* return int,
but that's a style judgement, not a requirement. An implementation
is explicitly permitted to support other forms of main, including
forms in which it doesn't return int. Such forms are not portable.
(Incidentally, the value returned by a function is not a
"parameter".)

>>- "main" does not
>> always return, and therefore a return parameter is meaningless.
>
> It's mandated by the C standard. So if you want to have a standard
> compliant program, it is very meaningful. Not in a way that transports
> any information (because the return value itself may be discarded).

That's not entirely correct. You do need to define "main" with a return
type of int if you want your program to be portable to conforming hosted
implementations. (No program can be portable to all conforming
freestanding implementations.)

>> In most
>> (small) embedded systems, main() never exits.
>
> I disagree completely. Is a 4 bit microcontroller small enoguh to
> qualify as "small"? Because these are the smallest I've programmed (in
> C). And nowhere, ever, have I encountered an environment that has no
> main somewhere (sure, maybe hidden from the application developer, but
> it is indeed there when you look for it).

He didn't say main doesn't *exist*, he said it never *exits*. For a
small embedded system, the main program is likely to be an infinite
loop that keeps running until you turn off the power; it never exits
because there's nothing to take control after it does so. And the
form of the program entry point for a freestanding implementation
is implementation-defined; it needn't even be called "main".

[...]

> Actually, many deeply embedded systems have no floating point support at
> all (because the sheer soft-float library is so large that it would
> completely fill the ROM. I'm actually not sure if float support is
> required by the standard, but would guess that it might be the case.

Floating-point arithmetic is not optional, even for freestanding
implementations. If your hardware doesn't support floating-point, you
can either emulate it in software, or you can provide a non-conforming
implementation (there's nothing wrong with that as long as you don't
claim conformance).

>> I also found this reference:
>> <http://c0x.coding-guidelines.com/5.1.2.2.1.html>
>>
>> I don't know whether this is from an official standards document, but
>> point 167 clearly says that "main" can be defined "in some other
>> implemention-defined manner".
>
> Hm, interesting. Would be interesting to know what is meant by that.
> Because "implementation-defined manner" can also mean that nothing
> (neither the prototype nor the name 'main' itself is required).

It means that the manner is defined (and documented) by the
implementation. It's implicitly assumed, I suppose, that there must be
*some* entry point.

[...]

[Dogukan Bayraktar]

25 Nisan 2013 Perşembe 21:53:39 UTC+3 tarihinde Tim Rentsch yazdı:

25 Nisan 2013 Perşembe 21:53:39 UTC+3 tarihinde Tim Rentsch yazdı:

Thank you so much ! You're really so helpful! I'm grateful for your help...
I loved this group :) I'll try to write some basic programs and try to run them. I'll post on this group, if I get any problem/error etc.

Thanks everyone for comments. I'm grateful for everyone!

[Keith Thompson]

James Kuyper <james...@verizon.net> writes:
> On 04/25/2013 12:00 PM, David Brown wrote:

[...]

>> point 167 clearly says that "main" can be defined "in some other
>> implemention-defined manner".
>
> It can, but what 5.1.2.2.1 says is "It shall be defined with a return
> type of int and [details of one permitted form] or [details of a second
> permitted form] or equivalent; or in some other implementation-defined
> manner."
>
> It has been argued that "A and B or C or D; or E" should be parsed as
> "(A and B) or C or D; or E", but that doesn't make sense. The intended
> parse was "A and (B or C or D; or E)" (I'm not sure what affect the ';'
> should have on the parse). If that weren't the case, A (== "it shall be
> defined with a return type of int") would be redundant, since the two
> explicitly specified forms already give a return type of 'int'. If that
> clause wasn't intended to apply to the "other implementation-defined
> manner", it could simply have been dropped.

Furthermore, 5.1.2.2.3p1 says:

If the return type of the main function is a type compatible
with int, a return from the initial call to the main function
is equivalent to calling the exit function with the value
returned by the main function as its argument; reaching the }
that terminates the main function returns a value of 0. If the
return type is not compatible with int, the termination status
returned to the host environment is unspecified.

(That's from N1570; the wording in N1256 is slightly different.) That
only makes sense if the return value of main is allowed to be something
other than int, or a type compatible with int.

[Keith Thompson]

Tim Rentsch <t...@alumni.caltech.edu> writes:
[...]

> Both these problems can be avoided by writing main() this
> way:
>
> int
> main( void ){
>
> /* ... */
> /* whatever main does in its loop body */
> /* ... */
>
> return main();
> }
>
> Of course I'm not completely serious, but neither is it
> completely a joke. Presented with such a program, gcc
> compiles it (under -O2) as a simple loop, not a call, and
> with no generated return opcode or any other extra clutter.

Making the body of main() an obvious infinite loop has the same effect.

[Keith Thompson]

Perhaps you'd like to read the context in which I mentioned void main()
and then decide whether it was relevant. (Hint: it was.)

What kind of "enlightenment" do you think I need?

[Keith Thompson]

If so, you've probably got an illegal copy of it. As far as I know, K&R
is not legally available other than as a paper book. (By "legal" I mean
"not violating copyright".)

[Keith Thompson]

I didn't read your "A and (B or C or D; or E)" closely enough. I
thought I was agreeing with you, but if I understand you correctly, I
disagree with you.

Without all the ABCDE stuff, an implementation *is* permitted to define
a form of main that returns a type other than int. The following
section, on program termination, wouldn't make sense otherwise.

[Tim Rentsch]

Keith Thompson <ks...@mib.org> writes:

> Tim Rentsch <t...@alumni.caltech.edu> writes:
> [...]
>> Both these problems can be avoided by writing main() this
>> way:
>>
>> int
>> main( void ){
>>
>> /* ... */
>> /* whatever main does in its loop body */
>> /* ... */
>>
>> return main();
>> }
>>
>> Of course I'm not completely serious, but neither is it
>> completely a joke. Presented with such a program, gcc
>> compiles it (under -O2) as a simple loop, not a call, and
>> with no generated return opcode or any other extra clutter.
>
> Making the body of main() an obvious infinite loop has the same
> effect.

Sure, but doing that has the problems the earlier poster
was complaining about ("Both of these problems"), which
is what prompted me to respond in the first place.

[James Kuyper]

I'd forgotten about that. So we have either redundant specification or
contradictory specification, depending upon what was actually intended.
I've never been fond of this section's wording. It's right up there with
"are meant to imply interchangeability" and "by which the exposition of
language elements is to be interpreted" on my list of the least clear
phrases in the standard.

[Robert Wessel]

On Thu, 25 Apr 2013 12:57:29 -0700, Keith Thompson <ks...@mib.org>
wrote:

>James Kuyper <james...@verizon.net> writes:
>> On 04/25/2013 02:17 PM, Dogukan Bayraktar wrote:

>>> 25 Nisan 2013 Per?embe 20:44:06 UTC+3 tarihinde James Kuyper yazd?:

>> ...
>>>> Try
>>>> <https://groups.google.com/forum/?fromgroups#!forum/cprogramlama>. I
>>>> can't read it, but Google claims it's a Turkish newsgroup, and the name
>>>> sounds appropriate.
>>>
>>> Thanks but that link is not useful for me because nobody didn't share
>>> anything about C programming on that link. Nothing to do with C
>>> programming. ..
>>
>> The group description translates to English as "Cprogramlama

>> This group is C, C + +, C #, Java, Php, such as languages ??with C-like

>> syntax, and was established as a discussion and helping the environment.
>> General programming issues, algorithms, and other programming languages,
>> jobs and so on. correspondence related issues, too." That sounded
>> appropriate, I'm sorry that it wasn't.
>>
>>> .. I don't want to write/listen/read/speak in Turkish, because of its
>>> that I want to improve my English. So I want to
>>> write/listen/read/speak in English to improve it.
>>
>> That makes sense - but from my own experience with discussing technical
>> subjects in foreign languages, I think you should also have a fall-back
>> source of advice where you can use the language you understand best.
>>
>>> I have got a file of .PDF about C programming called "K&D C Programming".
>>
>> That should be "K&R", standing for "Kernighan and Ritchie", the authors.
>
>If so, you've probably got an illegal copy of it. As far as I know, K&R
>is not legally available other than as a paper book. (By "legal" I mean
>"not violating copyright".)

K&R2 is available as a Kindle e-book from Amazon. I'm not aware of
any legal electronic versions of K&R1.

http://amzn.com/B009ZUZ9FW

[Keith Thompson]

Robert Wessel <robert...@yahoo.com> writes:
> On Thu, 25 Apr 2013 12:57:29 -0700, Keith Thompson <ks...@mib.org>
> wrote:
>>James Kuyper <james...@verizon.net> writes:
>>> On 04/25/2013 02:17 PM, Dogukan Bayraktar wrote:
>>>> 25 Nisan 2013 Per?embe 20:44:06 UTC+3 tarihinde James Kuyper yazd?:

[...]

>>>> I have got a file of .PDF about C programming called "K&D C Programming".
>>>
>>> That should be "K&R", standing for "Kernighan and Ritchie", the authors.
>>
>>If so, you've probably got an illegal copy of it. As far as I know, K&R
>>is not legally available other than as a paper book. (By "legal" I mean
>>"not violating copyright".)
>
> K&R2 is available as a Kindle e-book from Amazon. I'm not aware of
> any legal electronic versions of K&R1.
>
> http://amzn.com/B009ZUZ9FW

Cool, I didn't know that; it must be fairly new.

Still, a PDF copy of K&R is most likely a copyright violation.

[Keith Thompson]

The other problem being complaining about either unreachable code or a
missing return value. The latter shouldn't be an issue for a C99 or
later implementation, which makes a missing return statement in main()
equivalent to "return 0;".

[Tim Rentsch]

Just because the behavior is defined doesn't mean the compiler
won't issue a warning about it. There is even a reasonable
argument that it should get a warning, since C90 is different
in this regard. And for all we know the code in question may
be C90 code, not C99.

To be fair, we don't know that the compiler(s) in question will
compile the tail-recursive version as a loop rather than a call
either. I certainly don't presume to say this technique is
appropriate in all circumstances, or even many circumstances.
But in some circumstances - and reasonably plausible ones - it
may offer advantages that other alternatives don't. The point
is to provide another approach - one more arrow in the quiver,
so to speak - that may be attractive in some cases. I don't
know of any programming problem where just one approach is the
best choice in all possible cases.

[glen herrmannsfeldt]

Yes, more and more embedded systems run Linux, or something similar.

I suppose I call it embedded if it boots completely from ROM, EPROM,
EEPROM, or FLASH. The latter does not include FLASH interfaced through
one of the usual disk interfaces such as SATA.

The usual NAT router/wireless access point devices run Linux, for
example.

-- glen

[Stephen Sprunk]

On 25-Apr-13 10:19, Rui Maciel wrote:
> Stephen Sprunk wrote:
>> One of the problems that English-speaking countries have is there
>> is no obvious choice of second language for our students, whereas
>> English is an obvious (and now by far the most common) choice in
>> other countries. There are only a handful of other languages spoken
>> by enough people to be useful, and these days most people in those
>> countries are learning English now, so why bother?
>
> From where I'm from, a foreign language (english) is included in the
> national curriculum from the 1st grade, and a second foreign
> language from the 7th grade onward.
>
> For the second foreign language, students are free (technically*) to
> pick from three available options -- german, french and spanish.
>
> These choices are far from being "obvious", for a number of reasons.
> Yet, people still choose and no one is harmed by it.

English as a second language is rapidly being mandated around the world;
what language such students might choose after that is irrelevant to
this discussion since they already know English.

> Regarding english-speaking countries, it can be argued that each one
> has its glaring obvious choice.
>
> - US: According to wikipedia[1], the country has 45 million people
> who speak spanish as a first or second language. If we take into
> account that almost all neighbouring countries to the south have
> spanish as their official language, spanish does appear to be an
> obvious choice.

~95% of Americans speak English on some level, including most native
Spanish-speakers. Legal immigrants must know it to get a visa in the
first place, and their kids are forced to learn it in school. That
leaves only illegal immigrants, and many of them pick up English as well
to avoid detection and/or get higher-paying jobs.

Culturally, I agree that it would be a good to learn Spanish to speak to
our neighbors to the south, but it's a poor economic choice--and
mandating thatt would be political suicide. Learning Portuguese would
be a better economic choice, but Brazilians students are learning
English now, so any benefit there would be short-lived.

> - Canada: it has two official languages: english and
> french.

Aside from those living in Quebec or working for the govt, there's not
much reason to learn French, since even the Quebecois learn English in
school now.

> - UK: even when ignoring their "regional" languages, the
> british isles do have significant ties with France and Germany.

... and France and Germany both mandate English as a second language, so
any benefit to Brits learning those languages would be short-lived.

> On top of that, if only less than 6% of the world are native english
> speakers while over 14% speak Mandarin[2], in addition to China's
> increasing prominence, Mandarin becomes a rather glaring choice.

1.8 billion people speak English, compared to 1.3 billion who speak
Mandarin. Every student in China is now required to learn English, and
it is projected that within a decade China will have more English
speakers than the US itself.

So, Mandarin is rapidly becoming a poor choice as well.

> [1]
> http://en.wikipedia.org/wiki/Spanish_language_in_the_United_States
> [2]
> http://en.wikipedia.org/wiki/List_of_languages_by_number_of_native_speakers

It's not only native languages that matter, especially when we're
discussing what is by far the most popular _second_ language in the
world. See:
http://en.wikipedia.org/wiki/World_language

Also, of over 6,000 languages spoken today, only half are being taught
as a native language to the current generation of kids. A handful of
languages are strong enough today to resist eradication via cohort
replacement, and those languages' native speakers are already learning
English as a second language, so they'll probably get hit in a few more
generations as well when they see they're getting left behind by those
who have already switched.

S

--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking

[Seebs]

On 2013-04-25, David Brown <da...@westcontrol.removethisbit.com> wrote:
> No, "main" does not always have a return parameter - "main" does not

> always return, and therefore a return parameter is meaningless.

This analysis is incorrect.

On at least some systems, the calling sequence depends on what type
the return would be if the function returned, so even a function that
never returns must have the correct return type.

There's an old joke about an atheist visiting Ireland during a time of
more strenuous conflict, and someone asked him whether he favored the Catholic
or Protestant side. He explained that, as an atheist, he did not believe
in God. And someone said, "Yes, but is it the God of the Catholics or the
Protestants that you don't believe in?"

Similarly, in C, even if you never return, it may matter what it is that
you are never returning.

> I don't know whether this is from an official standards document, but

> point 167 clearly says that "main" can be defined "in some other
> implemention-defined manner".

Which is to say, a specific implementation may describe other forms.

But they aren't required to.

I'd also point out: There are now a fair number of "embedded systems" where
the bulk of actual work is done on a perfectly ordinary Linux system, so on
the entire program, there is exactly one piece of code which has a main()
which is not a standard hosted-environment C program main(), that being the
kernel. Everything else has a normal main() which returns int. Even if it
never returns.

-s
--
Copyright 2013, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

[Seebs]

On 2013-04-24, Dogukan Bayraktar <dg28...@gmail.com> wrote:
> Firstly, sorry for my bad English :/

Eh, it happens. It's my native language and I still make mistakes, after
years writing professionally.

> I'm only 17 and I want to learn C and write perfect codes in C.

> I'm not so good in C programming, but I want to become a good C
> programmer.

Well, if you think you're not so good, you're already ahead of a great
number of people I've had to deal with. :)

> My English is not enough to read the programming articles or anything.
> What should I do to become a good C programmer?

Read, write. Code and language. And don't neglect things like philosophy,
psychology, and so on; everything you know can help you be better at
programming. Psychology can help you understand people, and understanding
people helps you write programs that suit them, or write code they can
read. Philosophy can help you decide what to work on. And so on.

> - Do you think is English needed for programming?

Needed, not exactly, but at this point I think it's a de facto standard;
enough highly valuable material is written in English that I would recommend
practicing it even if you don't need it.

> - What should I learn in C to become a good programmer?

Everything you can! :)

> - Should I read the example C codes in the web?

Yes.

My basic strategy when starting out was: Find things I want to do, do them.

I will say, learning other (programming) languages has helped me more with
the quality of my C code than I expected. Even if a thing is harder to do in
C than it is in another language, knowing that it might be possible to do
can be useful.

[glen herrmannsfeldt]

Seebs <usenet...@seebs.net> wrote:
> On 2013-04-25, David Brown <da...@westcontrol.removethisbit.com> wrote:
>> No, "main" does not always have a return parameter - "main" does not
>> always return, and therefore a return parameter is meaningless.

> This analysis is incorrect.

> On at least some systems, the calling sequence depends on what type
> the return would be if the function returned, so even a function that
> never returns must have the correct return type.

This is true, but the differences are most often related to actually
returning.

If the return value isn't returned in a register, then it is usual
to add an extra argument for it. Bad things happen if you return and
get that wrong. That is usually true for a struct return value,
sometimes for floating point, but rarely for int.

It would cause problems if all the other arguments (argc, argv) were
moved, (relative to their position for void) and one was referenced.

> There's an old joke about an atheist visiting Ireland during a time of
> more strenuous conflict, and someone asked him whether he favored the Catholic
> or Protestant side. He explained that, as an atheist, he did not believe
> in God. And someone said, "Yes, but is it the God of the Catholics or the
> Protestants that you don't believe in?"

> Similarly, in C, even if you never return, it may matter what it is that
> you are never returning.

-- glen

[James Kuyper]

On 04/25/2013 07:05 PM, Stephen Sprunk wrote:
...

> ~95% of Americans speak English on some level, including most native
> Spanish-speakers. Legal immigrants must know it to get a visa in the
> first place, and their kids are forced to learn it in school. That
> leaves only illegal immigrants, and many of them pick up English as well
> to avoid detection and/or get higher-paying jobs.
>
> Culturally, I agree that it would be a good to learn Spanish to speak to
> our neighbors to the south, but it's a poor economic choice--and
> mandating thatt would be political suicide. Learning Portuguese would
> be a better economic choice, but Brazilians students are learning
> English now, so any benefit there would be short-lived.

The entire southwest portion of the US used to be controlled by Spanish
speaking people, and Spanish remains pervasive throughout that region.
Many people for whom Spanish is their birth language come from families
that have been US citizens for 3 generations, or longer - some can trace
their presence in the region to back before it was seized by the US.
Spanish was my first foreign language, and it remains by far the most
useful of the five that I've learned, even though I now live in the
Maryland (which also, for different reasons, has a significant
Spanish-speaking population).

>> - Canada: it has two official languages: english and
>> french.
>
> Aside from those living in Quebec or working for the govt, there's not
> much reason to learn French, since even the Quebecois learn English in
> school now.

Many Québécois are much more cooperative with those who at least attempt
to speak with them in French. You can insist on using English, but the
more obstinate ones will respond by pretending not to understand.

...

> 1.8 billion people speak English, compared to 1.3 billion who speak
> Mandarin. Every student in China is now required to learn English, and
> it is projected that within a decade China will have more English
> speakers than the US itself.

I can vouch personally for the fact that the English spoken by many of
those students is quite poor (it's not as poor as my Mandarin,
unfortunately - you might think that with a Mandarin-speaking wife, I'd
have plenty of opportunities to practice, but it hasn't worked out that
way). I wouldn't recommend counting on being able to communicate with
all of them using English.
--
James Kuyper

[David Brown]

I try to make the distinction of "small embedded systems" - basically,
microcontroller programming where the program runs entirely from flash,
mostly using flash and ram that are integrated into the microcontroller.
Typical cpus are 8-bit or 16-bit devices (like the AVR or msp430), or
small 32-bit devices (Cortex M family are the most common these days).
These are usually bare metal, or run embedded OS's like FreeRTOS.

"Mid level" embedded systems run things like VxWorks or Linux, have
processors with external ram and flash, but don't have disks, and have
mostly fixed hardware (you might be able to plug in a USB memory stick,
but you are not going to change the screen or memory). Wireless routers
are in this category.

"High-end" embedded systems are often more like PC's, except that you
mostly restrict the software and hardware that runs on it, and obviously
the hardware and software are often specialised. "Media centres" would
be an example.

Of course, these are only vague categories, with plenty of overlap and
plenty of missing categories.

[David Brown]

On 25/04/13 19:00, Johannes Bauer wrote:
> On 25.04.2013 18:00, David Brown wrote:
>
>>> "main" has a return parameter which is an int. Always.
>>

>> No, "main" does not always have a return parameter
>

> Well, if the code conforms to the C standard, it should return int.
>

>> - "main" does not
>> always return, and therefore a return parameter is meaningless.
>

> It's mandated by the C standard. So if you want to have a standard
> compliant program, it is very meaningful. Not in a way that transports
> any information (because the return value itself may be discarded).
>

>> In most
>> (small) embedded systems, main() never exits.
>
> I disagree completely. Is a 4 bit microcontroller small enoguh to
> qualify as "small"? Because these are the smallest I've programmed (in
> C). And nowhere, ever, have I encountered an environment that has no
> main somewhere (sure, maybe hidden from the application developer, but
> it is indeed there when you look for it).
>

I wrote "main() never /exits/", not "main() never /exists/", which I
think is what you thought I wrote.

I certainly cannot remember ever having written a main() in a small
embedded system that ever exited, except by a re-boot or re-start to a
different program (such as to enter "bootloader" mode).

Most of my programs have had a main() function, but I've also written a
few that don't. Occasionally I've written my own startup code to
establish the C run-time environment (clear out bss, copy initialised
data, set up the stack, etc.), and there is no need for any function
called "main" in that case. Of course, it would no longer be strictly C
standard :-) I haven't used any 4-bit micros, but I have used an 8-bit
micro with no ram and only a three-entry hardware return stack - I
certainly didn't want to waste part of that stack on calling a main()
function that doesn't return.


>> Including a return
>> parameter may mean wasted code, and will mean your compiler and/or
>> static code checker will warn about unreachable code (if you include a
>> return value) or missing return values (if you don't).
>
> Any smart compiler will optimize that away. And standard compliance is
> more important than that one instruction (even on a 8 bit MCU!) that
> sets the return value.

Why? What is the point of having a "return 0;" statement at the end of
main() that cannot return? It's true that the compiler will usually
omit it in the object code, but you are trading compliance with a
meaningless (in this context) rule in the C standard for breaking common
rules in embedded programming coding standards. You are including code
that is never run, and never tested - that's always bad. You are
generating warnings from your compiler - also contrary to common rules
that require warning-free compiles.

Strict compliance with the C standards is often important, just as
writing portable code is often important, but not if it gets in the way
of writing good quality code for the job in hand.

>
>> Is such a "void main(void)" declaration valid according to the strictest
>> C conformance? Perhaps not - but then, most (probably all) embedded
>> compilers and embedded programs are non-conforming in at least a few
>> small ways. They often have C libraries with limitations, floating
>> point implementations that are not fully IEEE, extra keywords for
>> special memory handling, etc.

>
> Actually, many deeply embedded systems have no floating point support at
> all (because the sheer soft-float library is so large that it would
> completely fill the ROM. I'm actually not sure if float support is
> required by the standard, but would guess that it might be the case.
>

Of course most small embedded systems don't /use/ floating point (and
certainly not the whole standard library), but the standards require the
compiler and library to support it.

>> I also found this reference:
>> <http://c0x.coding-guidelines.com/5.1.2.2.1.html>
>>

>> I don't know whether this is from an official standards document, but
>> point 167 clearly says that "main" can be defined "in some other
>> implemention-defined manner".
>

> Hm, interesting. Would be interesting to know what is meant by that.
> Because "implementation-defined manner" can also mean that nothing
> (neither the prototype nor the name 'main' itself is required).
>

My reading of the page is that "main" is required, but that forms such
as "void main(void)" are valid.

>> Do I think that most C programs are written for embedded systems? No, I
>> don't - that's why I did not say so.
>
> Gotcha. Misunderstood you there, sorry about that.
>

No problem. Misunderstandings are part of the fun of newsgroups.

>> But if someone tells me he wants to learn to program and asks what
>> language to use, I would only say "C" if it was for embedded systems.
>> If someone asks me what language is appropriate for a given project,
>> then the answer is seldom "C" - unless it is an embedded system, a very
>> low-level program, a high-speed library, or a very time-critical program
>> (even then C is often not the best choice).
>
> I agree.
>
>> I think this difference is particularly apparent in newer, younger
>> programmers. There was a time when people used C for everything from
>> small scripts or utilities to large applications - and people who are
>> used to that, continue to do so. But for a new developer, you would be
>> better off with Python, Java, Ruby, C++, etc.
>
> Couldn't agree more.
>
>> Of course, being good at C programming is an essential skill for /any/
>> expert programmer, even if you do most of your work in other languages.
>> It's like having a good understanding of assembly is essential for
>> being an expert C programmer, especially on embedded systems.
>
> Couldn't agree more here as well.
>
> Best regards,
> Johannes
>

[David Brown]

On 26/04/13 01:47, Seebs wrote:
> On 2013-04-25, David Brown <da...@westcontrol.removethisbit.com> wrote:
>> No, "main" does not always have a return parameter - "main" does not
>> always return, and therefore a return parameter is meaningless.
>
> This analysis is incorrect.
>
> On at least some systems, the calling sequence depends on what type
> the return would be if the function returned, so even a function that
> never returns must have the correct return type.

If you have such a system, then that would be true. However, I have a
hard time imagining what could go wrong within the body of main even if
the calling sequence depended on the return type. I could imagine how
things could fail on the return from main() if the return type did not
match the expected type, but not during execution of main() and its
infinite loop.

I think your argument here is perhaps technically true, but very much
hypothetical.

>
> There's an old joke about an atheist visiting Ireland during a time of
> more strenuous conflict, and someone asked him whether he favored the Catholic
> or Protestant side. He explained that, as an atheist, he did not believe
> in God. And someone said, "Yes, but is it the God of the Catholics or the
> Protestants that you don't believe in?"
>
> Similarly, in C, even if you never return, it may matter what it is that
> you are never returning.
>
>> I don't know whether this is from an official standards document, but
>> point 167 clearly says that "main" can be defined "in some other
>> implemention-defined manner".
>
> Which is to say, a specific implementation may describe other forms.
>
> But they aren't required to.
>
> I'd also point out: There are now a fair number of "embedded systems" where
> the bulk of actual work is done on a perfectly ordinary Linux system, so on
> the entire program, there is exactly one piece of code which has a main()
> which is not a standard hosted-environment C program main(), that being the
> kernel. Everything else has a normal main() which returns int. Even if it
> never returns.
>

I made a specific point about /small/ embedded systems. I didn't define
"small embedded systems" here, but Linux (or other OS's capable of
calling independent programs) do not count as "small" - "small" system
programs are free-standing rather than hosted.

Typically in embedded systems there are at least two programs which are
not standard hosted environments with "int main(...)" - the kernel, and
also the bootloader (such as U-Boot). There may in fact be more levels
of bootloader, some of which may not have any main() at all.

[David Brown]

On 25/04/13 17:19, Rui Maciel wrote:

> On top of that, if only less than 6% of the world are native english
> speakers while over 14% speak Mandarin[2], in addition to China's increasing
> prominence, Mandarin becomes a rather glaring choice.
>

There are more /native/ speakers of Mandarin than /native/ speakers of
English (and Spanish falls between these two). However, there are more
people who speak English than any other language - mostly as a second
language. Figures vary wildly depending on what levels of competence
you look for, but something like 20% is probably a decent estimate (of
native and second-language speakers).

If you narrow the field to people who are seriously interested in
programming - and therefore mostly young, literate, reasonably well
educated, and familiar with computers, then I expect the percentage of
people who can read reasonable English and have at least basic English
written and oral skills is going to be very much higher.

[David Brown]

On 26/04/13 01:47, Seebs wrote:

> On 2013-04-24, Dogukan Bayraktar <dg28...@gmail.com> wrote:
>> Firstly, sorry for my bad English :/
>
> Eh, it happens. It's my native language and I still make mistakes, after
> years writing professionally.
>
>> I'm only 17 and I want to learn C and write perfect codes in C.
>> I'm not so good in C programming, but I want to become a good C
>> programmer.
>
> Well, if you think you're not so good, you're already ahead of a great
> number of people I've had to deal with. :)
>
>> My English is not enough to read the programming articles or anything.
>> What should I do to become a good C programmer?
>
> Read, write. Code and language. And don't neglect things like philosophy,
> psychology, and so on; everything you know can help you be better at
> programming. Psychology can help you understand people, and understanding
> people helps you write programs that suit them, or write code they can
> read. Philosophy can help you decide what to work on. And so on.
>

Telepathy is useful too, when you are trying to figure out what a
customer wants rather than what he says he wants...

Seriously, that's good advice. There is lots more to programming well
than just writing code - you have to know /what/ to code.

Other useful related skills are graphical design, economics (programmers
are notoriously bad at figuring out real-world costs), physics, maths,
more maths, applied maths, pure maths, and then some more maths.

[Malcolm McLean]

On Friday, April 26, 2013 12:05:15 AM UTC+1, Stephen Sprunk wrote:
> On 25-Apr-13 10:19, Rui Maciel wrote:
>
> > Stephen Sprunk wrote:
>
> 1.8 billion people speak English, compared to 1.3 billion who speak
> Mandarin. Every student in China is now required to learn English, and
> it is projected that within a decade China will have more English
> speakers than the US itself.
>
>

Actually they write Mandarin. The various dialects aren't mutually intelligible.
Since Chinese uses a pictogram system, you can have the same pictogram
pronounced in totally different ways, without breaking the writing system.

[James Kuyper]

On 04/26/2013 08:28 AM, Malcolm McLean wrote:
> On Friday, April 26, 2013 12:05:15 AM UTC+1, Stephen Sprunk wrote:
>> On 25-Apr-13 10:19, Rui Maciel wrote:
>>
>>> Stephen Sprunk wrote:
>>
>> 1.8 billion people speak English, compared to 1.3 billion who speak
>> Mandarin. Every student in China is now required to learn English, and
>> it is projected that within a decade China will have more English
>> speakers than the US itself.
>>
> Actually they write Mandarin.

The Chinese speak and hear multiple spoken languages, such as Mandarin
or Cantonese, which they think of as dialects of a single language,
though linguists consider several of them to be distinct languages.
However, they read and write essentially a single written Chinese
language (中文 or Zhōngwén), though it is written slightly differently
by speakers of the different spoken languages.
--
James Kuyper

[Rui Maciel]

David Brown wrote:

> There are more /native/ speakers of Mandarin than /native/ speakers of
> English (and Spanish falls between these two). However, there are more
> people who speak English than any other language - mostly as a second
> language. Figures vary wildly depending on what levels of competence
> you look for, but something like 20% is probably a decent estimate (of
> native and second-language speakers).

The second languages are taught because they are useful to communicate with
those who don't speak our native language. Therefore, their choice is
motivated by how useful they might be to communicate with others.

In the last decade or so, english managed to become a de facto esperanto,
but that was mainly because the US dominated the world's economy and
academia. Things won't stay like that for long.

In addition, in some western countries it's much more likely that you
stumble on someone who speaks mandarin natively than english.

Again, a couple of decades ago francophones were using the same arguments to
justify why it would be silly for them to learn a second language.

> If you narrow the field to people who are seriously interested in
> programming - and therefore mostly young, literate, reasonably well
> educated, and familiar with computers, then I expect the percentage of
> people who can read reasonable English and have at least basic English
> written and oral skills is going to be very much higher.

Hardware production is already firmly established in Asia. I wouldn't bet
that in a decade or so english will still be the prefered language to
communicate with them.

Regarding software, I've published a small library (written in C, so let's
pretend it's on-topic) which is distributed under a FLOSS license and
managed to be somewhat popular. Currently, according to the site's download
statistics, the most number of downloads are by far from China, while those
from the US amount to only about 70% of that.

Singapore is ranked 4th, and Taiwan ranks 9th, right after the UK.


Rui Maciel

[Stephen Sprunk]

1.3 billion is for Mandarin speakers only; Cantonese, Taiwanese, etc.
speakers are not included, even though they use (roughly) the same
writing system.

The PRC mandated Mandarin in all schools, govt offices, etc. on the
mainland, so now only the elderly remember their region's dialect.
Non-PRC areas kept their dialects, eg. Cantonese in Hong Kong and Macau,
Taiwanese in Taiwan, etc.

There is a difference between "Simplified" (PRC) and "Traditional"
(non-PRC) writing, but natives tell me that the two are mutually
intelligible, something like a continental European still being able to
recognize their language without its normal diacritical marks.

[James Kuyper]

On 04/26/2013 11:02 AM, Stephen Sprunk wrote:
...

> The PRC mandated Mandarin in all schools, govt offices, etc. on the
> mainland, so now only the elderly remember their region's dialect.
> Non-PRC areas kept their dialects, eg. Cantonese in Hong Kong and Macau,
> Taiwanese in Taiwan, etc.

Cantonese is still quite widely used in Canton itself and in neighboring
provinces.

> There is a difference between "Simplified" (PRC) and "Traditional"
> (non-PRC) writing, but natives tell me that the two are mutually
> intelligible, something like a continental European still being able to
> recognize their language without its normal diacritical marks.

My wife tells me differently. Raised in Taiwan, where they still use
almost exclusively the Traditional characters, she finds the simplified
ones almost unintelligible. That fits my own experience - I had a hard
time finding textbooks that teach the traditional characters; the best I
could do is find one that taught both forms. I learned to write both
simplified and traditional characters, and they were quite different.
The difference is far greater than, for instance, the difference between
the Helvitica and Fraktur typefaces.

[David Brown]

On 26/04/13 16:36, Rui Maciel wrote:
> David Brown wrote:
>
>> There are more /native/ speakers of Mandarin than /native/ speakers of
>> English (and Spanish falls between these two). However, there are more
>> people who speak English than any other language - mostly as a second
>> language. Figures vary wildly depending on what levels of competence
>> you look for, but something like 20% is probably a decent estimate (of
>> native and second-language speakers).
>
> The second languages are taught because they are useful to communicate with
> those who don't speak our native language. Therefore, their choice is
> motivated by how useful they might be to communicate with others.
>
> In the last decade or so, english managed to become a de facto esperanto,
> but that was mainly because the US dominated the world's economy and
> academia. Things won't stay like that for long.
>

One thing you need to take into account here is that English is easier
to learn as a second language than, say, Mandarin or Hindi (there are a
lot of people in India too). In particular, languages that are written
using the Roman alphabet are far easier to learn (in their written
form), simply because there are far fewer symbols. And they are much
easier to work with for computers.

Learning to speak a second language /accurately/ is a different matter -
how hard that is depends greatly on how closely related the phonemes are
between the languages.

But I think it is totally unrealistic to imagine that a language written
in something other than a basic Roman alphabet will ever become the "de
facto esperanto". It is /conceivable/ that something like Pinyin
(Chinese spoken language, but written using the Roman alphabet) could
work. But I believe the momentum of English is too great to change now.

Of course, we will see steadily more non-English language in use on the
web, with plenty in non-Roman alphabets - but I do not foresee anything
taking the place of English.

> In addition, in some western countries it's much more likely that you
> stumble on someone who speaks mandarin natively than english.

"Native" doesn't matter - "reasonable second language" is enough. There
are no Western countries where you are more likely to find someone who
speaks decent Mandarin than someone who speaks decent English.

>
> Again, a couple of decades ago francophones were using the same arguments to
> justify why it would be silly for them to learn a second language.
>
>
>> If you narrow the field to people who are seriously interested in
>> programming - and therefore mostly young, literate, reasonably well
>> educated, and familiar with computers, then I expect the percentage of
>> people who can read reasonable English and have at least basic English
>> written and oral skills is going to be very much higher.
>
> Hardware production is already firmly established in Asia. I wouldn't bet
> that in a decade or so english will still be the prefered language to
> communicate with them.

There are lots of countries in Asia, with lots of different languages.
The common language used is normally English. So when a Japanese
company wants parts made by a Korean company, they require documents in
English. Some of the person-to-person communication might be in
Japanese or Korean, but the majority of international documentation is
in English.

>
> Regarding software, I've published a small library (written in C, so let's
> pretend it's on-topic) which is distributed under a FLOSS license and
> managed to be somewhat popular. Currently, according to the site's download
> statistics, the most number of downloads are by far from China, while those
> from the US amount to only about 70% of that.
>
> Singapore is ranked 4th, and Taiwan ranks 9th, right after the UK.
>

Thus demonstrating that there are lots of Chinese people interested in
software development, and happy to do so using English-based programming
languages, and using a library written and documented in English (I assume).

>
> Rui Maciel
>

[Seebs]

On 2013-04-25, Keith Thompson <ks...@mib.org> wrote:
> Still, a PDF copy of K&R is most likely a copyright violation.

Seems quite likely, although I'm not sure -- the question of how fair use
applies to media shifts is moderately open.

That said: As someone who has made a living writing now and then, I would
point out that I have never seen any evidence that I should care about
copyright violations of my writing, in general. By and large, if I'm selling
something, I care about sales. The theory that a given non-sale might have
been a sale otherwise is interesting, but I've seen no statistics bearing
out that it's a generally applicable pattern; rather, everything I've seen
suggests that widespread copying of a work tends to increase sales.

I know a lot of people who want to learn to program and can't, right now,
afford books. And worrying about whether they are getting their books
illegally is in general really, really, low on my priority list.

Note: I don't have the legal authority to tell people that they are welcome
to free copies of my shell book, because the publisher has a vote in the
matter. However, having access to concrete sales figures on at least one other
book, and knowing how people copying it freely affected them... Well, I
am pretty sure that people trading PDFs of my book would be in my economic
best interests, whether or not it is authorized by the publisher.

Economics: Weird.

[Seebs]

On 2013-04-25, Jorgen Grahn <grahn...@snipabacken.se> wrote:
> There's also a lot of confusion about what "embedded programming" is.
> My employers call what I do embedded programming, but it's really
> for the most part ordinary Unix server programming.

I don't think this is really a confusion, just... Times change.

When I was first active on comp.lang.c, I had what was at the time a fairly
powerful computer. It had 6MB of memory, I believe, and a 25 MHz processor,
and I think a 200MB hard drive.

Nowadays, I do embedded systems stuff. We do, in fact, I believe, still
actually talk to people about targets that have less than 200MB of available
long-term storage. I don't think I've heard of anyone actually using a
system with under 64MB of main memory with this product. I mean, I'm sure
it must happen, but it doesn't come up much. If I have to look at a target,
it's typically got at least one 700MHz or faster core, and realistically
it's pretty common for it to have 2-8 cores at >1GHz, at least 512MB-1GB
of memory (or quite a bit more), and so on. I take it for granted that users
will want decent performance when assembling filesystems 1GB or more in
size that will be installed on thousands+ of embedded devices.

At which point, developer time tends to be more expensive than storage,
so yeah.

I still remember when I thought it was in some way unreasonable that people
wanted to run the whole GNU toolchain on their target systems in the field.
I've long since gotten used to that. Of *course* people want self-hosting so
they can recompile hundreds of packages from source using autoconf
configuration.

For embedded systems.

[Stephen Sprunk]

On 25-Apr-13 20:49, James Kuyper wrote:
> On 04/25/2013 07:05 PM, Stephen Sprunk wrote: ....

>> ~95% of Americans speak English on some level, including most
>> native Spanish-speakers. Legal immigrants must know it to get a
>> visa in the first place, and their kids are forced to learn it in
>> school. That leaves only illegal immigrants, and many of them pick
>> up English as well to avoid detection and/or get higher-paying
>> jobs.
>>
>> Culturally, I agree that it would be a good to learn Spanish to
>> speak to our neighbors to the south, but it's a poor economic
>> choice--and mandating thatt would be political suicide. Learning
>> Portuguese would be a better economic choice, but Brazilians
>> students are learning English now, so any benefit there would be
>> short-lived.
>
> The entire southwest portion of the US used to be controlled by
> Spanish speaking people, and Spanish remains pervasive throughout
> that region. Many people for whom Spanish is their birth language
> come from families that have been US citizens for 3 generations, or
> longer - some can trace their presence in the region to back before
> it was seized by the US. Spanish was my first foreign language, and
> it remains by far the most useful of the five that I've learned, even
> though I now live in the Maryland (which also, for different reasons,
> has a significant Spanish-speaking population).

Still, most of them speak English as well, aside from the illegal
immigrants, despite potentially speaking Spanish at home.

As noted, making Spanish mandatory in the schools in the southwestern US
would be political suicide. We require _some_ foreign language to
graduate, and many students do choose Spanish, but most schools offer
other languages as well.

>>> - Canada: it has two official languages: english and french.
>>
>> Aside from those living in Quebec or working for the govt, there's
>> not much reason to learn French, since even the Quebecois learn
>> English in school now.
>
> Many Québécois are much more cooperative with those who at least
> attempt to speak with them in French. You can insist on using
> English, but the more obstinate ones will respond by pretending not
> to understand.

My experience in France is that they pretend not to know English, but if
you try to speak French, they will answer in English rather than allow
you to continue butchering their beautiful language. (I speak it well
enough to get pegged as French Canadian, but to the actual French that
still qualifies as butchering their language.)

This is notably unlike in most other countries, where people will
happily speak whatever common language can be found--and that is most
often English. Even if you do speak their language fluently, many still
prefer English just to get practice with a native speaker.

>> 1.8 billion people speak English, compared to 1.3 billion who
>> speak Mandarin. Every student in China is now required to learn
>> English, and it is projected that within a decade China will have
>> more English speakers than the US itself.
>
> I can vouch personally for the fact that the English spoken by many

> of those students is quite poor ... I wouldn't recommend counting

> on being able to communicate with all of them using English.

Spoken English quality varies among non-native speakers, but most
problems can be attributed to starting too late in life, eg. college.
The current (and future) generations of Chinese students will be far
better by the time they reach the job market simply because they're
starting earlier.

[Seebs]

On 2013-04-26, Rui Maciel <rui.m...@gmail.com> wrote:
> The second languages are taught because they are useful to communicate with
> those who don't speak our native language.

And also because thinking in different languages promotes mental flexibility.

> In the last decade or so, english managed to become a de facto esperanto,
> but that was mainly because the US dominated the world's economy and
> academia. Things won't stay like that for long.

They might not, but the network effects may win anyway; at this point,
there's so much literature in key fields in English that you practically have
to learn it anyway. English is the new lingua franca! :)

> Again, a couple of decades ago francophones were using the same arguments to
> justify why it would be silly for them to learn a second language.

... I made the joke above before I'd read that paragraph. But I'm leaving it
now.

> Hardware production is already firmly established in Asia. I wouldn't bet
> that in a decade or so english will still be the prefered language to
> communicate with them.

Hardware production is moving around more thanks to automation, though.

In any event, I think I'd say this: I don't think I've ever regretted learning
something.

[Seebs]

On 2013-04-26, David Brown <da...@westcontrol.removethisbit.com> wrote:
> On 26/04/13 01:47, Seebs wrote:
>> Read, write. Code and language. And don't neglect things like philosophy,
>> psychology, and so on; everything you know can help you be better at
>> programming. Psychology can help you understand people, and understanding
>> people helps you write programs that suit them, or write code they can
>> read. Philosophy can help you decide what to work on. And so on.

> Telepathy is useful too, when you are trying to figure out what a
> customer wants rather than what he says he wants...

Observations: Read Kahneman's _Thinking, Fast and Slow_. Read sites like
"Not Always Right" and "Clients From Hell". Study Miller's Law ("To
understand what another person is saying, you must assume that it is true
and try to imagine what it could be true of.") Do this stuff and you will
find that customer requirements are substantially more approachable.

Still impossible to be consistently right, but you can improve your odds.

> Seriously, that's good advice. There is lots more to programming well
> than just writing code - you have to know /what/ to code.
>
> Other useful related skills are graphical design, economics (programmers
> are notoriously bad at figuring out real-world costs), physics, maths,
> more maths, applied maths, pure maths, and then some more maths.

Yes. Human interface considerations are something programmers in general are
HORRIBLE at. Norman's "The Design of Everyday Things" is another book I
strongly recommend.

[Seebs]

On 2013-04-26, David Brown <da...@westcontrol.removethisbit.com> wrote:

> On 26/04/13 01:47, Seebs wrote:
>> On 2013-04-25, David Brown <da...@westcontrol.removethisbit.com> wrote:
>>> No, "main" does not always have a return parameter - "main" does not
>>> always return, and therefore a return parameter is meaningless.

>> This analysis is incorrect.

>> On at least some systems, the calling sequence depends on what type
>> the return would be if the function returned, so even a function that
>> never returns must have the correct return type.

> If you have such a system, then that would be true. However, I have a
> hard time imagining what could go wrong within the body of main even if
> the calling sequence depended on the return type. I could imagine how
> things could fail on the return from main() if the return type did not
> match the expected type, but not during execution of main() and its
> infinite loop.

> I think your argument here is perhaps technically true, but very much
> hypothetical.

I don't recall details, but I believe there have been systems on which
arguments and return value both went on the stack, so if your function
didn't have the same expectations for its return value as the caller, it
could end up reading the wrong arguments. Not sure, though.

Mostly, though:

I am a big believer in the theory that if something is undefined behavior,
and I don't have a really *good* reason to believe that I absolutely need
to find a way to make it happen, the best answer is to say "that's undefined
and I don't know what will happen".

So the fact that it's undefined is enough to make me think it's unsafe,
because even if it might well work in some environments, it might not in
others. Someone will do something thoughtful like a compiler which mangles
names to denote return types, and the program won't link, or will get a
default main() implementation provided by something like lex/yacc, or
whatever other madness.

> I made a specific point about /small/ embedded systems. I didn't define
> "small embedded systems" here, but Linux (or other OS's capable of
> calling independent programs) do not count as "small" - "small" system
> programs are free-standing rather than hosted.

I would concede this, but I would also argue that even then, it doesn't
necessarily matter; there's nothing *preventing* a freestanding environment
from choosing to use a setup in which main() is called and expected to
yield a return value.

> Typically in embedded systems there are at least two programs which are
> not standard hosted environments with "int main(...)" - the kernel, and
> also the bootloader (such as U-Boot). There may in fact be more levels
> of bootloader, some of which may not have any main() at all.

This is a good point, I hadn't been thinking about the boot loader. And
arguably, whatever's picking up the boot loader is almost certainly something
that someone somewhere wrote as code...

[glen herrmannsfeldt]

Seebs <usenet...@seebs.net> wrote:
> On 2013-04-26, David Brown <da...@westcontrol.removethisbit.com> wrote:
>> On 26/04/13 01:47, Seebs wrote:
>>> On 2013-04-25, David Brown <da...@westcontrol.removethisbit.com> wrote:
>>>> No, "main" does not always have a return parameter - "main" does not
>>>> always return, and therefore a return parameter is meaningless.

>>> This analysis is incorrect.

>>> On at least some systems, the calling sequence depends on what type
>>> the return would be if the function returned, so even a function that
>>> never returns must have the correct return type.

>> If you have such a system, then that would be true. However, I have a
>> hard time imagining what could go wrong within the body of main even if
>> the calling sequence depended on the return type. I could imagine how
>> things could fail on the return from main() if the return type did not
>> match the expected type, but not during execution of main() and its
>> infinite loop.

>> I think your argument here is perhaps technically true, but very much
>> hypothetical.

> I don't recall details, but I believe there have been systems on which
> arguments and return value both went on the stack, so if your function
> didn't have the same expectations for its return value as the caller, it
> could end up reading the wrong arguments. Not sure, though.

But that assumes that there are some arguments. In the case of

void main() { ... /* no arguments ! */

it wouldn't apply. Systems I know of return int in registers, but larger
return values could go on the stack. (Especially struct return values.)

-- glen

[Stephen Sprunk]

On 26-Apr-13 09:36, Rui Maciel wrote:
> David Brown wrote:
>> There are more /native/ speakers of Mandarin than /native/ speakers
>> of English (and Spanish falls between these two). However, there
>> are more people who speak English than any other language - mostly
>> as a second language. Figures vary wildly depending on what levels
>> of competence you look for, but something like 20% is probably a
>> decent estimate (of native and second-language speakers).
>
> The second languages are taught because they are useful to
> communicate with those who don't speak our native language.
> Therefore, their choice is motivated by how useful they might be to
> communicate with others.

But if someone else's second language already matches your native
language, what is the point in learning their native language as your
second language? That is the dilemma native English speakers face.

> In the last decade or so, english managed to become a de facto
> esperanto, but that was mainly because the US dominated the world's
> economy and academia. Things won't stay like that for long.

Even if it doesn't, which remains to be seen, there's a reasonable case
that English will soon reach critical mass, if it hasn't already: it no
longer needs the US to sustain its growth.

> In addition, in some western countries it's much more likely that you
> stumble on someone who speaks mandarin natively than english.

... but you're more likely to stumble across someone who speaks English
as a second language than someone who speaks Mandarin, either natively
or as a second language.

> Again, a couple of decades ago francophones were using the same
> arguments to justify why it would be silly for them to learn a second
> language.

French never reached anywhere near 1.8 _billion_ speakers.

Nor did we, during that era, see _half_ of the world's 6,000 languages
no longer being taught to the next generation. Language extinction on
that scale--and at that speed--is unprecedented in human history.

>> If you narrow the field to people who are seriously interested in
>> programming - and therefore mostly young, literate, reasonably
>> well educated, and familiar with computers, then I expect the
>> percentage of people who can read reasonable English and have at
>> least basic English written and oral skills is going to be very
>> much higher.
>
> Hardware production is already firmly established in Asia. I
> wouldn't bet that in a decade or so english will still be the
> prefered language to communicate with them.

I would. English is the de facto standard for all international
communication these days, even when none of the participants are native
speakers. Even ignoring cultural barriers to learning each others'
languages, English is simply the better investment: it allows one to
communicate with far more people than any other language.

> Regarding software, I've published a small library (written in C, so
> let's pretend it's on-topic) which is distributed under a FLOSS
> license and managed to be somewhat popular. Currently, according to
> the site's download statistics, the most number of downloads are by
> far from China, while those from the US amount to only about 70% of
> that.
>
> Singapore is ranked 4th, and Taiwan ranks 9th, right after the UK.

... and presumably most of those people are able to at least read
English, which supports the point at hand.

[James Kuyper]

On 04/26/2013 06:54 PM, Seebs wrote:
...

> In any event, I think I'd say this: I don't think I've ever regretted learning
> something.

I once read a very short summary of the basic premise behind a
particular horror movie. Ever since then, every once in a while I think
about it and feel overwhelming disgust. That's one thing I greatly
regret learning.
--
James Kuyper

[Tim Rentsch]

David Brown <da...@westcontrol.removethisbit.com> writes:

> [snip all but...]

>
> I made a specific point about /small/ embedded systems. I didn't
> define "small embedded systems" here, but Linux (or other OS's
> capable of calling independent programs) do not count as "small" -
> "small" system programs are free-standing rather than hosted.

I think you misunderstand what these terms mean as the Standard
defines them. A Linux kernel is a freestanding program, or more
accurately, it is compiled to run in a freestanding environment.
A Linux kernel is every bit as much a freestanding program, as
far as the Standard is concerned, as 47 byte programs running on
bare 8-bit processors with 256 bytes of RAM.

[Seebs]

On 2013-04-27, Stephen Sprunk <ste...@sprunk.org> wrote:
> But if someone else's second language already matches your native
> language, what is the point in learning their native language as your
> second language? That is the dilemma native English speakers face.

I find it extremely useful to have been fluent in Mandarin, even though
I've largely lost the vocabulary, because I understand slightly-imperfect
English much better. I know why the subtitles read "DO NOT WANT!"

[David Brown]

Yes, I realise that. But I think I was a little unclear here - programs
running under Linux are "big" (by my intentionally vague definition) and
"hosted" (by more rigid Standard definition), while the kernel itself is
"big" and "free-standing". My distinction between "small" and "big" is
more about the resources available to the program, and the types of
concerns you have when creating efficient programs. Usually it is
enough to simply talk about "small" or "big" without defining any details.

[Tinxx]

I'd try with reading the respective cs books in English if that is the original language they were written in. I did so when I studied computer science about 20 years ago ;-). I still read cs books in English and not in my mother tounge, although the US publishing companies have changed to translating their books. Reason being that the English versions are much easier and much more pleasant to read. You'd be amazed at how some of the big books in cs manage to explain things in simple terms using analogies from every day life. Books written by authors in my country compete in using as many greek symbols as possilbe and as many latin words as possible. It's simply awful and nothing to pick up from.

-- Tinxx

[Tim Rentsch]

It's rather maddening when someone understands what certain
words mean but won't make the effort to use them appropriately
or express what they mean accurately. The situation you mean to
talk about has nothing to do with embedded versus freestanding,
nor in fact "big" versus "small", but whether the hardware
environment is severely resource constrained for the program
in question. Say so.

[David Brown]

I use "big" and "small" in reference to embedded systems (or rather, the
programs running on them). The terms are intentionally vague - /I/ know
they are vague, and I think it's clear to readers that they are vague.
I would rather use such terms rather than something that has a clear
definition (such as "freestanding" vs. "hosted" - although in the
embedded world, that is not clear-cut either). And the term "resource
constrained" /sounds/ like a nice solid term - but does not say anything
about which resources are constrained, and in what way. I have worked
with systems that I call "small", despite having far more processor
speed or memory than older PC's - which are "big".

When I want to be specific, such as "on 8-bit systems" or "on systems
with expensive pointer handling" or "on systems where dynamic memory is
not allowed", then I try to do so. But for general points, where there
is no clear line, I don't want to draw lines - all I want is an
indicator of size.

The point of language is to communicate. If people understand what I
mean by a "small embedded system", then it is an appropriate choice of
phrase. If people don't understand me, then I need to explain better -
but "resource constrained" would be no improvement.



On the other hand, "conforming" to the C standards /is/ a solidly
defined term - I have learned a lot in this thread about its meaning and
implications, and I thank you for your patience and help here. I will
definitely try to be more precise with it in the future.

[Malcolm McLean]

On Tuesday, May 7, 2013 8:23:44 AM UTC+1, David Brown wrote:
> On 07/05/13 05:04, Tim Rentsch wrote:
>
> > David Brown <da...@westcontrol.removethisbit.com> writes:
>
> And the term "resource constrained" /sounds/ like a nice solid term - but
> does not say anything about which resources are constrained, and in what way.
>

"Resource constrained" is used a bit misleadingly.
Typically when you have a tiny embedded system, with say 128 bytes of RAM,
it's designed to run one program, which will be perfectly within its
capabilities. Otherwise the hardware engineer would have plugged in a
slightly bigger processor.
Typically when you are using a supercomputer, with massive memory, disk space,
and processing power, that's because you have a heroic problem to solve,
like simulation of the world's weather system or an attack on protein folding.
You virtually always want more processing power than you have available.

However the first situation is often described as "resource constrained".

[David Brown]

That's absolutely true. It's not the size of the resources that counts,
it's the resources in comparison to the needs of the program.

There are a few differences, however. In the supercomputer application,
you have to worry about the resource constrains when you decide if your
arrays should hold 1 bazillion elements or 2 bazillion. But with the
tiny embedded system, you have to worry about /all/ elements - picking
"uint8_t" rather than "int" for your variables, and so on.

[Tim Rentsch]

I think you missed my point. I'm not talking about needing
to be so specific as to distinguish, say, a Border Collie from
a Rough Collie. I'm talking about cases where someone says
'dog' but what they mean is 'cat'.

> The point of language is to communicate.

No argument there.

> If people understand what I mean by a "small embedded system",
> then it is an appropriate choice of phrase.

And they didn't, so it wasn't.

> If people don't understand me, then I need to explain better -
> but "resource constrained" would be no improvement.

If you don't like the phrasing I used, you're welcome to look for
something better. It does have the advantage that it clearly
identifies the most salient characteristic of the circumstances
under consideration, without getting bogged down in irrelevancies
like embeddedness or freestandingness.

[David Brown]

On 12/06/13 20:10, Tim Rentsch wrote:
<snip>

>> The point of language is to communicate.
>
> No argument there.
>
>> If people understand what I mean by a "small embedded system",
>> then it is an appropriate choice of phrase.
>
> And they didn't, so it wasn't.
>
>> If people don't understand me, then I need to explain better -
>> but "resource constrained" would be no improvement.
>
> If you don't like the phrasing I used, you're welcome to look for
> something better. It does have the advantage that it clearly
> identifies the most salient characteristic of the circumstances
> under consideration, without getting bogged down in irrelevancies
> like embeddedness or freestandingness.
>

This is an old thread, and I've lost track of most of the argument - and
certainly I've forgotten why it started...

But I think we can agree that sometimes we can all be a little better at
explaining exactly what we mean.


"When I use a word," Humpty Dumpty said in rather a scornful tone, "it
means just what I choose it to mean -- neither more nor less."

[paskali]

Dogukan Bayraktar <dg28...@gmail.com> wrote:

> Hi there!
>
> Firstly, sorry for my bad English :/
>
> I'm only 17 and I want to learn C and write perfect codes in C. I'm not
so good in C programming, but I want to become a good C programmer.
>
> My English is not enough to read the programming articles or anything.
> What should I do to become a good C programmer?
>
> - Do you think is English needed for programming?
> - What should I learn in C to become a good programmer?
> - Should I read the example C codes in the web?
> - etc ... ?
>
> I've been waiting your answers.. Please answer to my questions as soon
as possible..
>
> * Thanks ~ !
>

Hi, please read this tutorial:

http://www.phy.pmf.unizg.hr/~matko/C21/ch01/ch01.htm

Yes, you have to learn technical English, it is usefull to read.
It is more easy that spoken language.
Avoid, in a first moment, to learn spoken language especially in the form
of the USA.

--
Pasquale Frega
http://www.webuse.net/pm.php?u=2970

Posted using www.webuse.net

[Keith Thompson]

"paskali" <2970i...@webuse.net> writes:
[...]

> Hi, please read this tutorial:
>
> http://www.phy.pmf.unizg.hr/~matko/C21/ch01/ch01.htm

I wouldn't recommend that tutorial. The examples use an obsolete
version of the language. The first sample program is:

1: #include <stdio.h>
2:
3: main()
4: {
5: printf("Hello, World!\n");
6: return 0;
7: }

which is invalid as of the 1999 standard. "main()" should be
"int main(void)". Even in C89/C90, "int main(void)" is better style.

An example in a later example uses the gets() function without
explaining how dangerous it is.

Question 18.9 of the comp.lang.c FAQ, <http://www.c-faq.com/>, has links
to a number of online C tutorials. Be sure to read the disclaimer
included in the answer.

> Yes, you have to learn technical English, it is usefull to read.
> It is more easy that spoken language.
> Avoid, in a first moment, to learn spoken language especially in the form
> of the USA.

How is that relevant?

--
Keith Thompson (The_Other_Keith) ks...@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"

[paskali]

Keith Thompson <ks...@mib.org> wrote:

>
> I wouldn't recommend that tutorial. The examples use an obsolete
> version of the language.
>

I think it is a good starting point also to understand how many is old how
many is wrong. A lot of code out there is wrote in this manner.

> > Yes, you have to learn technical English, it is usefull to read.
> > It is more easy that spoken language.
> > Avoid, in a first moment, to learn spoken language especially in the form
> > of the USA.
>
> How is that relevant?
>

Yes, i think is relevant, may be that does not seem to you.

[Keith Thompson]

"paskali" <2970i...@webuse.net> writes:
> Keith Thompson <ks...@mib.org> wrote:
>> I wouldn't recommend that tutorial. The examples use an obsolete
>> version of the language.
>
> I think it is a good starting point also to understand how many is old how
> many is wrong. A lot of code out there is wrote in this manner.

Yes, a lot of code is written using obsolete versions of the language.
Pointing that out in a tutorial is fine. Presenting obsolete code
without saying it's obsolete is not.

>> > Yes, you have to learn technical English, it is usefull to read.
>> > It is more easy that spoken language.
>> > Avoid, in a first moment, to learn spoken language especially in the form
>> > of the USA.
>>
>> How is that relevant?
>
> Yes, i think is relevant, may be that does not seem to you.

I asked *how* it's relevant, not *whether* you think it's relevant.

This newsgroup discusses the C programming language, and this
thread is about C tutorials. I fail to see how spoken US English
is relevant to either.

I encourage you to focus on the topic.

[paskali]

Keith Thompson <ks...@mib.org> wrote:

>
> Yes, a lot of code is written using obsolete versions of the language.
> Pointing that out in a tutorial is fine. Presenting obsolete code
> without saying it's obsolete is not.
>

You have to read the entire tutorial and then judge that.

[James Kuyper]

On 06/14/2013 06:08 AM, paskali wrote:
> Keith Thompson <ks...@mib.org> wrote:
>
>>
>> Yes, a lot of code is written using obsolete versions of the language.
>> Pointing that out in a tutorial is fine. Presenting obsolete code
>> without saying it's obsolete is not.
>>
>
> You have to read the entire tutorial and then judge that.

How do you know that he hadn't already done so? Having read the entire
tutorial just now, I found nothing to justify changing the judgments
that Keith expressed up above.

The code at that site is written using an obsolete version of the
language - it relies upon main() being given an implicit return type of
'int'. That was a feature of C90 which was dropped in C99, 14 years ago,
and was never good practice even when it was permitted (which is why it
was dropped). I found similarly dated material in the other chapters
that I browsed. The tutorial doesn't say that it was written for an
obsolete version of the language, and neither did you when presenting it
as a place to go for learning C.

Those web pages have not been updated since 1999-08-31. That partially
explains why the information is out of date, though that doesn't excuse
your decision to mention it as a good place to learn C. However, by that
time most of the features of the new standard had already been agreed to
by the committee and were subjects of public discussion in both
comp.std.c and this newsgroup. Preliminary drafts were easily obtainable
by those who were interested. If the author had been paying attention to
such things, he could have re-written his code to be compatible with
both the current standard and the planned changes to the standard. He
could also have discussed what those planned changes were. He did neither.
--
James Kuyper

[paskali]

James Kuyper <james...@verizon.net> wrote:

Now i understand because someone has tried to open a comp.lang.c
alternative news group, to separate the normal people from the rest.

[James Kuyper]

On 06/14/2013 08:14 AM, paskali wrote:
> James Kuyper <james...@verizon.net> wrote:
>
> Now i understand because someone has tried to open a comp.lang.c
> alternative news group, to separate the normal people from the rest.

comp.lang.c was created for discussion of the C language. I suppose you
could describe that as separating people who have an interest in such
discussions from the people (I guess you could call them "normal") who
have no such interest. If your comment was meant to convey any meaning
other than that, you should explain in more detail, at least if you care
about whether or not anyone understands what you're trying to say.
--
James Kuyper

[David Brown]

On 14/06/13 14:14, paskali wrote:
> James Kuyper <james...@verizon.net> wrote:
>
> Now i understand because someone has tried to open a comp.lang.c
> alternative news group, to separate the normal people from the rest.
>

The comp.lang.c newsgroup is famous for the pedantic nit-picking of some
of the regulars, and some people don't like that. However, the
precision and accuracy of such posts is part of the value of the group -
you will get /correct/ answers if correct answers exist, and if "experts
disagree" then you will hear these experts disagreeing.

But I certainly can't see anything about the posts of James or others in
this thread that justify such a complaint. You have made wild
accusations about bias and inaccuracy in one source (Wikipedia), while
praising a long out-of-date tutorial with code that was bad style even
when it was written. You admit you are no expert on the subject, then
wrote code in a poor style yourself, containing a major error, and
proceeded to fight with multiple posters who /are/ experts, and who
corrected you.

I think the regulars here have been extraordinarily patient with you,
despite your pig-headedness and determination to stay ignorant.


If you want to learn, stay here and listen. If you have already decided
that you know everything you need to know about C and that your ideas
are better than everyone else's, then it's time to leave.

[Keith Thompson]

"paskali" <2970i...@webuse.net> writes:
> Keith Thompson <ks...@mib.org> wrote:
>> Yes, a lot of code is written using obsolete versions of the language.
>> Pointing that out in a tutorial is fine. Presenting obsolete code
>> without saying it's obsolete is not.
>
> You have to read the entire tutorial and then judge that.

Not really. I found serious problems in the first few pages.
That was enough for me to decide that reading the whole thing was
not worth my time. I suppose it was conceivable that the rest of
it made up for those problems, but there are plenty of C tutorials
that *don't* use implicit int and gets(). (James Kuyper did read
the whole thing, and confirmed my tentative conclusions.)

What is your basis, as an acknowedged C non-expert, for maintaining
that that particular tutorial is a good one? If you think that
you're right and multiple C experts are wrong, well, that's a
possibility, but you'll have to convince us.

Consider the possibility that you might be wrong. (I make mistakes
all the time myself; I usually acknowledge them.)

[Les Cargill]

paskali wrote:
> James Kuyper <james...@verizon.net> wrote:
>
> Now i understand because someone has tried to open a comp.lang.c
> alternative news group, to separate the normal people from the rest.
>
>

It may be pedantic nit-picking, but said pedantic nit-picking
is a good thing to be familiar with.

--
Les Cargill

[徐冬冬]

As I know ,English is not so decisive,Aii the way you have some knowledge of English, it is enogh.Just read one or two basic books in your language.perfer to read some famous book , like Modern C programming. then to read programming pearls.I ihink it is Ok.

[Nick Keighley]

On Apr 26, 11:39 am, David Brown <da...@westcontrol.removethisbit.com>
wrote:
> On 26/04/13 01:01, glen herrmannsfeldt wrote:
>
>
>
>
>
>
>
>
>
> > Jorgen Grahn <grahn+n...@snipabacken.se> wrote:
> >> On Thu, 2013-04-25, James Kuyper wrote:
>
> >>> In this newsgroup I've talked with a number of people who thought that
> >>> most, if not all, current C programming is being done for embedded
> >>> platforms. When challenged, none have been able to provide hard numbers
> >>> in support of their claim. To be fair, I know of no good source of
> >>> numbers to disprove the claim, either. But the simple fact that anybody
> >>> believes it is, in itself, evidence for the existence of a fairly large
> >>> amount of embedded C programming going on.
>
> >> There's also a lot of confusion about what "embedded programming" is.
> >> My employers call what I do embedded programming, but it's really
> >> for the most part ordinary Unix server programming.
>
> > Yes, more and more embedded systems run Linux, or something similar.
>
> > I suppose I call it embedded if it boots completely from ROM, EPROM,
> > EEPROM, or FLASH. The latter does not include FLASH interfaced through
> > one of the usual disk interfaces such as SATA.
>
> > The usual NAT router/wireless access point devices run Linux, for
> > example.

I think of myself as a semi-embedded programmer. The systems I work on
aren't on desktops or in server rooms. But my CV seems to go to the
bottom of the heap when I apply for jobs that call themselves
"embeded" (I don't have any problems getting employment otherwise).
The systems I work on do have proper OSs (Windows or Linux)

> I try to make the distinction of "small embedded systems" - basically,
> microcontroller programming where the program runs entirely from flash,
> mostly using flash and ram that are integrated into the microcontroller.
>  Typical cpus are 8-bit or 16-bit devices (like the AVR or msp430), or
> small 32-bit devices (Cortex M family are the most common these days).
> These are usually bare metal, or run embedded OS's like FreeRTOS.

I guess those are the jobs I don't get replies to!

> "Mid level" embedded systems run things like VxWorks or Linux, have
> processors with external ram and flash, but don't have disks, and have
> mostly fixed hardware (you might be able to plug in a USB memory stick,
> but you are not going to change the screen or memory).  Wireless routers
> are in this category.
>
> "High-end" embedded systems are often more like PC's, except that you
> mostly restrict the software and hardware that runs on it, and obviously
> the hardware and software are often specialised.  "Media centres" would
> be an example.

those are the systems I work on. Production lines at the moment. Weird
hardware and cut down versions of the OSs. Mine are diskless at the
moment.

> Of course, these are only vague categories, with plenty of overlap and
> plenty of missing categories.