473,836 Members | 2,332 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Is C99 the final C?

I was just thinking about this, specifically wondering if there's any
features that the C specification currently lacks, and which may be
included in some future standardization .

Of course, I speak only of features in the spirit of C; something like
object-orientation, though a nice feature, does not belong in C.
Something like being able to #define a #define would be very handy,
though, e.g:

#define DECLARE_FOO(bar ) #define FOO_bar_SOMETHI NG \
#define FOO_bar_SOMETHI NG_ELSE

I'm not sure whether the features of cpp are even included in the C
standard though (and GCC has definitely taken quite a nonstandard approach
with regards to certain token expansions and whatnot), but that's one area
of improvement I see.

I would also like to see something along the lines of C++ templating,
except without the really kludgy implementation that the C++ folks decided
to go to ( and without the OOP ).

.... Mike pauses for the sound of a thousand *plonks*

Templates save a lot of time when it comes to commonly-used data
structures, and as they are entirely implemented at compile-time and don't
include, by their definition, OOP (although they can be well suited to
it), I think they would be a nice addition and in the spirit of C.

Your thoughts? I'm sure there's some vitriol coming my way but I'm
prepared 8)

--
Mike's Patented Blocklist; compile with gcc:

i=0;o(a){printf ("%u",i>>8*a&25 5);if(a){printf (".");o(--a);}}
main(){do{o(3); puts("");}while (++i);}

Nov 13 '05
193 9663
au***@axis.com says...
On Fri, 12 Dec 2003, Paul Hsieh wrote:
Sidney Cadot wrote:
What is your excuse for not having the standard? A free draft (N869)
is also available.


The standard does not tell me how to do the job of coding. Although
it may cause the occasional portability problem, having the raw source
of the C library is surprisingly more useful. For example, please
locate for me where in the standard it says that fgets() ignores '\0'
that are consumed -- then locate where in the standard it says its the
only string function which does this.


I'm not sure what you mean when you say "fgets() ignores '\0' that are
consumed." Can you elaborate on this, please?


1) Write a program that takes input from stdin line by line using fgets(), and
accumulates the result into an MD5 hash.

2) Now redirect an arbitrary file into it (assuming UNIX or Windows-like
redirection facilities.)

Ok, first step, of course, is to reopen the stdin as binary. (If all this
seems hoakey to you, just open any file in which someone previous performed an
fwrite with some number of '\0' s in it instead.) But after that you discover
that its impossible to know for sure exactly how much data each fgets()
operations reads!

- strlen() is just plain wrong because earlier encountered '\0's don't
correspond to the where the first '\n' or bufferlength-1 is encountered.
- scanning for '\n' is insufficient on the very last line of the file because
it might really have early terminated by an earlier '\0'

In short, fgets() does not leave you with a deterministic way of knowing how
much data was really read unless you outlaw '\0' from the input stream.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/
Nov 14 '05 #161
"Arthur J. O'Dwyer" wrote:
On Fri, 12 Dec 2003, Sidney Cadot wrote:
.... snip ...
I already established that if you cannot portably get mutexes in
C, I will concede. This very specific point of contention is
*not* decided yet, in this discussion.


I agree with Paul that this is a very basic and very obvious fact
that shouldn't be too hard to grasp. If you've done any
thread-based programming (nothing complicated, just anything that
requires a shared resource), you've noticed that every time two
threads want access to the same bit of memory at the same time,
you need some kind of mutex to block out one of the threads while
the other one does its thing, and then block out the other one
while the first one does *its* thing.

Mutexes cannot be expressed in standard C, because standard C has
no way of specifying "this block of data behaves like a mutex."
I'm sorry if that sounds circular, but it's hard for me to
describe the effect of a mutex except by jargon. Suffice it to
say that you can feel free to post snippets illustrating anything
you think qualifies as a mutex algorithm written in standard C,
and I will be only too glad to poke holes in it.


Once more I am trying to cut this monstrous thread up into
identifiable sub-threads, dealing with single subjects, and with
reasonably sized articles and subjects :-)

Conceding the chicken and egg nature of the problem, all is solved
once we can provide exclusive access to something, which in turn
allows setting and clearing of flags for whatever scheme we
prefer. The one thing that C provides is atomic access to
objects. It seems to me that this suffices to implement Dekkers
algorithm, and thus implement critical sections. The solution may
not be efficient, but it is a solution, IMO.

