another bizarre architecture

We had a long thread on that, as I recall

Cheers

PeteS

Poor discipline is the bane of the industry, and I must agree with John on this, even though I prefer to write in C.

#include I have spoken with many a programmer unworthy of the name if only because they think hardware is something that automagically does what they need; it's the product of a great deal of hard disciplined work!

In this, incidentally, I include those who are software engineers and computer scientists (I have yet to divine the distinction).

#undef rant

Discipline is something foreign to many software engineers (but not all, as I can attest from personal knowledge) and is necessary if a product is to be successful.

So the answer seems to be; a disciplined approach is likely to produce successful results. Duh.

Cheers

PeteS

there's no bad consequence from doing fread() on a FILE* that may be NULL. The real problem is ignoring the return from fread, suppose the file is too short for instance.

Bye. Jasen

Source code isn't executed, either. A computer program is an interface between a human programmer and two destinations: downward, to the instruction set of a CPU: upward, to the author himself and to other programmers who need to understand, now and in the future, what is being done and why. The code tells what is being done, and the comments tell why.

The very act of commenting forces a programmer to explain the program to himself, sometimes with novel results.

It's shocking how many programmers and CS teachers don't understand this, or do and can't be bothered.

gave

Skipping comments is reasonable if what's going on is totally obvious, like a nicely-contained Linux file operation. But an embedded systen connects to real-world hardware external to the cozy world of computer languages and operating systems, so some context can be mighty helpful.

I dislike the language because I think it's ugly, but that's a personal affectation. I dislike the culture of C because it so often creates crap products. Fortunately, roughly half of C code, the really bad stuff, never makes it to the street; the projects, or the companies, fail.

John

You're right although I was referring to the larger sense in which source code does describe the instructions to the micro wheras comments are solely for human consumption :)

Those with a CS inheritance aren't the only ones, just the ones with the least excuse.

gave

I'm not sure I completely agree. The commenting can be a lot lighter though if you can refer to a well defined definition. As you can for much of the standard library.

Indeed, especially since some people have been known to produce functions that look like the standard functions but are either incomplete or behave slightly differently. (maybe we can call those homonym functions?)

I can't fault you for the results reasoning although I suspect that has as much or more to do with it's popularity than anything inherit in it. I've seen similar with C++ and Java at the very least.

Robert

--
Posted via a free Usenet account from http://www.teranews.com

On a sunny day (4 Feb 2007 01:31:27 GMT) it happened jasen wrote in :

You are wrong, and I posted an example, here it is again:

#include #include

main() { FILE *fptr = 0; char buffer[100]; size_t bytes_read;

fptr = fopen ("flipflap", "r");

// size_t fread(void *ptr, size_t size, size_t nmemb, FILE *stream); bytes_read = fread(buffer, sizeof(char), 100, fptr);

fprintf(stderr, "bytes_read=%d\\n", (int)bytes_read); }

gcc version 4.0.3 20060104 (prerelease) (Debian 4.0.2-6 grml: ~ # gcc -o test3 test3.c grml: ~ # ./test3 zsh: segmentation fault ./test3

Use brain.

On a sunny day (Sat, 3 Feb 2007 17:54:47 -0500) it happened Robert Adsett wrote in :

You are partly right in my view. If I buy a book in English (I am Dutch), can I require that plent of Ducth lines are inserted so I can read it if my English is broken?

If you are going to do some reading of C files, do you not think you should _AT_LEAST_ be able to read the language fluently? Even more when writing in C. C, written in the right way, other then if cryptic use of variables and functions in made, is very readable. I have worked myself throught tons of sourcefiles that had zero comments, something you learn when using open source..... Sometimes comments just distract.

The reliability of teranews (I once payed for lifetime access to it) is such that I stay clear of it.

Interesting article about a book covering much of this very subject at Salon

Cheers

PeteS

Sorry to have disillusioned you :)

While people do work that way, I don't think any HLLs have been designed that way.

Well, I think maybe English is necessary if you are communicating with English readers ;)

Now her I'll disagree. I've certainly seen uncommented and poorly commented assembly code. No assembler I've seen encouraged comments any more than most HLLs.

The prevalance of commenting, especially meaningful commenting, appears to have to do far more with the people writing the code than the language they are using to write it. The exception might be graphical languages which in my limited experience do not seem to have developed clear commenting techniques.

Robert

--
Posted via a free Usenet account from http://www.teranews.com

On a sunny day (4 Feb 2007 01:31:27 GMT) it happened jasen wrote in :

You are wrong, and I posted an example, here it is again:

PS, you are probably confused with 'read()', read() accepts a fileno, an integer, and if zero reads from stdin.

So this will always read from stdin:

#include #include #include

main() { char buffer[100]; size_t bytes_read;

bytes_read = read(0, buffer, 100);

fprintf(stderr, "bytes_read=%d\\n", (int)bytes_read); }

grml: ~ # gcc -o test3 test3.c grml: ~ # ./test3 asfweaswerwerwerwerwerw bytes_read=24

In case of read() there is an other problem, that the higher level 'fread()' protected us from, and a frequent make mistake is not to call read() again if it returns EAGAIN (and lose data), from libc.info:

- Function: ssize_t read (int FILEDES, void *BUFFER, size_t SIZE) The ead' function reads up to SIZE bytes from the file with descriptor FILEDES, storing the results in the BUFFER. (This is not necessarily a character string, and no terminating null character is added.)

