473,854 Members | 1,830 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 9685
Sidney Cadot wrote:
Paul Hsieh wrote:
Its a big deal to me. I don't own any material on the C language
that specifies all of this.

The C standard specifies what is UB and what's not. Grepping an
implementatio n is a fragile way of dedicing semantics, I would say.
Yes, and what percentage of C programmers in the world do you think have ever
had the standard in their hands that they actually refer to?


I think there are relatively few excuses for any professional C
programmer not to have access to the standard (and reading it once or
twice wouldn't hurt either). It's only 18 bucks in electronic form,
and you don't even have to go out to get it.


Care to take a quick survey of comp.lang.c patrons who own their own copy of
the standard?
My objection to your proposal can simply be restated as "all
machines have limited resources", deal with it.


Then the standard would have to specify what it means exactly by a
"resource". Standards are no places for vague terminology.


You mean vague terminologies like "stack"?
[...] If the thing needs to be able to run in
a multithreaded environment, you could even do that, with some
extra effort. You need some form of mutex locking, but you can
resort to Lamport's bakery algorithm for that.


I had to look this one up -- that's one of the classic useless
non-solutions (especially if you want to call malloc more than 4
billion times, for example), which explains why I've never
committed it to memory.


We have long longs nowadays. 2^32 is not an important limit.


And long long's are portable?!?! Are you even following your own
train of thought?
You still need to be able to identify process instances, which *BY
ITSELF* is not portable. Process instances identifiers would
count as something *BEYOND* just malloc/free/etc.


Why do you need to distinguish process instances?


Reread the Lamport's bakery algorithm. One of the crucial steps is
"for each process, check their number, and pick the max, then add 1".
Another is "for each process that has a lower number, wait in line
behind them." This means you have a way of knowing how many processes
there are, and how to index them. This means you have to hook out or
wrap whatever "spawn" mechanism you have in your language (or use some
other platform specific mechanism to iterate through all running
threads.)
[...] In your API, each call carries the heap it refers to as a
parameter.
Yes, but if two threads simultaneously call heap functions on the same
heap (heaps are not restricted to being distinct across threads) then
there is a race condition.
I would say that writing a more powerful heap manager is possible in
principle, even in a multithreaded environment, as long as you have a
well-implemented malloc() (and friends) at your disposal.


*BZZZT!!!* Wrong.
It would be a drag to do so and it would be slow, but it is possible.


Impossible. Slow, fast or otherwise. Its just impossible.


If you can explain to me why you need to explicitly distinguish threads
in the memory manager, I'll concede the point.


Go look up the source code for *ANY* multithreading supporting
malloc/free. I absolutely guarantee that every single one of them
uses some kind of platform specific exclusion object to make sure that
two simultaneous calls to the heap do not collide.

One way or another the heap is some kind of quasi-linked list of memory
entries. You should have learned from your OS classes (assuming you passed it
and/or comprehended the material) that all ADTs, including linked-lists have to
be protected by some sort of critical section like mechanism if more than one
thread has access to it. If you do not understand this, then you don't
understand multithreading.
So far, nobody has challenged me to come up with a specific phrasing for
this (which actually surprises me). Here you go. It's a bit rough, but
you get the idea.

---- Proposed addition to the standard to add stack overflows:
---- Draft

a. For an active function invocation, define an upper bound for the
amount of memory in use by this function as follows (in the
following, denote "Upper Limit on Memory Usage" by "ULMU"):


And what if the local/parameters are not stored, or storable on the stack?


How do you mean? They have to be stored. And I'm presuming they're
stored on the stack.


Most microprocessors have these temporary storage elements called
"registers" . They are often not part of any stack structure. Many modern
compilers will map local variables and temporaries to these "registers" , thus
not requiring stack storage for them.
What if an implementation uses multiple stacks depending on the
*type* of the parameter?


The hypothetical implementation [...]


That the ANSI C standard currently does not have any problem with ...
[...] that does this will be out of luck. Not because the proposal
wouldn't work, mind you, but because the ULMU is a very loose bound.
But hey, it beats having no bound whatsoever.
No it doesn't. Dealing with the stack is an area that clearly should be
platform specific. For example, it could be that an embedded system has
fast and slow ram. Certain data types might be best suited to being mapped
into fast RAM, whether they are local or not, but you might have a lot more
slow RAM, so you'd put all the rest of the stuff in there.
- For every parameter/local variable of basic type there is a
corresponding constant macro of type size_t:


You missed all the implicit temporaries required. Homework
exercise: for any fixed number n, create a function which requires
at least n implicit temporaries (not explicitely declared) to
implement.


Ah yes! So it seems. An interesting problem. Have to think about that
for a bit.


Why don't you think about the implication of the results of this
exercise with respect to your proposal while you are at it.
And what about the number of alloca() calls? alloca() is a common
extension which just eats extra space off the stack dynamically --
the big advantage being that you don't have to call free or
anything like it, for it to be properly cleaned up. It will be
cleaned up upon the function's return (the simplest implementation
of a "freeall".)


Ok, we can add alloca'ed space is each function invocation, plus an
overhead constant per active alloca.


The alloca() calls can be in a loop. Knowing how much memory a set of
alloca's will perform in any function is equivalent to solving the
halting problem.
Unless you allow that I'm trying to define an upper bound of total use,
which may be loose as far as I am concerned. The idiomatic use would be
to compare this to the ULMU_TOTAL to see if it fits. This may yield the
number of bytes on the smallest check for all I care. On those silly
platforms, you will grossly underestimate stack capacity now and then.
[...] Still beats the current situation.
This versus just living with runtime stack checking? I'll take the
runtime stack checking.
When reading the code that used (rather than defines) the operator, it
helps tremendously if the meaning jumps from the page, rather than
having to look it up in the Big Manual of Operators in use at your local
workplace.


You are completely ignoring that large population of people who
happily use operator overloading today. You don't understand that
what you are saying is nothing more than your very narrow opinion.
And you're using your opinion to try to trump a proposal whose
merits lean very heavily on its technical features.