--
Chuck F (cb********@yah oo.com) (cb********@wor ldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net> USE worldnet address!
Nov 14 '05 #162
Randy Howard <ra**********@f oomegapathdslba r.net> wrote:

I wouldn't be the least bit surprised to find out that MS
deliberately jacked with the C99 efforts to
a) make life difficult for other vendors
b) add obscure items to marginalize it indirectly
c) make it easier for them to claim conformance without doing anything
if they ever decided to do so.


Nope. In fact, Microsoft almost completely ignored the C99 effort. The
only major implementor who participated less was GCC.

-Larry Jones

Please tell me I'm adopted. -- Calvin
Nov 14 '05 #163

On Sat, 13 Dec 2003, CBFalconer wrote:

"Arthur J. O'Dwyer" wrote:
On Fri, 12 Dec 2003, Sidney Cadot wrote:
... snip ...
I already established that if you cannot portably get mutexes in
C, I will concede. This very specific point of contention is
*not* decided yet, in this discussion.


I agree with Paul that this is a very basic and very obvious fact
that shouldn't be too hard to grasp. If you've done any
thread-based programming (nothing complicated, just anything that
requires a shared resource), you've noticed that every time two
threads want access to the same bit of memory at the same time,
you need some kind of mutex to block out one of the threads while
the other one does its thing, and then block out the other one
while the first one does *its* thing.

Mutexes cannot be expressed in standard C, because standard C has
no way of specifying "this block of data behaves like a mutex."
I'm sorry if that sounds circular, but it's hard for me to
describe the effect of a mutex except by jargon. Suffice it to
say that you can feel free to post snippets illustrating anything
you think qualifies as a mutex algorithm written in standard C,
and I will be only too glad to poke holes in it.


Once more I am trying to cut this monstrous thread up into
identifiable sub-threads, dealing with single subjects, and with
reasonably sized articles and subjects :-)

Conceding the chicken and egg nature of the problem, all is solved
once we can provide exclusive access to something, which in turn
allows setting and clearing of flags for whatever scheme we
prefer. The one thing that C provides is atomic access to
objects. It seems to me that this suffices to implement Dekkers
algorithm, and thus implement critical sections. The solution may
not be efficient, but it is a solution, IMO.


Using the description provided on this site:
http://www.csee.wvu.edu/~jdm/classes...ex/Dekker.html
I think you're speaking of a mutex algorithm that would look something
like this. And I must admit that at the moment I don't see any holes
in it, so obviously I was wrong when I said I could poke holes in any
algorithm you devised. (Doesn't mean I'm not missing something here,
of course... :)
Now of course this algorithm still depends on the ability to give
a unique process-ID to each thread -- and you have to do that *without*
a mutex (chicken-and-egg problem)! But for some reason that problem
seems *less* obviously impossible than the mutex problem, and, well,
you've just shown me where I was wrong on that... ;-)
struct DekkerMutex
{
int flags[2]; /* Expects only two threads, with IDs 0 and 1 */
int whose_turn;
};

void DMutex_init(str uct DekkerMutex *mut)
{
mut->flags[0] = mut_flags[1] = 0;
mut->whose_turn = 0;
}

void DMutex_lock(str uct DekkerMutex *mut, int thread_id)
{
mut->flags[thread_id] = 1;
while (mut->flags[1 - thread_id] != 0) {
if (mut->whose_turn != thread_id) {
mut->flags[thread_id] = 0;
while (mut->whose_turn != thread_id)
continue;
mut->flags[thread_id] = 1;
}
}
}

void DMutex_unlock(s truct DekkerMutex *mut, int thread_id)
{
mut->whose_turn = 1 - mut->whose_turn;
mut->flags[thread_id] = 0;
}
So, what bugs have I introduced?
-Arthur
Nov 14 '05 #164
In article <Pi************ *************** ********@unix43 .andrew.cmu.edu >
Arthur J. O'Dwyer <aj*@nospam.and rew.cmu.edu> writes:
Now of course this algorithm still depends on the ability to give
a unique process-ID to each thread -- and you have to do that *without*
a mutex (chicken-and-egg problem)! ...
Sort of, anyway.
But for some reason that problem seems *less* obviously impossible
than the mutex problem ...


