Programming in standard c

S

SM Ryan

# Presumably filesize("/dev/random") could behave sensibly without

Presumably the interface definition includes appropriate
caveats and restrictions, and the implementor abides by the
promises made in the interface.

# The set of functions in the C standard library is not a carefully
# engineered coherent interface. The choice of which functions to

Standards committee are political, and you vote by buying in
rather than personal technical excellence. Somebody has to pay
the bills; we could use government funding and then let the
government decide who is technically excellent. I doubt the
politics will disappear.
 
S

SM Ryan

# >>>> AlphaServer DS10L Noname pc clone (my machine) 466Mhz CPU
# >>>> EV6 2GHZ Dual core AMD
# >>>
# >>> Remember, CISC vs RISC !
# >>
# >> The RISC idea was to reduce the instructions and speed up the clock.
# >
# > No. Suggest you read up on this.
#
# Pedantic.

Program to cope with or avoid endian and integer size issues.
Then you don't have to worry about cisc vs risc.

It turns out the only time I know if I'm running on Intel Macs
or PPC Macs is if I have a program error (like parameter type
mismatches) that show different errors on the machines. Apple
can fight with IBM and Intel if they want. My code runs the
same either way.
 
K

Keith Thompson

SM Ryan said:
# Presumably filesize("/dev/random") could behave sensibly without

Presumably the interface definition includes appropriate
caveats and restrictions, and the implementor abides by the
promises made in the interface.

# The set of functions in the C standard library is not a carefully
# engineered coherent interface. The choice of which functions to

Standards committee are political, and you vote by buying in
rather than personal technical excellence. Somebody has to pay
the bills; we could use government funding and then let the
government decide who is technically excellent. I doubt the
politics will disappear.

Please be courteous enough to leave attribution lines in place. I
wrote the quoted material above (the paragraphs starting with
"Presumably filesize" and "The set of functions").
 
S

Syren Baran

Walter said:
I don't see how that follows. For example, Appendix F of C99,
describing behaviours of floating point arithmetic, is part of
the C standard and yet specifically says that the rules there
only apply if a certain macro is defined. It is completely conforming
to have floating point that behaves differently than described in
Appendix F, as long as that macro is not defined. Thus, there are
parts of the C language standard which need not be implementable
on every device that can be programmed in C.

Nice, but trash talk nonetheless.
Thus the "real" C is a subset of the other "real" C.
As a programmer or developer, call it as you wish, i cant depent on the
feature. You can call it standard if you wish, i call it an additional
library or function, no more, no less.
It may be available, maybe,maybe not.
Of course you may argue against my point of of view that standards
should define the minimum capability to ensure compatibility[1].
But i just got to tell you, C{whatsoever} floting point works and if it
doesnt, sorry, then screw that standard.
Yeah, i usually check the docs for errors. If a documention states
"floating point" math allowed and some hidden appendix states "unless.."
its rubbish.
Define the standard. Define the extensions.
That point stands no matter how long you argue or want to me to recite it.

[1]There are differences between "may" and "must". "Must" is a feature
"may" is a library.
 
J

James Kuyper

And if you do ls again, one second later, all of those files might be
gone or different sized. If you relied on the answer that you got,
you would (at best) get the wrong answer on occasion. If you expected
that the size you got would hold all of the file, and if someone added
a record, then your memory allocation to hold it is too small and when
you read the data, the operation will overwrite memory. If you can
come up with a simple work-around for this obvious and fundamental
problem, I would like to hear of it. ....

I am surprised that you do not understand the ramifications of not
being the only one allowed to access a file.

I've stayed out of this part of the discussion, but I've decided that I
have to defend at least this aspect of Jacob's code. Sure, it's possible
for a file to change it's contents while you are working on it.
However, whether or not it's necessary or even appropriate to write code
which copes with that possibility depends upon the application.

I only remember one time in the last 3 decades where I wrote a program
which was actually intended to produce it's desired results despite the
possibility that it's input file might change while reading it. That
program worked by making sure the file didn't change, by using POSIX
file and record locking (I remember that I needed both file and record
locking in the same program - obviously not for the same file). For most
of the other programs I've ever written, failing gracefully by producing
an informative error message and avoiding undefined behavior is all that
they are expected to do in such a situation. For most of those programs,
it's the only thing that they could do.