My opionion is determined largely by the psychological objections (to
which you don't subscribe.)


Says who? You see, unlike some people, by idea isn't driven by an
opinion. Its driven by a consideration for design. Since you *CAN'T*
add just any old operator to satisfy everyone, then how do you satisfy
the demand for more operators? Some variation on edefinable
operators or operator overloading is the logical conclusion -- just
fix its problems (since type-index functions don't really exist in C,
so you just add in a bunch of them so that you don't lose any of the
ones you have). For all I know, I might not ever use such a feature,
even if it *WERE* to be endorsed by the standard.
My technical problem is that I can see no way that this could be
implemented.
Well I don't know what to make of this -- you can't see a race
condition when its staring you in the face, and you can't imagine
problems with knowing the size of a function's stack usage.
A small hypothetical case study. Suppose engineer A, working on
nuclear reactor core controllers, works in a team where "?<"
means "minimum" and "#<" means "x is implied by y" for some data
structure involved in logic reasoning on the state of the
system. Now he switches companies; he goes to work on electronic
toys and gadgets. Here the convention is different, but the same
operators are used.


The example you've made up has to do with basic comprehension of
the engineer -- since "?<" would clearly be one of the "extended
operators", the programmer is supposed to look up the its
definition. Just like they would have to look up logMsg() or any
other function name that might show up in more than one project.
Just like they are supposed to magically know how clock() behaves
on different OS'es.


There is a possibility of error caused by bad design (which isn't
trimmed to the type of mistakes we fallible humans make) in your
operator introduction scheme.


Same is true with free form function names, of course.
You haven't shown me that it can be implemented in a compiler,
even in theory. That should count for something.


I don't think there's a credible assertion that my idea is
impossible. You want me to describe a whole compiler
implementation just to support my idea?


I listed some specific objections with regards to disambiguation of
the grammer that the parser would have to be able to handle.


Even without a full grammar being specified? That's a pretty good trick.
About a year ago, Slumberger gave an amazing talk about implementing pico-java
bytecode into a smart card. It was incredible, because it was obvious that
they would be able to use all the Java tools/libraries, they could simulate it
almost perfectly in software -- mostly inheriting the pico-java architecture,
and because of Java's bignum class, it meant that exposing a widening multiply
and carry propogating add functionality in their smart card would be enough to
automatically have all the software they need for RSA all ready to go.


...So the smartcard presumes it's inserted into a machine that has these
classes available?


No ...
[...] They don't reside on the card itself....
Yes they do. That's the point of creating a pico-java assembly
language. Its so that you just have to upload a minimal java kernel to
it, and all of a sudden you have the whole world's Java libraries at your
disposal.
[...] Well, they
should be using Java then, I suppose. No need to augment C.
You misunderstand the point. Most of this kind of development
actually *does* happen in C + assembly language. Slumberger just
demonstrated that using Java is far superior, for the more general
reason that they get to inherit the entire Java infrastructure to help
them design their smart card software. But hidden in all of this is
the fact that C is further penalized quite specifically on the issue
of bignums which become a huge pain in the ass to deal with. There is
*NO* infrastructure for porting bignum functionality in C, using
embedded frameworks, gcc, or otherwise. Its all just "roll your own"
territory.
Ok, a large 2s complement integer is filled with an
array of unsigned sub-integers, except for the one at the top. *That* one is
signed, and that's how you know if the bignum integer is negative or not. The
problem is that the act of addition can cause a roll around at the top word
which requires an expansion of bignum by an extra integer in size. The logic
you use to determine this is just related to examining the carry flag.


Great. Now what has all this to do with defining a sensible signed <+
semantics for use in C (you know, a general purpose language, not tied
to your particular pet peeve problem).


Oh yeah my particular pet peeve problem, which only every serious CPU
company on the planet is only too willing to solve for me.
It all just comes down to the carry flag. The other flags are not
necessary for bignum libraries. Maybe there's a way to transform
the OF into something that can be used in a bignum library, but I
am not aware of it.


Because, we're talking about expanding the C language here (not about
your fairy-tale operator introduction hocus-pocus). You need decent
semantics.


CPU companies have laid out the decent semantics. I and others have
written bignum routines -- the carry flag is where its at as far as
this is concerned.
>>>>- var is set to the result of the addition; the remainder if
>>>>a carry occurs.
>>>
>>>What happens if the signedness of var, a, and b are not equal?
>
>>It just behaves like the ADC x86 assembly instruction, the
>>details of which I will not regurgitate here.
>
>So on adding a signed plus unsigned.... The carry gets a value
>"as if" the signed value was actually unsigned?

Yes. Note that x86 does not have a version of ADC that considers
the sign of its operands in any special way that is reflected in
the CF.

Of course, but you have to know whether your operands are signed or
unsigned to see whether the CF or the OF is the important flag.


OF is never the important flag. Its not relevant at all.


I guess that's why everything since the 4004 supports it.


That's because OF is used for <,>,<=,>= comparisons. Outside of
this, I have never seen OF being used for any purpose. I.e., I would
surmise that the only relevant usage of OF is already encoded in the
language semantics of C (and just about any other language with
integers.) But I could be wrong -- can you name at least one other
purpose which isn't really just an encoding of <,>,<=,>= ?
You must really consider that there's more to life than multiplying big
numbers (and that's coming from one of the few people that sees the fun
in it). We're not going to extend C with an operator to fit this (or
ANY) one purpose, however important it may be.
Carry flag comes up time and again. Just look it up on google:

http://www.google.com/search?hl=en&lr=&ie=ISO-8859-
1&safe=off&c2co ff=1&q=jc+ret+m ov

Off the top of my head, there's chain shifting, bit counting, and
predication/masking.
I'm still wondering about the high_order_valu e() and low_order_value ()
semantics I mentioned in my previous post, actually the part which I was
most curious about.


I wasn't able to suss out a coherent question from your post, so I just deleted
this discussion.


...And there I was thinking you had trouble answering it. What was I
thinking?
In this case, I am just copying the x86's MUL -> EDX:EAX or
AMD64's MUL -> RDX:RAX semantics.