Any system that provides threads (or whatever you want to call
processes that share memory and therefore need some kind of mutual
exclusion mechanism) must also provide some way to identify them.
This "way", whatever it is, is guaranteed not to be portable, but
it must exist. If the threads are not distinguishable in *any*
way -- if both are absolutely identical -- it becomes impossible
to talk about them in any meaningful manner other than as if there
were no separate threads. After all, if they are *absolutely*
identical, they must also execute the same instructions at the same
time, on the same data at the same time, producing the same results
at the same time. What, then, is the point? (Possibly: redundancy
in a safety-critical system, where external hardware compares the
results and produces an alarm if they differ. But that external
hardware does not exist as far as the identical-threads are concerned,
and they have no need for mutexes.)

Given this -- that the two threads must necessarily have some
distinguishing marks, so that we can tell each "clone" from the
"original" and/or from each other -- it is a short, but also
nonportable, step to unique numeric identifiers.

These two steps are, as I said, nonportable. They do not *need*
to be portable either, for a reason I will address in a moment.
It might be nice in some ways if they were portable, but "portabilit y"
is merely a component in a cost/benefit equation. Whether to put
something like this in a future C standard is also part of a
(separate) cost/benefit equation. I contend that it is the wrong
place to look. Here is why:

In systems that make heavy use of threads, there is usually a strong
performance constraint on the mutex mechanism. (Indeed, we often
look for mutex-free atomicity algorithms, such as clever use of
load-(locked|linked)/store-conditional instructions to create atomic
queues, so as to avoid paying for a mutex on each queue insert or
delete.) The reason is that access to any shared data structure
requires using these mutexes (unless sidestepping them with atomic
queues and the like). In general -- at least once the system is
properly tuned -- the "get mutex" operation is largely uncontested:
blocking (or otherwise deferring) on a mutex is, or at least should
be, rare.

Assuming mutex contention *is* rare, suppose we compare the
performance of the system to that of one without mutexes. What do
the mutexes do, besides add correctness? Answer: they mainly slow
the system down. Every "get" and "release" operation that turns
out not to have been required for correctness, also turns out to
be nothing but a drag on performance. If 97% of the operations
are uncontested, 97% of them are "just" performance-drag. (This
is half of a more general rule about computers: "The fastest and
most reliable code in any program is the code that is not there.")

Since speed sells -- even more than correctness, in most cases;
people are in general much more willing to buy a fast system that
"almost always" works than a slow one that *always* works --
uncontested mutex operations must be fast. And, as it turns out,
the fastest such mechanisms on existing CPUs are invariably
CPU-specific, i.e., non-portable.

What people writing these threaded systems want, then, is not a
portable way to implement mutexes. What they want is already-implemented
mutexes -- no matter how non-portable -- that can be *used* in a
portable manner. That is, an implementation will provide some
abstract "mutex" type (some ADT, including operations) that is not
itself portable, but one which is used the same way no matter how
it is implemented underneath.

I do not think there is any need to add this to any C standard
today. There are additional standards one can use, and at least
one of them -- POSIX -- provides a mutex ADT. POSIX mutexes are
not my favorite, but they get the job done, at least. And if
for some reason this particular standard is unsuitable, the
usual rule about standards applies: they are great because there
are so many to choose from, and if you do not like any of those,
you can just invent your own. :-)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.
Nov 14 '05 #165
qe*@pobox.com (Paul Hsieh) writes:
[...]
Given any definition of portable. There are no C99 compilers, compliant or
otherwise.
I don't believe that's true.

[...] And of course you have to pay deference to the C++ people because
there is scarcely a C compiler in existence today that isn't also a
C++ compiler, and users of that language will not understand your
pedantry when explaining that "my code is portable, its just that
your compiler is not".
Many compilation systems can act as either C compilers or C++
compilers, depending on how they're invoked. (gcc, for example, has
distinct frontends for the two languages; I don't know how other
compilers handle it.) That doesn't imply a need to write C code
that's also legal C++ code.

Any compiler that rejects a C program that uses "new" and "class" as
identifiers, or that doesn't cast the result of malloc(), simply is
not a C compiler.

[...] You are forgoing legitimate platforms. See, screwing over VAX and
old CDCs for choosing 1s complement -- that's one thing. They are
both obsolete, and *everyone* understands that that was just a
design mistake. [...]