It's completely normal for a program to require that it's input files be
changed, if at all, only by the program itself. The overwhelming
majority of the programs I've written, and most of the programs I use,
have precisely that requirement. It is entirely routine and normal to
take the precautions needed to ensure that a program's input files are
not subject to change during the running of the program: we use file
permissions to prevent unauthorized writes. We write scripts which make
sure that the programs which create the input files are complete, before
starting the programs which read them. W set aside working areas, and
count on other users who do have group-write permissions to those
working areas to be polite enough not to exercise those permissions
while we're using those areas.

There's obviously programs that do need to deal with input files that
might change while they are being read. I frequently use mail readers
and version control systems that must be able to deal with such
situations. However I think it's inappropriate to impose such a
requirement on all programs, regardless of their purpose.
 
A

Army1987

Serve said:
Army1987 said:
Serve Lau wrote:
[snip] In fact writing
fopen("LPT1:", "r"); is already not portable anymore in the sense that
your
code wont work on multiple systems. Same goes for most of the other
system
dependant files mentioned.
Yeah, reading from a printer is veeeeery non-portable...

Not sure what you mean with this, does fopen("LPT1", "r") return a valid
FILE * on Linux for instance?

It was a sarcastic way of saying 'You meant fopen("LPT1:", "w"), not "r",
right?'.
 
S

Serve Lau

Army1987 said:
Serve said:
Army1987 said:
Serve Lau wrote:
[snip] In fact writing
fopen("LPT1:", "r"); is already not portable anymore in the sense that
your
code wont work on multiple systems. Same goes for most of the other
system
dependant files mentioned.
Yeah, reading from a printer is veeeeery non-portable...

Not sure what you mean with this, does fopen("LPT1", "r") return a valid
FILE * on Linux for instance?

It was a sarcastic way of saying 'You meant fopen("LPT1:", "w"), not "r",
right?'.

with "r" fopen returns a valid pointer on windows. Why would you want to
open for writing when you just want to ask file size?
 
S

Syren Baran

jacob said:
And in machines with no file system files do not have any sense.
Completely wrong.
Even on a machine without any persistant storage it would be wrong.
Actually the whole file system is a file, e.g. /dev/sda2 in my case. The
whole disk is a file, even if there is no filesystem in the media.
Actually even stdin and stdout are files. Same holds true for a mouse
and a joystick.
In a 8 bit micro controller maybe there is no sense in implementing long
longs...
Care to explain why?
 
H

Harald van Dijk

Completely wrong.

Completely right.
Even on a machine without any persistant storage it would be wrong.
Actually the whole file system is a file, e.g. /dev/sda2 in my case.

That's because your /dev/ is a filesystem, or a directory on a
filesystem, providing the sda2 file.
The
whole disk is a file, even if there is no filesystem in the media.

True, there's no file system on the media, but there's a file system in
memory, and your operating system is what provides the layer required to
access data by name.
Actually even stdin and stdout are files. Same holds true for a mouse
and a joystick.

Again they're files on a filesystem.

When an implementation doesn't support any file system, the concept of
files doesn't make sense. When an implementation does support file
systems, files make sense, even if the implementation can only arrange to
store the contents of files in memory.
Care to explain why?

Because while it's possible to emulate 64-bit arithmetic on a processor
that doesn't natively support it, depending on the processor and the
program, it may be too slow to be useful.
 
J

jacob navia

Syren said:
Completely wrong.
Even on a machine without any persistant storage it would be wrong.
Actually the whole file system is a file, e.g. /dev/sda2 in my case. The
whole disk is a file, even if there is no filesystem in the media.

You have a file system, or I do not know where /dev/sda2 comes from...
You have no file system in that particular disk, but there is a file
system to access that device as a single file...
Actually even stdin and stdout are files. Same holds true for a mouse
and a joystick.

Yes, because you have a file system in your OS. I am speaking about
a machine for controlling some hardware where there is just a program,
some flash memory for data, and that's all.
Care to explain why?