So again (as with the carry vs. overflow), you're going to perform an
instruction that works on UNsigned integers even on signed integers.


Yes.
Pardon my French, but that's just plain stupid. Perhaps you should be a
little less confident about your own understanding of bit-twiddling...


Perhaps you should consider that there's a reason every assembly
language in existence associated signedness with particular
*OPERATIONS* not the *OPERANDS*. Having signed and non-signed versions of
every operator may be something that fit C when it was first designed, but that
doesn't make it necessarily correct for all relevant computations.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/
Nov 14 '05 #141
Paul Hsieh wrote:
Sidney Cadot wrote:
Paul Hsieh wrote:
> .... snip ...>
> Of course, but you have to know whether your operands are
> signed or unsigned to see whether the CF or the OF is the
> important flag.

OF is never the important flag. Its not relevant at all.


I guess that's why everything since the 4004 supports it.


That's because OF is used for <,>,<=,>= comparisons. Outside of
this, I have never seen OF being used for any purpose. I.e., I
would surmise that the only relevant usage of OF is already
encoded in the language semantics of C (and just about any other
language with integers.) But I could be wrong -- can you name
at least one other purpose which isn't really just an encoding
of <,>,<=,>= ?


How about its named purpose, detection of overflow? I have
written x86 code generators that emitted INTO after every signed
integer operation.

Instead of these monstrous articles dealing with every aspect of
everything under the sun, I suggest you cut out single themes,
adjust the subject to suit, and deal with (or argue about) them
one at a time. I see something like seven or eight articles here
between 500 and 1000 lines long, which is ridiculous.

--
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 #142
In article <MP************ ************@ne ws.sf.sbcglobal .net>,
qe*@pobox.com says...
Care to take a quick survey of comp.lang.c patrons who own their own copy of
the standard?


I bought the 18 buck pdf version quite some time ago, and more recently
the hardback version including the rationale and TC1 published by Wiley
& Sons. Most the people I work with have at least seen it, own one of
the preliminary drafts, or have sprung for the $18. If you are
claiming to be a professional C programmer that can't afford $18,
you're lying to yourself.
We have long longs nowadays. 2^32 is not an important limit.


And long long's are portable?!?! Are you even following your own
train of thought?


You are right about that, given the lack of gcc everywhere, or a
C99 compiler proper. However, it is indeed trivial to use a couple
typedef's in a header file, say "bigtypes.h " or something, that
define U64 and I64 in a platform-dependent way *IFF* it's not a
C99 implementation that does not support long long directly. A
simple #ifdef chain with an error directive at the end if the
platform isn't yet supported will make the porting effort for a
new platform (which has a local way to support 64-bit types) a
matter of a few minutes, if not seconds.

--
Randy Howard _o
2reply remove FOOBAR \<,
_______________ _______()/ ()_____________ _______________ _______________ ___
SCO Spam-magnet: po********@sco. com
Nov 14 '05 #143
Paul Hsieh wrote:
(I'm snipping superfluous bits, I propose we concentrate on the
important things and leave some other things aside, to keep this
manageable...)

Sidney Cadot wrote:
Paul Hsieh wrote:
[snip]