The return value is the number of bytes actually read. This might be less than SIZE; for example, if there aren't that many bytes left in the file or if there aren't that many bytes immediately available. The exact behavior depends on what kind of file it is. Note that reading less than SIZE bytes is not an error.

A value of zero indicates end-of-file (except if the value of the SIZE argument is also zero). This is not considered an error. If you keep calling ead' while at end-of-file, it will keep returning zero and doing nothing else.

If ead' returns at least one character, there is no way you can tell whether end-of-file was reached. But if you did reach the end, the next read will return zero.

In case of an error, ead' returns -1. The following rrno' error conditions are defined for this function:

AGAIN' Normally, when no input is immediately available, ead' waits for some input. But if the NONBLOCK' flag is set for the file (*note File Status Flags::), ead' returns immediately without reading any data, and reports this error.

*Compatibility Note:* Most versions of BSD Unix use a different error code for this: WOULDBLOCK'. In the GNU library, WOULDBLOCK' is an alias for AGAIN', so it doesn't matter which name you use.

On some systems, reading a large amount of data from a kernel cannot find enough physical memory to lock down the user's pages. This is limited to devices that transfer with direct memory access into the user's memory, which means it does not include terminals, since they always use separate buffers inside the kernel. This problem never happens in the GNU system.

Any condition that could result in AGAIN' can instead result in a successful ead' which returns fewer bytes than requested. Calling ead' again immediately would result in AGAIN'.

BADF' The FILEDES argument is not a valid file descriptor, or is not open for reading.

INTR' ead' was interrupted by a signal while it was waiting for input. *Note Interrupted Primitives::. A signal will not necessary cause ead' to return INTR'; it may instead result in a successful ead' which returns fewer bytes than requested.

IO' For many devices, and for disk files, this error code indicates a hardware error.

IO' also occurs when a background process tries to read from the controlling terminal, and the normal action of stopping the process by sending it a IGTTIN' signal isn't working. This might happen if the signal is being blocked or ignored, or because the process group is orphaned. *Note Job Control::, for more information about job control, and *Note Signal Handling::, for information about signals.

Please note that there is no function named ead64'. This is not necessary since this function does not directly modify or handle the possibly wide file offset. Since the kernel handles this state internally, the ead' function can be used for all cases.

This function is a cancellation point in multi-threaded programs. This is a problem if the thread allocates some resources (like memory, file descriptors, semaphores or whatever) at the time ead' is called. If the thread gets cancelled these resources stay allocated until the program ends. To avoid this, calls to ead' should be protected using cancellation handlers.

The ead' function is the underlying primitive for all of the functions that read from streams, such as getc'.

This is a bit out of context for these newsgroups, and more for comp dot os dot linux dot development dot apps and related.

Why have the people in this thread been so belligerent? Most of us in this group (c.a.e) can remain civil in spite of our disagreements.

In this case CBF was simply making a point, not insulting anyone.

-- Michael N. Moran (h) 770 516 7918

5009 Old Field Ct. (c) 678 521 5460 Kennesaw, GA, USA 30144

"So often times it happens, that we live our lives in chains and we never even know we have the key." The Eagles, "Already Gone"

The Beatles were wrong: 1 & 1 & 1 is 1

Shades of an earlier thread ;)

Maxim is still fighting that, and unsuccessfully it seems. We look at actions, not PR spin, of course. If it's still being discussed this way then Maxim still hasn't mended it's ways, obviously.

Cheers

PeteS

Thanks for the ref: I just ordered a copy.

This is profound:

"Programmers are programmers because they like to code"

That goes a long ways towards explaining the problem.

John

So true.

I have ordered a copy as well.

Perhaps this explains much of the difference; hardware designers like to design, but due to the discipline forced upon us by the task, we ojnly design new subsystems *when we must*.

When we need a function that already exists (whether from elsewhere or our own library) , there has to be a compelling reason not to use it, in contrast with the comment above where programmers will re-invent it almost every time with all the attendant issues of something new.

Cheers

PeteS

So-called 'Computer science' isn't.

Just my opinion, of course

Cheers

PeteS

Commenting code *properly* requires a certain discipline. I comment my code as accurately as possible (and reference the original requirement if possible) for many reasons, not least when I go back to it in 6-12 months and wonder why the F*** I did something.

Proper comments in code are a requirement for proper development just as proper documentation in hardware design is necessary.

The fact that many lack discipline in no way changes the requirement.

Cheers

PeteS

And because of the cost and turnaround time of an assembly, we check our work carefully before we commit it to copper. Software, because it can be changed in minutes, without making pads fall off boards, usually doesn't get checked at all before it's run. So the bugs you fix are the bugs you find.

I like to design new circuits, but that increases the obligation to check/breadboard/simulate them before commiting them to layout.

John

You are embarrassing yourself by not recognizing the difference between pointer (an integer type, where zero / nil is zero / nil and no approximation occurs) and the floating point type (where representation truncation based approximation does occur).

--
 JosephKK
 Gegen dummheit kampfen die Gotter Selbst, vergebens.  
  --Schiller

Precisely. Rather than finding the bugs that exist.

I love to design new things, but I must minimise risk as must you. So I design the new stuff (and have great fun doing it) while re-using as much as I can for the boring 'already done this' stuff.

This might need to be a new thread: Why hardware designers have more discipline and fewer bugs.

Cheers

PeteS