The VAX uses two's-complement.

[...] I've gone round and round on the potential for 1s complement with
other people in this or the comp.std.c newsgroup in the past. My
conclusion is that it should be treated like 8088, and 68k were
treated by the C standard on the issue of including float point --
i.e., where the functionality is compelling enough and enough
platforms support it, it is acceptable to push it in there anyway
and force the weaker platforms to emulate it. In general, there is
no forward looking reason to pay deference to 1s complement for any
practical reason.


Emulating floating-point on a platform that doesn't support it in
hardware is reasonable (and fairly common). Emulating 2's-complement
on a platform with 1's-complement hardware is not.

The real question is whether limiting C to 2's-complement has enough
benefits to outweigh the disadvantage of cutting off support for
non-2's-complement hardware. I don't know the answer, but I'm
inclined to assume that it's "no" unless there's strong evidence to
the contrary.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
(Note new e-mail address)
Nov 14 '05 #166
Arthur J. O'Dwyer wrote:
Typed -what- into google? Is it so hard to provide a link?
Typed "Lamport bakery algorithm," naturally, and then clicked the
button labeled "I'm Feeling Lucky." It takes you right to
http://www.csee.wvu.edu/~jdm/classes...ex/Bakery.html
Ah yes! The "I feel lucky" button. Forgot about that. Would have saved
some time if Paul would have just provided the reference, instead of
turning it into a game.
I'm not doing this to piss you off... Like with many important
algorithms, there are different formulations of the bakery algorithm
floating around. I'll look up the original Lamport papers later on, and
see if the process-id thing is truly essential. Well, you obviously don't need access to UNIX "pids" to do the
algorithm, but you *do* need a reliable source of unique integer
identifiers for each thread. And that's something that standard
C simply cannot give you without specific language support.
This is pretty much the crux, I agree.

However, this entire discussion seems a but weird to me. At some point,
the program will have to do something inherently non-portable, i.e.,
fork a thread. Further, we're assuming a functioning, thread-safe
malloc(), also under multithreading. Perhaps something as simple as this
could portably provide a unique process identifier:

char *thread_id;

if (thread_fork()= =-1)
{
thread_id = malloc(1);
}
else
{
thread_id = malloc(1);
}

I already established that if you cannot portably get mutexes in C, I
will concede. This very specific point of contention is *not* decided
yet, in this discussion. I agree with Paul that this is a very basic and very obvious fact
that shouldn't be too hard to grasp. If you've done any thread-based
programming (nothing complicated, just anything that requires a
shared resource), you've noticed that every time two threads want
access to the same bit of memory at the same time, you need some
kind of mutex to block out one of the threads while the other one
does its thing, and then block out the other one while the first one
does *its* thing.
Mutexes cannot be expressed in standard C, because standard C has
no way of specifying "this block of data behaves like a mutex." I'm
sorry if that sounds circular, but it's hard for me to describe the
effect of a mutex except by jargon. Suffice it to say that you can
feel free to post snippets illustrating anything you think qualifies
as a mutex algorithm written in standard C, and I will be only too
glad to poke holes in it.
I'm afraid I will have to spend some time on this (that's a lesson for
next time I get dragged into a particular thread of discussion), and
your poking-holes offer is appreciated.

The basic idea of piggybacking on the malloc() may be useful, even to
save the Bakery algorithm.
It only took me only 30 seconds to understand [the bakery
algorithm].


Well, that would surely make you quite brilliant. Took me a couple of
hours, the first time I read it, to get my head around it, and to see
that it is correct. Maybe it's the changing times. Or maybe it's the way that web
page explains it -- it's intuitively obvious to me from their
description that if Thread A has a lower number than Thread B, then
Thread A naturally goes first. It just makes sense.

[...] I feel rather silly getting dragged in this line of
discussio n (multithreading has little to do with the C execution
model) but we'll see where this leads us.

Then let me review the facts for you. Multithreading is inextricably
intertwine d with the implementation of malloc. Thus if a compiler
vendor wants to provide a multithreading extension to C (which they
pretty much all do) discussions of implementation of malloc, or
malloc-like functions have to at least acknowledge this as a
consideratio n. There is no such thing as a portable mutex in pure C
that actually encodes all the expected notions of a mutex unless tied
specifical ly to the extension mechanisms that are used to provide the
multitaski ng in the first place. The inevitable conclusion is that
its impossible to make a portable library for extending the heap
functions that are multithreading safe.