I think there are relatively few excuses for any professional C
programmer not to have access to the standard (and reading it once or
twice wouldn't hurt either). It's only 18 bucks in electronic form,
and you don't even have to go out to get it.
Care to take a quick survey of comp.lang.c patrons who own their own copy of
the standard?


Sure, I think you'd be surprised.

What is your excuse for not having the standard? A free draft (N869) is
also available.
My objection to your proposal can simply be restated as "all
machines have limited resources", deal with it.


Then the standard would have to specify what it means exactly by a
"resource". Standards are no places for vague terminology.

You mean vague terminologies like "stack"?


No, I meant "resource".

There doesn't have to be any mention of "stack" in what I try to
propose. Obviously, active function invocations consume memory - that's
what I would like to see formalized.
I had to look this one up -- that's one of the classic useless
non-solutions (especially if you want to call malloc more than 4
billion times, for example), which explains why I've never
committed it to memory.


We have long longs nowadays. 2^32 is not an important limit.

And long long's are portable?!?! Are you even following your own
train of thought?


You really seem a bit out of touch with current events... Since you
don't seem to have access to the C99 standard, here's the relevant quote:

6.2.5 clause #4:

"There are five standard signed integer types, designated as signed
char, short int, int, long int, and long long int. (These and other
types may be designated in several additional ways, as described in
6.7.2.) There may also be implementation-defined extended signed integer
types. The standard and extended signed integer types are collectively
called signed integer types."

(somewhat further down, the unsigned long long int is defined).

Both must be able to represent at least 64 bit values (-2^63..2^63-1,
0..2^64-1, respectively).
You still need to be able to identify process instances, which *BY
ITSELF* is not portable. Process instances identifiers would
count as something *BEYOND* just malloc/free/etc.


Why do you need to distinguish process instances?


Reread the Lamport's bakery algorithm. One of the crucial steps is
"for each process, check their number, and pick the max, then add 1".
Another is "for each process that has a lower number, wait in line
behind them." This means you have a way of knowing how many processes
there are, and how to index them. This means you have to hook out or
wrap whatever "spawn" mechanism you have in your language (or use some
other platform specific mechanism to iterate through all running
threads.)


Could you provide a reference to the description of the algorithm you're
using? I'm not saying it's incorrect or anything, it's just that I'd
like to respond in the same terminology.
[...] In your API, each call carries the heap it refers to as a
parameter.

Yes, but if two threads simultaneously call heap functions on the same
heap (heaps are not restricted to being distinct across threads) then
there is a race condition.


So we need to put a mutex around the critical section, no big deal. 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.
I would say that writing a more powerful heap manager is possible in
principle , even in a multithreaded environment, as long as you have a
well-implemented malloc() (and friends) at your disposal.

*BZZZT!!!* Wrong.
It would be a drag to do so and it would be slow, but it is possible.

Impossible . Slow, fast or otherwise. Its just impossible.


If you can explain to me why you need to explicitly distinguish threads
in the memory manager, I'll concede the point. Go look up the source code for *ANY* multithreading supporting
malloc/free. I absolutely guarantee that every single one of them
uses some kind of platform specific exclusion object to make sure that
two simultaneous calls to the heap do not collide.
Sure. Mutexes would suffice and I contend the bakery algorithm can
provide them. I feel rather silly getting dragged in this line of
discussion (multithreading has little to do with the C execution model)
but we'll see where this leads us.
One way or another the heap is some kind of quasi-linked list of memory
entries. You should have learned from your OS classes (assuming you passed it
and/or comprehended the material)
Could you refrain from the silly ad hominems? I am trying to take you
seriously, even though you seem to deny the importance of standards, and
even though you are advocating an (in my opinion) confused "operator
introduction" feature. Maintaining a basic level of respect helps in any
discussion.
---- Proposed addition to the standard to add stack overflows:
---- Draft

a. For an active function invocation, define an upper bound for the
amount of memory in use by this function as follows (in the
following, denote "Upper Limit on Memory Usage" by "ULMU"):

And what if the local/parameters are not stored, or storable on the stack?


How do you mean? They have to be stored. And I'm presuming they're
stored on the stack.

Most microprocessors have these temporary storage elements called
"registers" . They are often not part of any stack structure. Many modern
compilers will map local variables and temporaries to these "registers" , thus
not requiring stack storage for them.


Not an issue, as I try to establish an upper bound. The fact that the
implementation can do better by using registers is of no concern.
What if an implementation uses multiple stacks depending on the
*type* of the parameter?


The hypothetical implementation [...]

That the ANSI C standard currently does not have any problem with ...

[...] that does this will be out of luck. Not because the proposal
wouldn't work, mind you, but because the ULMU is a very loose bound.
But hey, it beats having no bound whatsoever.

No it doesn't. Dealing with the stack is an area that clearly should be
platform specific. For example, it could be that an embedded system has
fast and slow ram. Certain data types might be best suited to being mapped
into fast RAM, whether they are local or not, but you might have a lot more
slow RAM, so you'd put all the rest of the stuff in there.


To what does "no it doesn't" refer?

How does your example invalidate the "upper bound" idea?
- For every parameter/local variable of basic type there is a
corresponding constant macro of type size_t:

You missed all the implicit temporaries required. Homework
exercise: for any fixed number n, create a function which requires
at least n implicit temporaries (not explicitely declared) to
implement.


Ah yes! So it seems. An interesting problem. Have to think about that
for a bit.


Why don't you think about the implication of the results of this
exercise with respect to your proposal while you are at it.


If no way can be found to address this, we can no longer give an upper
bound, and the proposal is dead in the water. However, I'm not conviced
it can't be handled. For one thing, your proposal to make macro's
available outside the function scope that give the functions stack usage
upper bound may come in handy.
And what about the number of alloca() calls? alloca() is a common
extension which just eats extra space off the stack dynamically --
the big advantage being that you don't have to call free or
anything like it, for it to be properly cleaned up. It will be
cleaned up upon the function's return (the simplest implementation
of a "freeall".)


Ok, we can add alloca'ed space is each function invoation, plus an
overhead constant per active alloca.

The alloca() calls can be in a loop. Knowing how much memory a set of
alloca's will perform in any function is equivalent to solving the
halting problem.


So what? Why is this relevant? Most of the time you can still give an
upper bound. In cases where you can't (few and far inbetween) you don't
have the guarantee, which is a pity; the code can no longer be written
in a way that's fully portable. It would still be much better than what
happens now (standard-compliant programs segfaulting without so much as
a hint in the standard).
Unless you allow that I'm trying to define an upper bound of total use,
which may be loose as far as I am concerned. The idiomatic use would be
to compare this to the ULMU_TOTAL to see if it fits. This may yield the
number of bytes on the smallest check for all I care. On those silly
platforms, you will grossly underestimate stack capacity now and then.
[...] Still beats the current situation.

This versus just living with runtime stack checking? I'll take the
runtime stack checking.


Then define a proposal to formalize "runtime stack checking" in
standard-like language.
[...]
My opionion is determined largely by the psychological objections (to
which you don't subscribe.) Says who? You see, unlike some people, by idea isn't driven by an
opinion. Its driven by a consideration for design. Since you *CAN'T*
add just any old operator to satisfy everyone, then how do you satisfy
the demand for more operators? Some variation on redefinable
operators or operator overloading is the logical conclusion -- just
fix its problems (since type-index functions don't really exist in C,
so you just add in a bunch of them so that you don't lose any of the
ones you have). For all I know, I might not ever use such a feature,
even if it *WERE* to be endorsed by the standard.
I fail to see the point you want to make here.
My technical problem is that I can see no way that this could be
implemented .

Well I don't know what to make of this -- you can't see a race
condition when its staring you in the face, and you can't imagine
problems with knowing the size of a function's stack usage.


Be careful not to presume things that are not there. Other than that,
make of it what you like.
[...]
There is a possibility of error caused by bad design (which isn't
trimmed to the type of mistakes we fallible humans make) in your
operator introduction scheme.

Same is true with free form function names, of course.


The risks of errors are minute, in comparison.
You haven't shown me that it can be implemented in a compiler,
even in theory. That should count for something.

I don't think there's a credible assertion that my idea is
impossible . You want me to describe a whole compiler
implementati on just to support my idea?


I listed some specific objections with regards to disambiguation of
the grammer that the parser would have to be able to handle. Even without a full grammar being specified? That's a pretty good trick.
Yes, it's called "abstract thinking". It's a cousin of "thought experiment".
[smartcards]
Yes they do. That's the point of creating a pico-java assembly
language. Its so that you just have to upload a minimal java kernel to
it, and all of a sudden you have the whole world's Java libraries at your
disposal.
How much would these combined libraries consume, in terms of memory on
the smartcard? I mean, the bignum-multiply code has to reside somewhere.
[...]
Great. Now what has all this to do with defining a sensible signed <+
semantics for use in C (you know, a general purpose language, not tied
to your particular pet peeve problem).

Oh yeah my particular pet peeve problem, which only every serious CPU
company on the planet is only too willing to solve for me.


You haven't answered the question.
It all just comes down to the carry flag. The other flags are not g
necessary for bignum libraries. Maybe there's a way to transform
the OF into something that can be used in a bignum library, but I
am not aware of it.


Because, we're talking about expanding the C language here (not about
your fairy-tale operator introduction hocus-pocus). You need decent
semantics. CPU companies have laid out the decent semantics. I and others have
written bignum routines -- the carry flag is where its at as far as
this is concerned.
That's fine. Now here's a big idea: hardware design and general-purpose
language design are two different things.
[...]
OF is never the important flag. Its not relevant at all.


