C examples and codes

[Ian Collins]

On the contrary, there are much better resources along these lines
available. If diving into OS code and OS utilities is an approach you
want to try, I'd recommend the OpenBSD sources at http://www.openbsd.org/.
The code is generally of extremely high quality with few bugs, and
largely written in Standard portable C. The style is generally clear,
straightforward, and easy to read - and consistent.

Another alternative that shares the above attributes with the added
bonus of at least one good explanatory book and a great search tool
(http://cvs.opensolaris.org/source/) is the OpensSolaris source.

 

[Philip Potter]

I think that implementations without floating point are disappearing
quite fast. Actually, the only one I used was in a DSP some years ago,
where we did not bother with that since the circuit did not support it
and we had like 40-50K of RAM.

But those are extreme environments.

You misunderstand; the standard allows for floating-point which is not
IEEE 754 (aka IEC 559) floating-point. For example, you could use a
decimal-based system (FLT_RADIX == 10). IEEE 754 has all sorts of
requirements (denormal numbers, infinities, NaNs, and certain
implementation details of math functions) which a specific
implementation may not care to fulfil.

 

[Ian Collins]

Why?

The operating system will cleanup after the program closes!
Why it is a bad practice?

All fine and dandy until you move the code into a library for reuse
later. Why start of teaching bad habits when it is just as easy to
teach good ones?

I mention this as a valid memory allocation strategy in the chapter
about memory allocation!

If the programs makes only allocation and almost no free() then why
bothering with freeing the memory at all?

That's a very short sighted, if not slapdash attitude.

 

[Mark McIntyre]

*shrug* I won't lose any sleep.

Thats fortunate, because you will ***never*** convince Jacob that
pointers are not integers.

And what happens when your daemon doesn't terminate, but just keeps on
mallocing more and more memory....

You really are a shockingly bad programmer if you seroiusly advocate
you don't need to clear up after yourself.

If you are sloppy with scratch code you will also be sloppy with
production code.

Quite.

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Ian Collins]

I think that implementations without floating point are disappearing
quite fast. Actually, the only one I used was in a DSP some years ago,
where we did not bother with that since the circuit did not support it
and we had like 40-50K of RAM.

You jest? I bet there's more C written and compilers for 8 bit, limited
memory devices that for systems with FPU support.

But those are extreme environments.

s/extreme/mainstream/

 

[Philip Potter]

And what happens when your daemon doesn't terminate, but just keeps on
mallocing more and more memory....

You really are a shockingly bad programmer if you seroiusly advocate
you don't need to clear up after yourself.

To be fair to Jacob in his tutorial he only advocates this for programs
which do terminate. It's still a shocking habit though.

 

[John Smith]

jacob navia wrote:

I sent a message about my tutorial,
that has taken me years of work.

Before making such sweeping statements, Mr Bode could (maybe)
try to see the tutorials that aren't crap...

Jacob, for a long time I thought you were getting a raw deal in
c.l.c. Now I'm not so sure. The fact of the matter is, you don't
have a particularly good track record. Have you looked at the
most recent post in your own lcc-win32 newsgroup? Does it deserve
a response or do you think it best just to ignore reports of
errors in your code?

JS

 

[Keith Thompson]

Do you discuss the rules imposed by the standard, for example, that
int is at least 16 bits?

Correct. I will add that.
Great.

p54:
"1.13.10 union.
You can store several values in a single memory location or a group
of memory locations with the proviso that they can't be accessed at
the same time of course. This allows you to reduce the memory
requirements of a structure, or to interpret a sequence of bits in a
different fashion.
For a detailed discussion see "Unions" on page 107."
This isn't very clear. It sounds like I can store multiple variables
in a union simultaneously, provided I don't access them
simultaneously.

Well... that's a union dear.

Storing a value in one member of a union, result of accessing a
different member is unspecified except in some very narrow
circumstances. (Consider that when you're wrong about something, and
somebody points it out, that's not a good time to be condescending,
"dear".)
[...]

Why did you quote all that if you're not going to respond to it?

I think that implementations without floating point are disappearing
quite fast. Actually, the only one I used was in a DSP some years ago,
where we did not bother with that since the circuit did not support it
and we had like 40-50K of RAM.

But those are extreme environments.

You've missed the point.