If you can't understand that it means that you are deliberately trying
to start a polemic because "jacob is always wrong and always speak
nonsense", to please your friends...

In an 8 bit microcontroller, there is with high probablity no NEED
for 64 bit arithmetic, and if you would need it it would be so
slow that it would be useless. Besides, those machines have little
memory to go around, and moving 64 bit integers and loading all the
software needed for that would explode the requirements for the
program.
 
S

Syren Baran

Harald said:
Completely right.


That's because your /dev/ is a filesystem, or a directory on a
filesystem, providing the sda2 file.
Perhaps we have differing opinions on what a file system is.
Ext2/3,Reiserfs,ZFS,NTFS and FAT are surely filesystems.
A simply hierarchical structure is not necesarily a file system. Would
you consider a linked list a file system?
sda is placed within the filesystem hierachy, but that is not necesarry.
On a device without a filesystem it could be called just "sda".
On a device without an OS there could only one file, call it "storage"
or whatever, which could be opened normaly without requiring a file system.
True, there's no file system on the media, but there's a file system in
memory, and your operating system is what provides the layer required to
access data by name.

Right, "access data by name". Thats why, e.g. open has its char*
argument. This does not necesarily imply a file system.
Again they're files on a filesystem.
Stdin an stdout are files on a filesystem? They have file handles
associated with them. Where is "1" on my filesystem, e.g. "somecommand
2>&1"?
When an implementation doesn't support any file system, the concept of
files doesn't make sense. When an implementation does support file
systems, files make sense, even if the implementation can only arrange to
store the contents of files in memory.
As long as there is something that is at least either readable or
writable the concept of a file can make sense.
Because while it's possible to emulate 64-bit arithmetic on a processor
that doesn't natively support it, depending on the processor and the
program, it may be too slow to be useful.
The keyword here is "may". I will fully agree to "There may be no sense
in supporting long longs on a 8 bit microcontroller", but not to the
unconditional sentance above.
 
J

jacob navia

The keyword here is "may". I will fully agree to "There may be no sense
in supporting long longs on a 8 bit microcontroller", but not to the
unconditional sentance above.

You are completely BLIND. You have just CITED this
sentence:

<quote>
In a 8 bit micro controller maybe there is no sense in implementing
long longs...
<end quote>

I see a clear "maybe" there. But YOU do not see it. Your brain doesn't
want to see it because jacob is always wrong.

Since you do not see it, it doesn't exist of course. And from
a conditional sentence you make an "unconditional sentence"
and there you go...
 
S

Syren Baran

jacob said:
You have a file system, or I do not know where /dev/sda2 comes from...
You have no file system in that particular disk, but there is a file
system to access that device as a single file...
Simply put. A file system starts making sense if you have a lot of
files. Especially if they are supposed to be in some kind of order.
Take real world files (where you place sheets of paper in), or books, as
an example. There is no need for a system, or order, if you only a few a
few books or files. On the other hand a real world library would surely
have a system for storing them.
Yes, because you have a file system in your OS. I am speaking about
a machine for controlling some hardware where there is just a program,
some flash memory for data, and that's all.
And how would you access that flash memory? Maybe open("flash",RW)?
The whole flash memory is a file. No need for a file system.
If you can't understand that it means that you are deliberately trying
to start a polemic because "jacob is always wrong and always speak
nonsense", to please your friends...
No, as i wrote in another reply "It MAY make no sense to implement long
longs on an 8bit microcontroller".
Your sentance above is is unconditional and thus false, simple as that.
In an 8 bit microcontroller, there is with high probablity no NEED
for 64 bit arithmetic, and if you would need it it would be so
slow that it would be useless. Besides, those machines have little
memory to go around, and moving 64 bit integers and loading all the
software needed for that would explode the requirements for the
program.
Following that logic it makes no sense to implement a double precision
floating point library on a 16bit device with no arithmetic processor?
Well, i guess a calculator app on an old phone is not worth considering.
Nor was there any sense in scientific calculations on old DOS boxes, right?
 
S

Syren Baran