I guess that's why everything since the 4004 supports it. That's because OF is used for <,>,<=,>= comparisons. Outside of
this, I have never seen OF being used for any purpose. I.e., I would
surmise that the only relevant usage of OF is already encoded in the
language semantics of C (and just about any other language with
integers.) But I could be wrong -- can you name at least one other
purpose which isn't really just an encoding of <,>,<=,>= ?
Adding, subtracting, multiplying, dividing. Basically anything
arithmetic you can do that can map the result of an operation on signed
ints to a value that doesn't correspond to the mathematical
interpretation of what the result should be.
You must really consider that there's more to life than multiplying big
numbers (and that's coming from one of the few people that sees the fun
in it). We're not going to extend C with an operator to fit this (or
ANY) one purpose, however important it may be.

Carry flag comes up time and again. Just look it up on google:

http://www.google.com/search?hl=en&lr=&ie=ISO-8859-
1&safe=off&c2co ff=1&q=jc+ret+m ov


That seems to yield some results concerning intel assembly. Interesting,
but how does that address my point?
Off the top of my head, there's chain shifting, bit counting, and
predication/masking.
You don't have to convince me that carry flags are important. At times I
have found myself in want of a way to access them myself, from C.
However, the point is that you would have to find a good semantics, that
fits in with the rest of C, not some ad-hoc operator to make some bignum
implementors happy.
[...]
In this case, I am just copying the x86's MUL -> EDX:EAX or
AMD64's MUL -> RDX:RAX semantics.


So again (as with the carry vs. overflow), you're going to perform an
instruction that works on UNsigned integers even on signed integers.


Yes.


That doesn't rhyme well with C. There are many subtle issues with
signed/unsigned representation and operations, and the standard is
careful to find a compromise; not assuming too much on the architecture
side, while at the same time maintaining a sound semantics for both
signed and unsigned operations. Your semantics just doesn't fit in.
Pardon my French, but that's just plain stupid. Perhaps you should be a
little less confident about your own understanding of bit-twiddling...

Perhaps you should consider that there's a reason every assembly
language in existence associated signedness with particular
*OPERATIONS* not the *OPERANDS*.
Are you aware that the C standard allows for other representations than
2-complement? Assume 1-complement representation for a moment (the
standard is specifically worded to allow this).

10000001 - 00000001 yields 10000010 if '-' is a signed operator
10000001 - 00000001 yields 10000000 if '-' is an unsigned operator

Now I don't know assembly for any 1-complement architecture, but from
this it seems to me that there will have to be different signed and
unsigned versions of 'SUB'.
Having signed and non-signed versions of
every operator may be something that fit C when it was first designed, but that
doesn't make it necessarily correct for all relevant computations.


Well, if (and that's a big if) something resembling your wide-mul would
ever make it in the standard, I'd be disappointed if it didn't for
instance allow me to multiply two big signed integers. It would be messy
to only support unsigned ones.

Best regards,

Sidney

Nov 14 '05 #144
>In article <MP************ ************@ne ws.sf.sbcglobal .net>,
qe*@pobox.co m says...
Care to take a quick survey of comp.lang.c patrons who own their own copy of
the standard?

In article <news:MP******* *************** **@news.megapat hdsl.net>
Randy Howard <ra**********@F OOmegapathdslBA R.net> writes:I bought the 18 buck pdf version quite some time ago, and more recently
the hardback version including the rationale and TC1 published by Wiley
& Sons. ...


I still have not paid for the C99 standard, but do not need it yet
as we only claim to support C89 (not even "C95", with the various
addenda). I did buy the dead-tree edition of the 1989 C standard
some time in the early 1990s, back when it cost $75 and came with
the Rationale, and before the various "TC"s and "NA"s.

(I use an out-of-date C99 draft for online "quick reference" as
needed. I really should just get the $18 PDF version, but I find
on-line editions of technical documentation far less useful, as
yet, than printed editions. PDF is not as portable as it should
be; displays are just not high enough resolution to make reading
easy; marking pages does not work as well; and they are not
comfortable to take to the restrooms. :-) )
--
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 #145
Chris Torek <no****@torek.n et> writes:
(I use an out-of-date C99 draft for online "quick reference" as
needed. I really should just get the $18 PDF version, but I find
on-line editions of technical documentation far less useful, as
yet, than printed editions. PDF is not as portable as it should
be; displays are just not high enough resolution to make reading
easy; marking pages does not work as well; and they are not
comfortable to take to the restrooms. :-) )