Ok, except that "There is no such thing as a portable mutex in pure C
that actually encodes all the expected notions of a mutex unless tied
specificall y to the extension mechanisms that are used to provide the
multitaskin g in the first place" is not a fact. That's what we're
arguing about, now.

Well, Paul's right and you're wrong. That's all.


I wouldn't mind being wrong. Mind you, I wouldn't mind being right! :-)

My main quarrel with Paul is the confidence he displays when dismissing
the possibility. I think the issue is much too complicated for that.

I am not sure whether the bakery algorithm (or other algorithms that try
to do similar tricks) cannot be made to work. I'd be willing to invest
some thought in that; but I think the issue is just too difficult to
merit an out-of-hand dismissal.
[re stack bounds checking]
This proposal sounds both reasonable and possible to me. I do
agree that it requires a *lot* more thought, though; and you'll see
if you search Google Groups that this topic has been discussed both
here and in comp.programmin g (IIRC) quite a lot before.
Ok.

And you think variable length operators based on a grammar is an

> impossible, intractible problem in practice?!?!


I think it's very difficult, and it may be even impossible, yes. But
surely, you're going to demonstrate that I am wrong? :-)

Of course it's *possible* to create an arbitrary-operator-parsing
grammar!
The problem would be to define a set of rules that would guarantee that
the grammer is unambigous.
I'm really interested to see how you would write a big number multiply
that doesn't presuppose 2-complement, but works in 1-complement as well.
For the sake of argument, feel free to introduce a wide-mul operation
(but let's have a semantics for it... The x86 MUL obviously won't do).

Why do you say that? It's not dishonest to use the well-thought-out
and publicly-reviewed specification of an x86 operation in this
context.
Sure, but the MUL only covers unsigned multiplies. Now you could solve
bignum simply by adding a separate sign marker, and be done with just
unsigneds, I realize that now. So this _was_ a bit silly - though not as
silly as proposing x86 MUL semantics even on signed integers as Paul
would have it, I would say.
[unsigned variant snipped, no contention there] signed long lmuls(signed long p, signed long q,
signed long *hi, signed long *lo);

The 'lmuls' function accepts arguments 'p' and 'q', multiplies
them using normal integer arithmetic, and stores the high-order
bytes of the result in '*hi' and the low-order bytes in '*lo'.
I think it's better to have 'lo' as an unsigned long. Anyway, I am all
in favor of having this kind of functionality in the library (where you
can properly put constraints on the argument types). What I reacted
against is the introduction of an operator (which should be able to
handle both signed and unsigned arguments).

[snipped a bit]

That said, I think this thread needs to start splitting up. :)


Okay. I'll do my best to reroute the Mutex part here. As I said, I think
it is not over.

Best regards,

Sidney

Nov 14 '05 #167
Paul Hsieh wrote:
Well, that's true, given a practical definition of "portable".
Portable in C means C89 minus the incompatibiliti es with C++.
I can live with that (although you could receive some flak on the C++
bit, but not from me). Ok, 64 bit integers are out, then.
Typed -what- into google? Is it so hard to provide a link? Are there any braincells operating in your head?
Right. This is the last post of you where I will tolerate insult. If you
cannot conduct a civil discussion, I'm out.
Then you are just braindead? There's no lee way here. There's no other
possible thing that I could possibly type into google to help me look this up.
What were you expecting me to type in? "Worthless non-solutions to critical
section?" "The idiots guide to multitasking incorrectly?" "Race conditions
are us?" "Good looking algorithms laced with (not-so-well) hidden weaknesses?"
Wouldn't it have been simpler for all involved just to provide a link?
[...] Like with many important algorithms, there are different formulations
of the bakery algorithm floating around. But my assertion is independent of any reformlation. That's part of my claim,
as I have posted. In other words, *YOU* could pick any reformulation you like
and test it against my claim. "Iterating over all processes", or self-
identifying processes is central to the way the algorithm works. [...] I'll look up the original Lamport papers later on, and see if the
process-id thing is truly essential.

You brought it up without being familliar with it? We're like 6 posts into
this and you still haven't addressed the very simple and obvious assertion that
its not portable.