The standard requires floating point; types float, double, and long
double are not optional. (But a non-conforming implementation that
doesn't support floating-point might be quite useful.)

IEEE 754 (more precisely IEC 60559, but most people just think of it
as "IEEE floating-point") is a specification for an implementation of
floating-point numbers. A conforming C implementation can provide
floating-point support in a form other than what IEEE 754 specifies.

Floating-point formats other than IEEE 754 are becoming rarer (that's
the point of having a standard, after all), but I've worked on systems
with a number of other formats (VAX, IBM mainframe, Cray, PDP-11). I
think, but I'm not certain, that it's not uncommon even for modern
implementations to use the IEEE 754 *format* without providing all the
bells and whistles specified by the IEE 754 standard.

A C tutorial certainly needs to discuss floating-point, but it needn't
(and shouldn't) go into the details of IEEE 754. Issues of roundoff
errors, inexact representations, and so forth, apply to any
floating-point format, not just IEEE 754.

 

[Keith Thompson]

Philip Potter wrote: [...]

The point is that it is more harmful that helpful to think of
pointers as integers. (And that machine addresses are not
necessarily just integers, regardless of how many implementations
you find where they are.)

Well, this is a disagreement. I hope you do not mind.

Addresses are not integers. If a C tutorial claims that they are,
that alone is enough reason for me to recommend avoiding it.

I hope you do not mind.

 

[rosewater]

Why shouldn't I? I mean using windowed output is quite normal this
days.

Don't be stupid. Most C programs are in embedded systems. Almost all
desktop C programming uses a terminal of some sort, and a significant
proportion is still done via a teleprinter or similar.

You are at page 2. Do not be surprised if I haven't explained
EVERYTHING Read ON!

If there is incomplete and misleading information on page 2, that
isn't much of an incentive to read ON.

If you read two sentence before the table you will see:
"The implementation of the C language by the lcc-win compiler..."

So much for this being the chapter on "standard C".

Well... that's a union dear.

You should be aware that this sounds extremely camp in English, with
homo-erotic overtones.

True. Eliminated msize and expand. And marked alloca and GC_malloc by
saying that they may be absent in other systems.

Why mention them at all? They're a useless addition to lcc-win32.

Yes.
It is very convenient. The lcc compiler does that.

Completely barmy. You clearly don't have the first idea about good C
programming practice. Anyone who makes a statement like this has NO
BUSINESS writing a tutorial purporting to teach others C.

I think that you have obviously a bias against me. But your comments
are welcome. I will go on working in this.

Why do you always think the world is against you? If you were prepared
to act on the constructive criticism you receive, your compiler and
its tutorial might not be such a shambles.

 

[jacob navia]

jacob navia wrote:



Jacob, for a long time I thought you were getting a raw deal in c.l.c.
Now I'm not so sure. The fact of the matter is, you don't have a
particularly good track record. Have you looked at the most recent post
in your own lcc-win32 newsgroup? Does it deserve a response or do you
think it best just to ignore reports of errors in your code?

JS

Hi John

Your post started a long re-research program trying to find the most
adequate definition of kurtosis. Then, I left it for tomorrow, and
then many other things came. I should have acknowledge that
and tell you I am researching your post.

Excuse me for the delay.

 

[rosewater]

I am using an old version of frame maker from adobe since I have no
money for the upgrade (US$ 350).

And it has bugs DAMM!!!
And I did not see that one.

Well, live by the sword, die by the sword. Given that you choose to
give nothing back to the community, instead releasing your compiler
under a non-free license, you are hardly in a position to complain
that Adobe's software is proprietary.

Why don't you ask your daughter to download the new version at the
same time as she's illegally downloading Japanese movies?

 

[Ben Bacarisse]

If I do not explain those immediately, they will NOT be able to
compile!

I know why you do it. I have no problem with it as a style, but it
means your tutorial reads as being very compiler and OS specific. You
said the first part is about "standard C" but I think there is a lot
of other stuff in there. Personally, I'd put it in an appendix. This
has the advantage that you can have several appendices -- one for each
compiler/IDE/OS or whatever.

and the sentence CONTINUES "in most implementations!"

Not in the version I am looking at right now (download an hour or so
ago). If you have a corrected version I have just wasted my time
looking at. I think the best correction (in a tutorial on C) would
have been to say nothing about code generated from pointer
conversions.

And MSVC extension and Watcom extension and gcc extension for the
32 bit version of those at least.

It is not in gcc as far as I can see. What do you mean by this?

(Oddly, this is
Not "oddly"

Eh? You state: "in lcc-win32 for the Intel platform, in 32 bits, long
and int are compatible". Immediately followed by the correct rules
which imply (correctly) that int and long are not compatible types.
It loos odd to me. I don't see how the platform details have anything
to do with it.

Well, I do not see any errors.

And you may have fixed them. We are obviously reading different
texts but there were quote a few in the text I saw.

 

[Thad Smith]

Thats fortunate, because you will ***never*** convince Jacob that
pointers are not integers.

Pointers are objects stored in some number of bytes. A group of bytes
can be interpreted as a bit string, which can be interpreted as an
integer. What's the big deal about interpreting a group of bytes as an
integer? C even defines optional types intptr_t and uinptr_t for that
purpose. The important issue is what meaning, if any, you give to the
value of the integer.

You can say the same thing about floating point representations.

 

[Keith Thompson]

Pointers are objects stored in some number of bytes. A group of bytes
can be interpreted as a bit string, which can be interpreted as an
integer. What's the big deal about interpreting a group of bytes as
an integer? C even defines optional types intptr_t and uinptr_t for
that purpose. The important issue is what meaning, if any, you give
to the value of the integer.

No, intptr_t and uintprt_t, if they exist, can hold *converted*
pointer values. In many implementations, conversion of a pointer to
an integer of the same size just reinterprets the representation, but
the language doesn't guarantee that.

You can say the same thing about floating point representations.

Yes, you can. On one system I just tried, the float value 1.25 can be
interpreted as the integer value 1067450368. How is that useful?

All object representations in C are made of bits, and can therefore be
treated as integers. But thinking of pointers as integers is
misleading, potentially dangerous, and not useful, unless you're doing
*very* low-level work.

Pointers are pointers. Integers are integers.

 

[Thad Smith]

No, intptr_t and uintprt_t, if they exist, can hold *converted*
pointer values. In many implementations, conversion of a pointer to
an integer of the same size just reinterprets the representation, but
the language doesn't guarantee that.

Good point: a converted value isn't necessarily the value of a pointer
object interpreted as an integer.

All object representations in C are made of bits, and can therefore be
treated as integers. But thinking of pointers as integers is
misleading, potentially dangerous, and not useful, unless you're doing
*very* low-level work.

I think the most important use is as examples of the use of pointers.
Giving a pointer variable an example value helps for illustration. Of
course, the values used might not make sense for a particular
implementation, but serves the purpose. To me, it's a simple way to
illustrate, while realizing the limitations of an illustration.

I have not encountered any misleading, dangerous, and useless side
effects, but your experience may be different.

 

[Mark McIntyre]

Pointers are objects stored in some number of bytes. A group of bytes
can be interpreted as a bit string, which can be interpreted as an
integer. What's the big deal about interpreting a group of bytes as an
integer?

Nothing. This doesn't mean that a pointer *is* an integer.

You can say the same thing about floating point representations.

Indeed. This does not mean a floating point number *is* an integer.
Thank you for making my point...
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Wade Ward]

Another alternative that shares the above attributes with the added
bonus of at least one good explanatory book and a great search tool
(http://cvs.opensolaris.org/source/) is the OpensSolaris source.

This suggestion is less non-standard than I thought it was going to be.
This is the header list for bootadmin.c.
/* Headers */
36 #include <stdio.h>
37 #include <errno.h>
38 #include <stdlib.h>
39 #include <string.h>
40 #include <unistd.h>
41 #include <sys/types.h>
42 #include <sys/stat.h>
43 #include <stdarg.h>
44 #include <limits.h>
45 #include <signal.h>
46 #include <sys/wait.h>
47 #include <sys/mnttab.h>
48 #include <sys/statvfs.h>
49 #include <libnvpair.h>
50 #include <ftw.h>
51 #include <fcntl.h>
52 #include <strings.h>
53 #include <utime.h>
54 #include <sys/systeminfo.h>
55 #include <sys/dktp/fdisk.h>
56 #include <sys/param.h>
57 #if defined(__i386)
58 #include <sys/ucode.h>
59 #endif
60
61 #include <pwd.h>
62 #include <grp.h>
63 #include <device_info.h>
64
65 #include <locale.h>
66
67 #include <assert.h>
68
69 #include "message.h"
70 #include "bootadm.h"
I hope I get time to take another crack at installing a solaris partition.
It comes out of the box with a C99 capability (up to bugs).