I use a C99 PDF converted to text format most of the time. The
formatting isn't perfect, but it is good enough for most purposes
most of the time, and it is easily searchable.
--
"C has its problems, but a language designed from scratch would have some too,
and we know C's problems."
--Bjarne Stroustrup
Nov 14 '05 #146
Sidney Cadot wrote:
Paul Hsieh wrote:
Sidney Cadot wrote:
Paul Hsieh wrote:
[snip]
I think there are relatively few excuses for any professional C
programmer not to have access to the standard (and reading it once
or twice wouldn't hurt either). It's only 18 bucks in electronic
form, and you don't even have to go out to get it.
Care to take a quick survey of comp.lang.c patrons who own their
own copy of the standard?


Sure, I think you'd be surprised.


Well the few people in here who have the standard have chimed in. Now
how do you supposed we convince everyone else in the group to chime
about the fact that they don't have it? (Look up the term "push poll"
if you don't understand what I mean.)
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. Then tell me where in the
standard it says that strtok is not re-enterable.
I had to look this one up -- that's one of the classic useless
non-solutions (especially if you want to call malloc more than 4
billion times, for example), which explains why I've never
committed it to memory.
We have long longs nowadays. 2^32 is not an important limit.


And long long's are portable?!?! Are you even following your own
train of thought?


You really seem a bit out of touch with current events... Since you
don't seem to have access to the C99 standard, here's the relevant
quote:


Excuse me?!?! *C99* is not portable.
You still need to be able to identify process instances, which *BY
ITSELF* is not portable. Process instances identifiers would
count as something *BEYOND* just malloc/free/etc.

Why do you need to distinguish process instances?


Reread the Lamport's bakery algorithm. One of the crucial steps is
"for each process, check their number, and pick the max, then add
1". Another is "for each process that has a lower number, wait in
line behind them." This means you have a way of knowing how many
processes there are, and how to index them. This means you have
to hook out or wrap whatever "spawn" mechanism you have in your
language (or use some other platform specific mechanism to iterate
through all running threads.)


Could you provide a reference to the description of the algorithm
you're using?


Typed it into google and felt lucky. Its the first hit. Notice
language like "Process i", and statements like for (j=0; j < n; j++),
where each j indexes a process id, and n is the number of processes.
I tried to think up a way of implementing that algorithm without
specifically requiring an enumeration of processes, but it seems that
that is central to the way the algorithm works. Which is only *one*
of the reasons why that algorithm is worthless.
[...] I'm not saying it's incorrect or anything, it's just that I'd
like to respond in the same terminology.
[...] In your API, each call carries the heap it refers to as a
parameter.
Yes, but if two threads simultaneously call heap functions on the same
heap (heaps are not restricted to being distinct across threads) then
there is a race condition.


So we need to put a mutex around the critical section, no big deal.


It *is* a big deal. Mutexes, and other similar multithreading objects
are not expressible is a portable way in language like C or C++.
[...] 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.
It only took me only 30 seconds to understand it.
>I would say that writing a more powerful heap manager is possible in
>principle , even in a multithreaded environment, as long as you have a
>well-implemented malloc() (and friends) at your disposal. [...]
>It would be a drag to do so and it would be slow, but it is possible.

Impossible . Slow, fast or otherwise. Its just impossible.

If you can explain to me why you need to explicitly distinguish threads
in the memory manager, I'll concede the point.
Go look up the source code for *ANY* multithreading supporting
malloc/free. I absolutely guarantee that every single one of them
uses some kind of platform specific exclusion object to make sure that
two simultaneous calls to the heap do not collide.


Sure. Mutexes would suffice and I contend the bakery algorithm can
provide them.


Well, but that's not my contention, and I would appreciate that you not put
words in my mouth, or follow the discussion (whichever one is causing
you do write things like this) -- my contention is that Lamport's
Bakery algorithm is not portable (I mean relative to C, which doesn't
expose and multithreading functionality, even if implementations do.)
Then again, once you open it up to non-portable code, of course,
nobody will touch Lamport's Bakery algorithm with a 10 ft pole -- its
worthless when you have far superior mechanisms for creating Mutexes
at your disposal.
[...] I feel rather silly getting dragged in this line of
discussion (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
intertwined 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
consideration. There is no such thing as a portable mutex in pure C
that actually encodes all the expected notions of a mutex unless tied
specifically to the extension mechanisms that are used to provide the
multitasking 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.
One way or another the heap is some kind of quasi-linked list of
memory entries. You should have learned from your OS classes
(assuming you passed it and/or comprehended the material)


Could you refrain from the silly ad hominems? I am trying to take you
seriously, even though you seem to deny the importance of standards,
and even though you are advocating an (in my opinion) confused
"operator introduction" feature. Maintaining a basic level of
respect helps in any discussion.


Well, if you are sensitive about being admonished in public, then can
I ask that you have a little bit of intellectual honesty? I am trying
to put forward hard core analytical ideas, and I have made efforts to
distill your own proposals is a very serious way. The response is not
supposed to be "oh but you can't prove its impossible to implement".
This is like Ari Fleischer telling the anti-war sympathizers that its
up to them to prove that there are no WMDs in Iraq. If you have a
problem with what I am saying why can't you limit it to an analytical
response?

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),
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. Are you going to do it again, or are you
going at least take my arguments more seriously?

You see its not *UP* to me to analyze bogus algorithms to prove that
you can't implement a mutex portably. That's retarded -- even if I do,
its not actual proof of anything. If you have a serious contention
against my very technical claim, then don't you think that its at
least somewhat incumbant upon your to wade through the details
yourself?
What if an implementation uses multiple stacks depending on the
*type* of the parameter?

The hypothetical implementation [...]


That the ANSI C standard currently does not have any problem with ...
[...] that does this will be out of luck. Not because the proposal
wouldn't work, mind you, but because the ULMU is a very loose bound.
But hey, it beats having no bound whatsoever.


No it doesn't. Dealing with the stack is an area that clearly
should be platform specific. For example, it could be that an
embedded system has fast and slow ram. Certain data types might
be best suited to being mapped into fast RAM, whether they are
local or not, but you might have a lot more slow RAM, so you'd put
all the rest of the stuff in there.


To what does "no it doesn't" refer?


The last statement "... it beats having no bound ..."
How does your example invalidate the "upper bound" idea?
Look, if you have two stacks, then the right way to bound it is to
have two bounds. If one of your stacks has very limited amount of
memory (fast RAM is likely to be more expensive) then in order to
properly implement a single bound (you proposal) you need to assume
the worst case and say that you only have as much stack space of the
smaller stack (otherwise it wouldn't be a correct bound.) This is
completely worthless to systems that want to expose really really deep
call stacks but fairly shallow floating point stacks, for example
(look up the Ackerman function again, and try to imagine attempts at
mathematical simplifications , to be able to output at least *some* of
the reasonable computable values in reasonable time.)
> - For every parameter/local variable of basic type there is a
> corresponding constant macro of type size_t:

You missed all the implicit temporaries required. Homework
exercise: for any fixed number n, create a function which requires
at least n implicit temporaries (not explicitely declared) to
implement.

Ah yes! So it seems. An interesting problem. Have to think about that
for a bit.


Why don't you think about the implication of the results of this
exercise with respect to your proposal while you are at it.


If no way can be found to address this, we can no longer give an upper
bound, and the proposal is dead in the water. However, I'm not conviced
it can't be handled.


I can see once again I'll be trying to prove that the are no WMDs in
Iraq ...
[...] For one thing, your proposal to make macro's available outside
the function scope that give the functions stack usage upper bound
may come in handy.
See how that worked out? You had a proposal, I found something wron
with it, so I offered something *CONSTRUCTIVE* to try to save it,
rather than pretending it would fail because of an issue that I can
work around even if you might have missed it. Its called intellectual
honesty.
And what about the number of alloca() calls? alloca() is a common
extension which just eats extra space off the stack dynamically --
the big advantage being that you don't have to call free or
anything like it, for it to be properly cleaned up. It will be
cleaned up upon the function's return (the simplest implementation
of a "freeall".)

Ok, we can add alloca'ed space is each function invocation, plus an
overhead constant per active alloca.


The alloca() calls can be in a loop. Knowing how much memory a set of
alloca's will perform in any function is equivalent to solving the
halting problem.


So what? Why is this relevant? Most of the time you can still give an
upper bound.


Perhaps you do not know the true nature of the halting problem. You
can't know if a piece of code ends, which is equivalent to knowing if
it takes one branch or another, or how many times it executes a given
code fragment. There's no shortage of open mathematical problems for
which the output of a given function is just completely unboundable,
calculatable, or estimatable (the famous "+3 on odd, /2 if even"
problem which I can't recall the details of comes to mind) with any
current knowledge.
[...] In cases where you can't (few and far inbetween) you don't
have the guarantee, which is a pity; the code can no longer be
written in a way that's fully portable. It would still be much
better than what happens now (standard-compliant programs
segfaulting without so much as a hint in the standard).
It means you are expecting compilers to come as close to solving the
halting problem as they can. And you think variable length operators
based on a grammar is an impossible, intractible problem in
practice?!?!
Unless you allow that I'm trying to define an upper bound of total
use, which may be loose as far as I am concerned. The idiomatic
use would be to compare this to the ULMU_TOTAL to see if it fits.
This may yield the number of bytes on the smallest check for all I
care. On those silly platforms, you will grossly underestimate
stack capacity now and then. [...] Still beats the current
situation.


This versus just living with runtime stack checking? I'll take the
runtime stack checking.


Then define a proposal to formalize "runtime stack checking" in
standard-like language.


The implementation may exit or take any other defined action which halts
the execution on any function call. But it may not create undefined
behaviour from the action of performing the call itself alone.

There's a proposal that's compatible with many implementations today
(if we presume that turning stack checking *off* would be an
extension, and that leaving it on is the default conforming behavior)
and should be easy to understand and implement.
[...]
My opionion is determined largely by the psychological objections (to
which you don't subscribe.)
Says who? You see, unlike some people, by idea isn't driven by an
opinion. Its driven by a consideration for design. Since you *CAN'T*
add just any old operator to satisfy everyone, then how do you satisfy
the demand for more operators? Some variation on redefinable
operators or operator overloading is the logical conclusion -- just
fix its problems (since type-index functions don't really exist in C,
so you just add in a bunch of them so that you don't lose any of the
ones you have). For all I know, I might not ever use such a feature,
even if it *WERE* to be endorsed by the standard.


I fail to see the point you want to make here.


Just that I am trying analyze problems, and you are just spouting
opinion.
My technical problem is that I can see no way that this could be
implemented.


Well I don't know what to make of this -- you can't see a race
condition when its staring you in the face, and you can't imagine
problems with knowing the size of a function's stack usage.


Be careful not to presume things that are not there. [...]


Yeah, thanks for the warning. I'll be sure to purchase some duct tape
to deal with my neighbors who might be terrorists too.

The race is there. I reduced it to the standard notions that you are
supposed to learn about in an OS class. I've explained everything you
need to know to understand its there. Any research you do into the
subject will confirm what I'm saying. But I'm supposed to worry that
I might be wrong based on your flimsy non-arguments.
There is a possibility of error caused by bad design (which isn't
trimmed to the type of mistakes we fallible humans make) in your
operator introduction scheme.


Same is true with free form function names, of course.


The risks of errors are minute, in comparison.


An opinion you will back up how ... ?
>You haven't shown me that it can be implemented in a compiler,
>even in theory. That should count for something.

I don't think there's a credible assertion that my idea is
impossible . You want me to describe a whole compiler
implementati on just to support my idea?

I listed some specific objections with regards to disambiguation of
the grammer that the parser would have to be able to handle.
Even without a full grammar being specified? That's a pretty good trick.


Yes, it's called "abstract thinking". It's a cousin of "thought
experiment".


Yeah, well believing that there are parsable grammars doesn't take very much
"abstract thinking", there millions of examples.
[smartcards]
Yes they do. That's the point of creating a pico-java assembly
language. Its so that you just have to upload a minimal java kernel to
it, and all of a sudden you have the whole world's Java libraries at your
disposal.


How much would these combined libraries consume, in terms of memory on
the smartcard? I mean, the bignum-multiply code has to reside somewhere.


If you have a widening multiply, a bignum multiply is tiny. As a WAG,
maybe 30 instructions or so? Obviously the don't *include* every
library -- I imagine they need the Java GUI for a smart card. Look
I'm not going to defend them, *they* did it, not me. Go look this stuff up
yourself:

http://www.google.com/search?hl=en&ie=UTF-
8&c2coff=1&safe =off&q=Michael+ Montgomery+Java +smart+card&spe ll=1
> It all just comes down to the carry flag. The other flags are
> not g necessary for bignum libraries. Maybe there's a way to
> transform the OF into something that can be used in a bignum
> library, but I am not aware of it.

Because, we're talking about expanding the C language here (not
about your fairy-tale operator introduction hocus-pocus). You
need decent semantics.
CPU companies have laid out the decent semantics. I and others have
written bignum routines -- the carry flag is where its at as far as
this is concerned.


That's fine. Now here's a big idea: hardware design and general-purpose
language design are two different things.


And so which category do you think "bignum libraries" falls into? I
mean given that every platform supports it, and that in fact an
implementation (the GMP) purports to be a software library with a
portable interface up to software, supporting just about every popular
desktop/server/workstation platform under the sun.
[...]
OF is never the important flag. Its not relevant at all.
I guess that's why everything since the 4004 supports it.
That's because OF is used for <,>,<=,>= comparisons. Outside of
this, I have never seen OF being used for any purpose. I.e., I would
surmise that the only relevant usage of OF is already encoded in the
language semantics of C (and just about any other language with
integers.) But I could be wrong -- can you name at least one other
purpose which isn't really just an encoding of <,>,<=,>= ?


Adding, subtracting, multiplying, dividing. Basically anything
arithmetic you can do that can map the result of an operation on signed
ints to a value that doesn't correspond to the mathematical
interpretation of what the result should be.


No, we all understand what produces an OF, I mean, name an actual
agorithm that uses it, that can't extract the semantics from one of
<,>,<=,>=.
[...]
In this case, I am just copying the x86's MUL -> EDX:EAX or
AMD64's MUL -> RDX:RAX semantics.

So again (as with the carry vs. overflow), you're going to perform an
instruction that works on UNsigned integers even on signed integers.


Yes.


That doesn't rhyme well with C.


Well that's right -- *bignums* don't rhyme well with C. *STRINGS*
don't rhyme well with C. *BITS* don't rhyme well with C. That
doesn't mean its not worth having them.
[...] There are many subtle issues with
signed/unsigned representation and operations, and the standard is
careful to find a compromise; not assuming too much on the
architecture side, while at the same time maintaining a sound
semantics for both signed and unsigned operations. Your semantics
just doesn't fit in.


There's your deep analysis again "... just doesn't fit in ...". I
just can't argue with that. Wow, I guess I am just wrong.
Pardon my French, but that's just plain stupid. Perhaps you should
be a little less confident about your own understanding of
bit-twiddling...
Perhaps you should consider that there's a reason every assembly
language in existence associated signedness with particular
*OPERATIONS* not the *OPERANDS*.


Are you aware that the C standard allows for other representations
than 2-complement? Assume 1-complement representation for a moment
(the standard is specifically worded to allow this).


Yes, but the semantics of what a carry is, is not crucially tied to
this. Even if you use ones complement, or something else, you can
still *compute* the carry, even if you don't automatically have it from
the built-in representation.
Having signed and non-signed versions of every operator may be
something that fit C when it was first designed, but that doesn't
make it necessarily correct for all relevant computations.


Well, if (and that's a big if) something resembling your wide-mul
would ever make it in the standard, I'd be disappointed if it didn't
for instance allow me to multiply two big signed integers. It would
be messy to only support unsigned ones.


But I didn't precisely say that. In fact losing the (un)signedness
semantics is really something you need for the carry flag idea. The
"almost like widening multiplies", that exist in C retain the sign as
you would expect, and obviously you probably wouldn't want to change
that in an extension to C.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/
Nov 14 '05 #147
Paul Hsieh wrote:

Sidney Cadot wrote:
Paul Hsieh wrote:
Sidney Cadot wrote:
>Paul Hsieh wrote:
> [snip]
>I think there are relatively few excuses for any professional C
>programmer not to have access to the standard (and reading it once
>or twice wouldn't hurt either). It's only 18 bucks in electronic
>form, and you don't even have to go out to get it.

Care to take a quick survey of comp.lang.c patrons who own their
own copy of the standard?
Sure, I think you'd be surprised.


Well the few people in here who have the standard have chimed in. Now
how do you supposed we convince everyone else in the group to chime
about the fact that they don't have it? (Look up the term "push poll"
if you don't understand what I mean.)
What is your excuse for not having the standard? A free draft (N869)
is also available.


That document gets referenced here from time to time.

Searched Groups for N869 group:comp.lang .c.*
Results 1 - 10 of about 2,200. Search took 1.30 seconds.

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. Then tell me where in the
standard it says that strtok is not re-enterable.


N869
7.1.4 Use of library functions
[#4] The functions in the standard library are not
guaranteed to be reentrant and may modify objects with
static storage duration.

--
pete
Nov 14 '05 #148
Paul Hsieh wrote:
Sidney Cadot wrote:
Paul Hsieh wrote:
>
> Care to take a quick survey of comp.lang.c patrons who own their
> own copy of the standard?


Sure, I think you'd be surprised.


Well the few people in here who have the standard have chimed in.


Don't be ridiculous.
--
Richard Heathfield : bi****@eton.pow ernet.co.uk
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
Nov 14 '05 #149
Paul Hsieh wrote:
Sidney Cadot wrote:
> [snip]

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. Then tell me where in the standard it says that strtok is
not re-enterable.


Once more, please cut these monstrous postings down to size and
deal with one thing at a time, using suitable subjects.

All those characteristics are not mandated. However it is hard to
see what use any data would be after the end marking '\0', nor any
prohibition against a re-enterable strtok if you can devise a way
to do so. You are told that it saves a pointer, and that the way
to avoid reinitializing that pointer is to pass in NULL. Unless
you have a DWIM machine I fail to see any other basis for
restoring the saved pointer.

--
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 #150

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
23152
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
8728
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
5126
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
1780
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
8625
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
1403
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
3002
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
9903
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
9752
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
11041
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...
0
10692
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that captivates audiences and drives business growth. The Art of Business Website Design Your website is...
0
10373
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...
0
5753
by: TSSRALBI | last post by:
Hello I'm a network technician in training and I need your help. I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs. The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols. I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
0
5946
by: adsilva | last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
1
4565
by: 6302768590 | last post by:
Hai team i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
2
4167
muto222
by: muto222 | last post by:
How can i add a mobile payment intergratation into php mysql website.

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.