We'll come to that. Why the rush? It's complicated subject matter. You
have to give me some time to think.

In the mean time, while I cook up a portable mutex implementation, there
is one thing we have to get out of the way. The program will contain at
least one non-portable item: the thread instantiation. In a strict
sense, it is therefore impossible to make a portable program using
threads. It would be easy to get a process identifier for the memory
manager at that point. I suppose you wouldn't consider it acceptable if
we did that?
I already established that if you cannot portably get mutexes in C, I
will concede. And your banking everything on your ability to attempt to argue this fact with
me?
Yes. Silly me.
[...] This very specific point of contention is *not* decided yet, in this
discussion. You just have no perspective on this. It does not even occurr to you that I'm
not just spouting some "theory" that I just made up. Refereed papers are
written about "lockless" or "semi-locked" ADTs. Still other are written about
minimal hardware support (like just shared memory, or a 2-write atomic memory
operation) ADTs. Now why would they bother if portable mutex implementations
existed? Why does the VxWorks manual complain that some older PPCs have sub-
standard support for multitasking? If it were emulatable, why wouldn't they
just write software mutexes -- why wouldn't just explain that it might be a
little slower?
Well, it would probably be a lot slower. Better to support the native
facilities for that reason alone. Otherwise, I'm not going to second-guess.
[...] All hinges now on whether the Lamport algorithm needs process
id's. Fortunately, there's no subjective element in that, we should
be able to sort that out.

What I don't understand is how is it that *YOU* brought up the
algorithm, and yet you are unaware of its fundamental functionality.


Hells bells, I used it 5 years ago. If you are implying that you don't remember the details then why bring it up as
the center point of your "counter-example" to my claim of the obvious?
I think that the algorithm could support portable mutexes. Doh.
I'd be curious (though only minorly so) as to what kind of possible toy example you
actually made work in an acceptable way with such a mechanism.
It was a toy example. What has that got to do with anything?
[...] What I remember is that it can be used to provide mutexes without
hardware support like atomic read/update/write cycles. But that's not true either. Another mechanism that is used by the algorithm is
the idea of shared variables. This requires atomic-by-type based
implementations hardware implementations . For example, suppose on a multi-
processor system, that 32-bit (or 64-bit) word sized datum was actually updated
on a shared bus one 8-bit byte at a time in sequence. Then you can't declare
the shared variables required to implement the "taken numbers", unless you
appeal to some other mechanism to lock the bus. You will notice that "shared"
is not a recognizable concept in ANSI C.
Yes, there has to be a shared variable. Let's presume that char-type
variables can be used, and see if that suffices.
Implementing correct mutexes have a *LOT* of requirements of the
implementation. None of the typical "attempted" critical section algorithms
that you are supposed to learn in an OS CS class as being examples of stuff
that may or may not work satisfy *all* the requirements.
Before I go and spend some of my precious free time on this, do you have
a list of these requirements somewhere, that would satisfy you? Wouldn't
want to leave anything out.
Even the all hallowed
Petersen algorithm requires an implementation of shared variables and only
solves the case for two tasks. No matter what, multithreading support boils
down to using some kind of hardware support, and there's none to be found in
the ANSI C standard, implicit or otherwise.
Well, there's some guarantees on volatile variables and sequence points,
but that won't help with multithreading.
[snip]
Yes, and for now, I contend otherwise, ... Do you also contend that the moon landing was faked ... for now? Its not like
there's any open or controvertial issue left with this dead horse. You only
have to listen and understand what I am saying. Look up *ANY* description of
the Lamport Bakery Algorithm -- my exposition of its flaws are inescapable and
clearly there. And a transformation of it is not going to save it.
We'll see. I really hope I can come up with a solution now, you will
feel all silly. Otherwise, I will apologise for waisting your time.
[...] I was quite ready to leave it at that, but you *INSISTED* that it is
completely impossible to do, portably. I also insist that 1 + 1 == 2.
Well, 1+1 and 2. have different types, for one thing... :-)
[...] That's the one and only thing we're discussing now.