jacob said:
You are completely BLIND. You have just CITED this
sentence:

<quote>
In a 8 bit micro controller maybe there is no sense in implementing
long longs...
<end quote>
Please except my apology. I overlooked that word.
 
K

Keith Thompson

jacob navia said:
You are completely BLIND. You have just CITED this
sentence:

<quote>
In a 8 bit micro controller maybe there is no sense in implementing
long longs...
<end quote>

I see a clear "maybe" there. But YOU do not see it. Your brain doesn't
want to see it because jacob is always wrong.

Since you do not see it, it doesn't exist of course. And from
a conditional sentence you make an "unconditional sentence"
and there you go...

And it doesn't even occur to you that it might have been an honest
mistake.

Please take a moment to stop and think before assuming that everything
is part of the Vast Anti-jacob Conspiracy. Trust me, Syren Baran
hasn't even shown up at any of the meetings. :cool:}
 
R

Randy Howard

Please take a moment to stop and think before assuming that everything
is part of the Vast Anti-jacob Conspiracy. Trust me, Syren Baran
hasn't even shown up at any of the meetings. :cool:}

When/where is the next meeting being held?
 
R

Richard

Richard Heathfield said:
Serve Lau said:


Fine. All this means is that the Java standard library designers have taken
some arbitrary decisions and enshrined them in a standard library. Because
they are not fools, we can presume that these arbitrary decisions were
taken as intelligently as possible, but nevertheless the decisions they
have made will necessarily ignore some of the issues discussed in this
thread.

No. Not ignore them. Discard them as the kind of pedantic oneupsmanship
that has place in the real world where real, practical solutions are
required.

Like the strdup function, these functions have a use and are documented
to perform a certain task. And they do that task well.
 
D

dj3vande

Keith Thompson said:
Note that, in many implementations, the trick of fseek()ing to the end
of a file and calling ftell() to get the offset actually works, at
least for files whose size doesn't exceed LONG_MAX. It's not
portable, of course, but if you happen to know that your program will
run only on systems where that works, it's probably no worse than
invoking some system-specific function like fstat().

I disagree that it's no worse.
If you use fseek() and ftell(), and try to build and run your program
on a system where the assumptions don't hold, it will silently accept
it until you run into a file that breaks one or more of the
assumptions. If you use fstat() and try to do the same thing, you'll
get a warning or error at compile time, and shouldn't have too much
trouble working out what it's trying to do and how to do it on the
system you're porting to, which ends up taking rather less total effort
to get the port working.

So unless you have an automated way to track the assumptions you're
making and verify that they hold on all the systems you try to build
on, you're probably better off with the explicitly nonportable code
than with code that makes nonportable assumptions about standard
interfaces.


dave
 
K

Kelsey Bjarnason

[snips]

Yes, this is 100% clear logic. I will apply it then.

I doubt it, but let's see.
1) You can't open a file with
fopen("name","a+")
since somebody else could grow the file after the file is positioned at
EOF, so you would overwrite his data.

You could, or the system could prevent one user writing, or it could to
the equivalent of a copy-on-write with subsequent merge, or it could
append your data to whatever end-of-file is at the exact time of write and
do the same for his, or...

The mechanics of this are beyond the scope of the language, for one thing,
and are beyond the scope of trivial file management for another. If you
need protection against this sort of thing, you need to be using at the
very least a locking mechanism, and perhaps a database instead of a simple
file. None of which has bugger all to do with the problem at hand.
2) ftell/fseek/ and in general all file primitives should be dropped
from the standard.

Oh, indeed. After all, if they're useless in _one_ case, they must, of
course, be useless in _all_ cases. You can't really be that simple.
I have answered this thousand times but you still come back with the
same nonsense!

If we keep coming back with the same nonsense, why can't you come up with
a single, valid response to any of it?
 
K

Kelsey Bjarnason

[snips]

Look "CJ" whoever you are:

You know NOTHING of where I have programmed, or what I am doing.
Versions of lcc-win run in DSPs with 80k of memory, and only
20 usable.

And Win98 on a 486?
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,904
Latest member
HealthyVisionsCBDPrice

Latest Threads

Top