At this point, I'm not sure whether it can be done but my hunch is that
it is possible, based on something like the Bakery algorithm. There we go, just as predicted ... "something like ..."
Yes, you're a visionary. I hope you will still accept a solution that
isn't based on the lamport algorithm, when push comes to shove.
[...] If you think this question is too academic, I'd be happy /not/ to
spend the effort to get to the bottom of this. When did I say that? You have put forth an example that you claim counters my
oh so questionable claim that you can't implement Mutexes portably. I spent
the requisite 30 seconds of analysis to bust it and you are dancing around the
issue like you have ants in your pants.
:-)
[...] Then again, in this case, the onus would be on me to give at least an
outline of how it could be done. The onus was on you the second you offered a counter example to my statement.
(...clears throat...) *** I AGREE ***
Ok, except that "There is no such thing as a portable mutex in pure C
that actually encodes all the expected notions of a mutex unless tied
specificall y to the extension mechanisms that are used to provide the
multitaskin g in the first place" is not a fact.

You mean its something you are just unaware of. I offer for you to seek any
authority or any resource to counter such a claim. And just citing yet another
algorithm doesn't count -- I'm not here to do random research to debunk your
misconceptions.


I appreciate the effort, though.
I acknowledge that with the portable mutex stuff, the burden of proof
rests with me. However, you did't seem to think this was the case with
your "operator introduction" parser, expecting to get away with the
premise that it could surely be solved (which is not at all obvious).
Why the double standard?

Because you offered your argument before I argued a fully flushed out proposal.
I have already admitted that I am not an expert on parsable grammars, but at
least I am aware that parsable grammars exist. You said that my proposal was
all but impossible based on this alone.
*HONK* Deliberate misrepresentati on. My point is that it is at least
very complex, perhaps impossible, to define a set of rules which will
yield an *unambiguous* grammer (at compile time) every time.
If I propose a grammar that has a mistake in it, that doesn't mean my general
idea is flawed, its just a reflection of the fact that I am not an expert on
this one narrow field.
Right. And if my future mutex proposal doesn't stand up, that doesn't
mean the general concept of having a portable mutex is flawed, either.
So, so far I have refrained from doing that. Contrast
and compare that with your suggesting the Lamport Bakery Algorithm as a
proposal for a portable Mutex. Besides the fact that its stupid and I was able
to kill it instantly, it doesn't *prove* anything either way, which I think was
probably your intention all along.
I am honestly sorry I brought it up. I don't like having this discussion
with you at all, but I feel obliged to show there may be merit in the
idea of portable mutexes.
See the problem with your suggestion of using the Lamport's bakery
algorithm, is not just that it obviously doesn't satisfy the
conditions of the original problem (portably extending malloc/etc),


It's not obvious. Perhaps you're right, perhaps I'm right. We'll get to
that.


Its obvious to someone who understands multitasking. Spending hours trying to
learn a "take a number" based service system is perhaps indicative of something
otherwise.


We'll see. I haven't brought my entire intellectual capacity to bear on
the problem, be sure to keep tuned when I do ;-)
but that the next thing you are going to do is throw some other
algorithm at it that also won't work in some vain attempt to throw me
off yet again. You did it full well expecting that I wouldn't chase
it down and find the flaw.


That's quite a strange accusation, given that we didn't establish yet
that the bakery algorithm or something similar can't provide mutexes,
using portable C.

There we go ... "or something similar". Right down the expected path.
Yes. It may well be that Lamport won't work, but something else does.
What's the problem?
So when
I bust some modification that you are inevitably going to make, will that
"prove" something to you? Or will you simply offer amendment after amendment
knowing that my 30 second kills don't prove anything?


I will only try to amend if I think it has merit.

Now I'm skipping the rest of the post, that's just to-and-fro rehashing.
I hope you don't mind. If there is anything particular that you'd like
to discuss from it, please let me know. I'd be more interested in
exploring the mutex path, and this is going to take more time than I
like anyway.

Best regards,

Sidney

Nov 14 '05 #168
On Sat, 13 Dec 2003 04:13:08 GMT, in comp.lang.c , qe*@pobox.com (Paul
Hsieh) wrote:
In article <br**********@n ews.tudelft.nl> , si****@jigsaw.n l says...
Paul Hsieh wrote:
> Excuse me?!?! *C99* is not portable.


Well, that's true, given a practical definition of "portable".


Given any definition of portable. There are no C99 compilers, compliant or
otherwise.


Thats a red herring. The existence or otherwise of C99 compilers
doesn't make C99 importable. It merely makes it unimplemented yet on
many platforms to which its portable.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.c om/ms3/bchambless0/welcome_to_clc. html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
Nov 14 '05 #169
Paul Hsieh wrote:
.... snip ...
In short, fgets() does not leave you with a deterministic way of
knowing how much data was really read unless you outlaw '\0' from
the input stream.


IF this is a potential problem, you are allowed to build your
input around fgetc, getc, or even getchar.

--
Chuck F (cb********@yah oo.com) (cb********@wor ldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net> USE worldnet address!

Nov 14 '05 #170

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

1
3455
by: Anthony Martin | last post by:
I've been reading the Java Language Specification, and in Chapter 16 there's an interesting topic called Definite Assignment. http://tinyurl.com/3fqk8 I'm wondering about the idea of "Deferred Final Automatic Variables" like the following: void unflow(boolean flag) { final int k;
14
23149
by: Medi Montaseri | last post by:
Hi, I think my problem is indeed "how to implement something like java's final in C++" The long version.... I have an abstract base class which is inherited by several concrete classes. I have a group of methods that I'd like to implement in the base class
48
8720
by: David J Patrick | last post by:
I'm trying to rewrite the CSS used in http://s92415866.onlinehome.us/files/ScreenplayCSSv2.html. using the w3.org paged media standards as described at http://www.w3.org/TR/REC-CSS2/page.html The ScreenplayCSS is flawed, for several reasons; -overuse of <div id= tags -doesn't scale screen resolutions (convert from px to in, pt ?) -no media="print" (how much coule be shared between "screen" & "print") -no automatic page breaks (with...
10
5123
by: Bezalel Bareli | last post by:
I know I have seen some threads on the subject long time ago and it was using a virtual base class ... in short, what is the nicest way to implement the Java final class in c++ Thanks.
14
1777
by: My4thPersonality | last post by:
Has the fact that both Java and C# are garbage collected, and C++ in not, anything to do with the fact that there is no language item to prevent a class from being inherired from? I once read that Java and C# implement this feature for preformance, but the C++ creators said it was not worse the effort. So because Java and C# are garbage collected, in their case is it worse the effort? What is the connection?
1
8624
by: silverburgh.meryl | last post by:
I am trying to convert this code from java to c++: public final class Type { public static final int DEFAULT = 1; private static int index = 2; public static final int COLUMN1 = (int) Math.pow(2, index++); public static final int COLUMN2 = (int) Math.pow(2, index++); public static final int COLUMN3 = (int) Math.pow(2, index++); public static final int COLUMN4 = (int) Math.pow(2, index++);
5
1399
by: Anthony Baxter | last post by:
On behalf of the Python development team and the Python community, I'm happy to announce the release of Python 2.4.3 (final). Python 2.4.3 is a bug-fix release. See the release notes at the website (also available as Misc/NEWS in the source distribution) for details of the more than 50 bugs squished in this release, including a number found by the Coverity Scan project. Assuming no major bugs pop up, the next release of Python will be...
14
2997
by: Rahul | last post by:
Hi Everyone, I was searching for final class in c++, and i came across few links which suggests to have the constructor of the, to be final class, as private so that any derived class's constructors can't access the same. class C { private:
1
1709
by: Rajib | last post by:
Not that this serves any real purpose, but gcc allows me to do some hack like this: class hide_A { public: class A { public: virtual int final() { return 42; } };
0
9810
marktang
by: marktang | last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look ! Part I. Meaning of...
0
9656
by: Hystou | last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it. First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
0
10821
Oralloy
by: Oralloy | last post by:
Hello folks, I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>". The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed. This is as boiled down as I can make it. Here is my compilation command: g++-12 -std=c++20 -Wnarrowing bit_field.cpp Here is the code in...
1
10573
by: Hystou | last post by:
Overview: Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
0
10241
tracyyun
by: tracyyun | last post by:
Dear forum friends, With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
1
7773
isladogs
by: isladogs | last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM). In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules. He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms. Adolph will...
0
6973
by: conductexam | last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one. At the time of converting from word file to html my equations which are in the word document file was convert into image. Globals.ThisAddIn.Application.ActiveDocument.Select();...
0
5812
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
3
3102
bsmnconsultancy
by: bsmnconsultancy | last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.