hmmm, no C99

[Serve La]

I asked if MS has any plans to support C99 in the next VisualC. This is
their answer.
I think we should whine more :-)

We feel that C++ addresses this space
sufficiently. In general we have no plans to add any C99 features that
duplicate functionality in C++ or conflict with it.

That also matches the feedback we have gotten from customers. In fact the
non interest in C99 is the clearest feedback I have seen of any issue. The
ratio of customers who don't want us to prioritize C99 features versus those
who do is definitely higher than 100:1.
They have planned "restrict" BTW, the one feature I like the least.

[Irrwahn Grausewitz]

"Serve La" <[e-mail]> wrote:

I asked if MS has any plans to support C99 in the next VisualC. This is
their answer.
I think we should whine more :-)

We feel that C++ addresses this space
sufficiently. In general we have no plans to add any C99 features that
duplicate functionality in C++ or conflict with it.

That also matches the feedback we have gotten from customers. In fact the
non interest in C99 is the clearest feedback I have seen of any issue. The
ratio of customers who don't want us to prioritize C99 features versus those
who do is definitely higher than 100:1.
They have planned "restrict" BTW, the one feature I like the least.

Surprised, anyone? This is not to start flame war, but IMHO people
using braindead M$VC for compiling C code are, err..., well..., nah,
I'm not going to insult someone for using a specific product.

Irrwahn

( using gcc, yet another product of the Sirius Cybernetics Corp. ;] )
--
My other computer is a abacus.

[jacob navia]

This is great news.

At least there *is* a market niche within windows that is not occupied by Microsoft!

The lcc-win32 compiler implements most of C99. A full C99 compliant release is
some months away, but most features are implemented.

http://www.cs.virginia.edu/~lcc-win32

[Richard Heathfield]

Serve La wrote:

I asked if MS has any plans to support C99 in the next VisualC. This is
their answer.
I think we should whine more :-)
Or vote with your feet.

<snip>
They have planned "restrict" BTW, the one feature I like the least.

C'est la vie. You don't /have/ to use Visual C, though. There are other
compilers for the Windows platform.

--
Richard Heathfield : bi****@eton.powernet.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

[John Tsiombikas (Nuclear / the Lab)]

Serve La wrote:

I asked if MS has any plans to support C99 in the next VisualC. This is
their answer.
I think we should whine more :-)

Hmmm not really, whine as much as you like but I couldn't give a damn since I
don't use the MSVC/C++ compiler :)
GCC just rulez

-- Nuclear / the Lab --

[Allin Cottrell]

Irrwahn Grausewitz wrote:

"Serve La" <[e-mail]> wrote:

I asked if MS has any plans to support C99 in the next VisualC. This is
their answer.
I think we should whine more :-)

We feel that C++ addresses this space
sufficiently. In general we have no plans to add any C99 features that
duplicate functionality in C++ or conflict with it.

That also matches the feedback we have gotten from customers. In fact the
non interest in C99 is the clearest feedback I have seen of any issue. The
ratio of customers who don't want us to prioritize C99 features versus those
who do is definitely higher than 100:1.
They have planned "restrict" BTW, the one feature I like the least.

Surprised, anyone? This is not to start flame war, but IMHO people
using braindead M$VC for compiling C code are, err..., well..., nah,
I'm not going to insult someone for using a specific product.

Irrwahn

( using gcc, yet another product of the Sirius Cybernetics Corp. ;] )

Yes, well, gcc is not in any hurry to comply with C99 either. I'm
as ready as the next person to blast MS, but in this case the target
seems wrong. Rather, it seems that the C standards group came up
with something that just has not caught on. To date (4 years after
the standard was promulgated), the only C compiler vendors claiming
full C99 compliance are (no offence intended) marginal to the
market. Why should MS devote a lot of expense to something that
few programmers really seem to want? Why should the gcc authors?

--
Allin Cottrell
Department of Economics
Wake Forest University, NC

[Fao, Sean]

"Allin Cottrell" <co******@wfu.edu> wrote in message
news:bk***********@f1n1.spenet.wfu.edu...

Yes, well, gcc is not in any hurry to comply with C99 either. I'm
as ready as the next person to blast MS, but in this case the target
seems wrong. Rather, it seems that the C standards group came up
with something that just has not caught on. To date (4 years after
the standard was promulgated), the only C compiler vendors claiming
full C99 compliance are (no offence intended) marginal to the
market. Why should MS devote a lot of expense to something that
few programmers really seem to want? Why should the gcc authors?

I have read very little of the standard but from what I have read, C99 looks
like it has some great improvements over past standards. I'm just curious
why people would be so uninterested. From what I have gathered about this
group, the majority seem to be pro C99; but, suggest not to use it *yet*
(Again I want to stress that this is only based on simple observation, I
could be entirely wrong about what you all _honestly_ think of the
standard). If somebody is compiling code that will *never* be ported to
another platform, I see no reason not to use the new standard, so long as a
compiler exists for the platform you're developing on. What's the verdict
here?

Sean

[Allin Cottrell]

Fao, Sean wrote:

"Allin Cottrell" <co******@wfu.edu> wrote in message
news:bk***********@f1n1.spenet.wfu.edu...

Yes, well, gcc is not in any hurry to comply with C99 either. I'm
as ready as the next person to blast MS, but in this case the target
seems wrong. Rather, it seems that the C standards group came up
with something that just has not caught on. To date (4 years after
the standard was promulgated), the only C compiler vendors claiming
full C99 compliance are (no offence intended) marginal to the
market. Why should MS devote a lot of expense to something that
few programmers really seem to want? Why should the gcc authors?

I have read very little of the standard but from what I have read, C99 looks
like it has some great improvements over past standards. I'm just curious
why people would be so uninterested. From what I have gathered about this
group, the majority seem to be pro C99; but, suggest not to use it *yet*

I'm not going to claim great expertise, but I've found Dan Pop's postings
on this topic quite persuasive. He points out that C99 includes several
features present in GNU C, but with slightly different semantics. This
would make it awkward for gcc (for one) to move to full C99 compliance.

--
Allin Cottrell
Department of Economics
Wake Forest University, NC

[Jack Klein]

On Mon, 22 Sep 2003 20:00:09 +0200, "Serve La" <[e-mail]>
wrote in comp.lang.c:

I asked if MS has any plans to support C99 in the next VisualC. This is
their answer.
I think we should whine more :-)

We feel that C++ addresses this space
sufficiently. In general we have no plans to add any C99 features that
duplicate functionality in C++ or conflict with it.

That also matches the feedback we have gotten from customers. In fact the
non interest in C99 is the clearest feedback I have seen of any issue. The
ratio of customers who don't want us to prioritize C99 features versus those
who do is definitely higher than 100:1.
They have planned "restrict" BTW, the one feature I like the least.

Despite what some other responses in this thread claim, MSVC++, at
least through version 6, is quite a good C95 implementation.

In addition to lcc-win32's steady progress toward full C99 conformance
(thank you very sincerely, Jacob, I am one of your biggest fans), and
Comeau's front end for various back ends, there does seem to be some
promise from a major Windows compiler vendor, namely Borland.

Their recently announced cross-platform C++ BuilderX is supposed to
eventually come with a brand new optimizing compiler with top priority
given to full ISO C++ and C99 conformance, although the C99 is far
less mentioned on their web site than C++.

The real issue, as Microsoft puts it, is putting their priority, and
development effort, on what the majority of their customers want.
There are very few "small" Windows applications anymore, and C is not
the primary language of choice for large GUI applications in desktop
environments these days.

The major stronghold of C today is in embedded systems, where in the
last 10 to 15 years it has totally outstripped hand coded assembly
language.

The vast majority of embedded systems coded in C are implemented with
smaller 8 or 16 bit microprocessors and microcontrollers. These
people do not want or need many of the new C99 features, such as
variable length arrays or the long long data type. In fact although
all of these compilers call themselves "ANSI C", it usually means that
they allow function prototypes. Many don't implement floating point
at all or provide nothing wider than a 32-bit IEEE single precision
type, so they are not even conforming free-standing implementations.

There is some hope on the higher end 32-bit systems. Several
compilers were adding C99 features. Although I am a few versions and
a few years behind the latest, CodeWarrior and ARM's compilers were
adding C99 features steadily with each release the last time I looked.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq

[Ben Pfaff]

"Serve La" <[e-mail]> writes:

I asked if MS has any plans to support C99 in the next VisualC.

I had the regrettable need to use MSVC, briefly, today. One line
of code evoked this error, or something to the same effect:
x.c:200: conversion from `unsigned long long' to `double'
not implemented (use `long long' instead)
Sheesh. Talk about half-efforts.

[Randy Howard]

In article <u9********************************@4ax.com>,
ir*****************@freenet.de says...

Surprised, anyone? This is not to start flame war, but IMHO people
using braindead M$VC for compiling C code are, err..., well..., nah,
I'm not going to insult someone for using a specific product.

Irrwahn

( using gcc, yet another product of the Sirius Cybernetics Corp. ;] )

Anyone read the latest DDJ, particularly the article on C and C++ compiler
performance? gcc gets it's proverbial butt handed to it in terms of
compile time, run-time performance and code size as compared to 8 or 9
other compilers, including that evil one from MS.

I'm not saying it's not a great product if you're really into writing code
for a ton of obscure platforms (as I seem to be doing more and more
lately), but ...

--
Randy Howard _o
2reply remove FOOBAR \<,
______________________()/ ()______________________________________________
SCO Spam-magnet: po********@sco.com

[LibraryUser]

Allin Cottrell wrote:

.... snip ...
Yes, well, gcc is not in any hurry to comply with C99 either. I'm
as ready as the next person to blast MS, but in this case the target
seems wrong. Rather, it seems that the C standards group came up
with something that just has not caught on. To date (4 years after
the standard was promulgated), the only C compiler vendors claiming
full C99 compliance are (no offence intended) marginal to the
market. Why should MS devote a lot of expense to something that
few programmers really seem to want? Why should the gcc authors?

However gcc is making steady progress towards C99 compliance.
This is definitely an aim. The salary levels for gcc programmers
may have a negative effect on the rapidity of that progress,
inasmuch as volunteerism is not usually as financially rewarding
as heading Enron, WorldCom, the NYSE, or having pals in that
white house.

--
Replies should be to the newsgroup
Chuck Falconer, on vacation.

[jacob navia]

Yes, this bug is since quite a long time.

The problem is that to do this conversion you cannot use the x86, since the
only 64 bit integer conversion in the x86 is signed. Unsigned long long means
that a quite long sequence of machine instructions must be emitted.

"Ben Pfaff" <bl*@cs.stanford.edu> wrote in message news:87************@pfaff.stanford.edu...

"Serve La" <[e-mail]> writes:

I asked if MS has any plans to support C99 in the next VisualC.

I had the regrettable need to use MSVC, briefly, today. One line
of code evoked this error, or something to the same effect:
x.c:200: conversion from `unsigned long long' to `double'
not implemented (use `long long' instead)
Sheesh. Talk about half-efforts.

[Serve Laurijssen]

"Jack Klein" <ja*******@spamcop.net> wrote in message
news:kn********************************@4ax.com...

Their recently announced cross-platform C++ BuilderX is supposed to
eventually come with a brand new optimizing compiler with top priority
given to full ISO C++ and C99 conformance, although the C99 is far
less mentioned on their web site than C++.

Yes, what's up with BuilderX? I've read the marketing story, but I'm still
not sure whether they've included a compiler. It seems to me it's a cross
platform IDE in which you can plug other compilers/debuggers. So they will
be including a newer C++/C99 compiler in the future?

[Dan Pop]

In <3F***************@made.invalid> LibraryUser <de**********@made.invalid> writes:

Allin Cottrell wrote:

... snip ...

Yes, well, gcc is not in any hurry to comply with C99 either. I'm
as ready as the next person to blast MS, but in this case the target
seems wrong. Rather, it seems that the C standards group came up
with something that just has not caught on. To date (4 years after
the standard was promulgated), the only C compiler vendors claiming
full C99 compliance are (no offence intended) marginal to the
market. Why should MS devote a lot of expense to something that
few programmers really seem to want? Why should the gcc authors?

However gcc is making steady progress towards C99 compliance.

What "steady progress" are you talking about? I haven't noticed any
changes in http://gcc.gnu.org/c99status.html for the last couple of
years...

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Mike Wahler]

"jacob navia" <ja*********@jacob.remcomp.fr> wrote in message
news:bk**********@news-reader1.wanadoo.fr...

Yes, this bug is since quite a long time.

The problem is that to do this conversion you cannot use the x86, since the only 64 bit integer conversion in the x86 is signed. Unsigned long long means that a quite long sequence of machine instructions must be emitted.

In which case I'd have gone ahead and emitted them,
and given a performance warning.

-Mike

[Serve La]

"Richard Heathfield" <do******@address.co.uk.invalid> wrote in message
news:bk**********@titan.btinternet.com...

I asked if MS has any plans to support C99 in the next VisualC. This is
their answer.
I think we should whine more :-)

Or vote with your feet.

<snip>

They have planned "restrict" BTW, the one feature I like the least.

C'est la vie. You don't /have/ to use Visual C, though. There are other
compilers for the Windows platform.

First, I wish I had the luxury of choosing a compiler.
Second, when somebody writes void main everybody starts shouting that it's
not portable. Following this logic, when some compiler refuses to implement
C99 it makes all those C99 features not portable. Isn't that a bit strange?

[Richard Heathfield]

Serve La wrote:

<snip>

Second, when somebody writes void main everybody starts shouting that it's
not portable. Following this logic, when some compiler refuses to
implement C99 it makes all those C99 features not portable. Isn't that a
bit strange?

Strictly conforming code written to C99 rules is portable to all conforming
C99 compilers, of which the number appears (slowly) to be increasing. The
same cannot be said for void main.

--
Richard Heathfield : bi****@eton.powernet.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

[Severian]

On Tue, 23 Sep 2003 15:38:31 +0200, "jacob navia"
<ja*********@jacob.remcomp.fr> wrote:

"Ben Pfaff" <bl*@cs.stanford.edu> wrote in message news:87************@pfaff.stanford.edu...

"Serve La" <[e-mail]> writes:

> I asked if MS has any plans to support C99 in the next VisualC.

I had the regrettable need to use MSVC, briefly, today. One line
of code evoked this error, or something to the same effect:
x.c:200: conversion from `unsigned long long' to `double'
not implemented (use `long long' instead)
Sheesh. Talk about half-efforts.

Yes, this bug is since quite a long time.

The problem is that to do this conversion you cannot use the x86, since the
only 64 bit integer conversion in the x86 is signed. Unsigned long long means
that a quite long sequence of machine instructions must be emitted.

On the x86, doesn't a long long have more digits of precision than a
double? If so, doesn't this do the trick, at least on the X86?

unsigned long long v;
double d;

if (v <= LONGLONG_MAX)
d = (double)(long long)v;
else if (v < ULONGLONG_MAX)
d = ((double)(long long)((v+1)>>1)) * 2.0;
else
d = 18446744073709551615.0; /* X86 64-bit ULL */
}

(I don't know about the _MAX constants; I left my copy of the standard
at home today.)

Does this really require "a lot" of X86 instructions? It seems to me
that the first condition will be true in most circumstances, so the
performance penalty wouldn't be that great regardless.

- Sev
--
I am just a thought of mine, an egotisticality. (P. Crews)

[Serve La]

"Richard Heathfield" <do******@address.co.uk.invalid> wrote in message
news:bk**********@titan.btinternet.com...

Serve La wrote:

<snip>

Second, when somebody writes void main everybody starts shouting that it's not portable. Following this logic, when some compiler refuses to
implement C99 it makes all those C99 features not portable. Isn't that a
bit strange?
Strictly conforming code written to C99 rules is portable to all

conforming C99 compilers, of which the number appears (slowly) to be increasing. The
same cannot be said for void main.

Talking about numbers, there's far more compilers in use that support void
main than there are C99 compilers.
Since VC is the most used compiler in the world, not being able to program
C99 in VC means that void main is more portable than C99.

[jacob navia]

Here is what lcc-win32 generates:
; long double ld = ull; // This is the C code. ull is unsigned long long
; First, load the 64 bit integer into the eax:edx register pair
movl -4(%ebp),%edx
movl -8(%ebp),%eax
; Load 32 into the FPU. This will be used when scaling the long double later
pushl $32
fildl (%esp)
; Clear this memory location, since we are going to use it later
movl $0,(%esp)
; push the bits 32-63 of the unsigned long long
pushl %edx
;; load the bits 32-63 into the FPU
fildq (%esp)
; scale it by 2^32. This is why we loaded the 32 above
fscale
; put the bits 0-31 in memory
movl %eax,(%esp)
; load it into the FPU
fildq (%esp)
; add low and high parts
faddp
; adjust the stack
addl $8,%esp

This leaves the 64 bit number in the FPU.

Microsoft doesn't do this, because an optimizing compiler doesn't emit operations
that are too long :-)

jacob

[Andreas Kahari]

In article <bk**********@news3.tilbu1.nb.home.nl>, Serve La wrote:
[cut]

Talking about numbers, there's far more compilers in use that support void
main than there are C99 compilers.
A compiler is perfectly welcome to compile non-conforming
code into something that is executable and that does what the
programmer expects it to do. It is, however, not required to do
so.
Since VC is the most used compiler in the world, not being able to program
C99 in VC means that void main is more portable than C99.

So VC (whatever that is) doesn't support "int main(void) { ... }"?

--
Andreas Kähäri

[Default User]

Serve La wrote:

Second, when somebody writes void main everybody starts shouting that it's
not portable. Following this logic, when some compiler refuses to implement
C99 it makes all those C99 features not portable. Isn't that a bit strange?

Please explain your reasoning. There are compilers that didn't implement
the previous standard either, are you saying that was nonportable?
You are missing the point that extensions, by their very nature, are
outside of the standard. There is no requirement for compilers that do
implement the standard to include them, so they are nonportable.


Brian Rodenborn

[Severian]

On Tue, 23 Sep 2003 21:41:46 +0200, "Serve La" <[e-mail]>
wrote:

"Richard Heathfield" <do******@address.co.uk.invalid> wrote in message
news:bk**********@titan.btinternet.com...

Serve La wrote:

<snip>

> Second, when somebody writes void main everybody starts shouting thatit's > not portable. Following this logic, when some compiler refuses to
> implement C99 it makes all those C99 features not portable. Isn't that a
> bit strange?

Strictly conforming code written to C99 rules is portable to all

conforming

C99 compilers, of which the number appears (slowly) to be increasing. The
same cannot be said for void main.

Talking about numbers, there's far more compilers in use that support void
main than there are C99 compilers.
Since VC is the most used compiler in the world, not being able to program
C99 in VC means that void main is more portable than C99.

No matter what compilers let you do it, void main() is still STUPID
and looks especially ignorant on a newsgroup for discussing standard
C.

Even Microsoft says it should return int, to wit:

A special function called main is the starting point of
execution for all C and C++ programs. If you are writing
code that adheres to the Unicode programming model, you
can use the wide-character version of main, wmain.

The main function is not predefined by the compiler;
rather, it must be supplied in the program text.

The declaration syntax for main is:

int main( );

or, optionally:

int main( int argc[ , char *argv[ ] [, char *envp[ ] ] ] );

- Sev
--
I am just a thought of mine, an egotisticality. (P. Crews)

[jacob navia]

"Dan Pop" <Da*****@cern.ch> wrote in message news:bk**********@sunnews.cern.ch...

In <3F***************@made.invalid> LibraryUser <de**********@made.invalid> writes:
What "steady progress" are you talking about? I haven't noticed any
changes in http://gcc.gnu.org/c99status.html for the last couple of
years...

Well, they have done complex arithmetic. I am debugging my implementation of
complex arithmetic using gcc.

That's a really difficult stuff to do. I can tell you Dan, with 3 different complex
numbers (in float/double/long double varieties), 3 types of floating point
numbers, and 3 kinds of integers to interchange, well done numeric C99 is quite
difficult.

jacob

[Keith Thompson]

[top-posting fixed]
"jacob navia" <ja*********@jacob.remcomp.fr> writes:

"Ben Pfaff" <bl*@cs.stanford.edu> wrote in message
news:87************@pfaff.stanford.edu...

[...]

I had the regrettable need to use MSVC, briefly, today. One line
of code evoked this error, or something to the same effect:
x.c:200: conversion from `unsigned long long' to `double'
not implemented (use `long long' instead)
Sheesh. Talk about half-efforts.

Yes, this bug is since quite a long time.

The problem is that to do this conversion you cannot use the x86, since the
only 64 bit integer conversion in the x86 is signed. Unsigned long long means
that a quite long sequence of machine instructions must be emitted.

I just tried a compiling a small test program on an x86 system with
gcc. Converting from signed long long to double seems to require 2
instructions; converting from unsigned long long to double takes 10,
including a comparison and conditional branch.

The point, though, is that gcc generates the code to do this. It's a
compiler; that's its job. If MSVC (which I've never used) doesn't do
this, that's a bug. (The suggestion to "use `long long' instead" is
particularly silly; perhaps it should say "use `gcc' instead".)

--
Keith Thompson (The_Other_Keith) ks*@cts.com <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

[Severian]

On Tue, 23 Sep 2003 21:47:31 +0200, "jacob navia"
<ja*********@jacob.remcomp.fr> wrote:

Here is what lcc-win32 generates:
; long double ld = ull; // This is the C code. ull is unsigned long long
; First, load the 64 bit integer into the eax:edx register pair
movl -4(%ebp),%edx
movl -8(%ebp),%eax
; Load 32 into the FPU. This will be used when scaling the long double later
pushl $32
fildl (%esp)
; Clear this memory location, since we are going to use it later
movl $0,(%esp)
; push the bits 32-63 of the unsigned long long
pushl %edx
;; load the bits 32-63 into the FPU
fildq (%esp)
; scale it by 2^32. This is why we loaded the 32 above
fscale
; put the bits 0-31 in memory
movl %eax,(%esp)
; load it into the FPU
fildq (%esp)
; add low and high parts
faddp
; adjust the stack
addl $8,%esp

This leaves the 64 bit number in the FPU.

Microsoft doesn't do this, because an optimizing compiler doesn't emit operations
that are too long :-)

Wouldn't it be more efficient to check the high bit and use the
quicker signed conversion if the 64-bit ULL can be represented as a
LL?

- Sev

--
I am just a thought of mine, an egotisticality. (P. Crews)

[Simon Josefsson]

Richard Heathfield <do******@address.co.uk.invalid> writes:

Serve La wrote:

<snip>

Second, when somebody writes void main everybody starts shouting that it's
not portable. Following this logic, when some compiler refuses to
implement C99 it makes all those C99 features not portable. Isn't that a
bit strange?

Strictly conforming code written to C99 rules is portable to all conforming
C99 compilers, of which the number appears (slowly) to be increasing. The
same cannot be said for void main.

Are there any C99 to C89 translators around? Is it possible to write
one? Compare with the C89 to K&R translators that was popular once.

[Default User]

Serve La wrote:

Talking about numbers, there's far more compilers in use that support void
main than there are C99 compilers.
So what?
Since VC is the most used compiler in the world, not being able to program
C99 in VC means that void main is more portable than C99.

How does that make int main() less portable?

You seem to have real problems (to paraphrase Dan Pop) engaging your
brain.

Brian Rodenborn

[Richard Heathfield]

Serve La wrote:

"Richard Heathfield" <do******@address.co.uk.invalid> wrote in message
news:bk**********@titan.btinternet.com...

Strictly conforming code written to C99 rules is portable to all
conforming C99 compilers, of which the number appears (slowly)
to be increasing. The same cannot be said for void main.
Talking about numbers, there's far more compilers in use that support void
main than there are C99 compilers.

I know of only one C compiler that documents support for void main. Most of
my compilers do not support it, and at least two of them actively diagnose
it as being incorrect, when invoked in conforming mode.
Since VC is the most used compiler in the world, not being able to program
C99 in VC means that void main is more portable than C99.

By the same argument, the Windows API is more portable than C99. And yet,
50% of the computers here in my study don't have Windows API support. All
of these (four) machines, however, can run gcc, which is on its way to C99
support, and one of them actually has a full C99 (Comeau/Dinkumware)
implementation. So, from my point of view, C99 is much more portable than
void main. As for the world, well, last I heard, it was going to hell in a
handbasket.

--
Richard Heathfield : bi****@eton.powernet.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

[jacob navia]

"Severian" <se******@chlamydia-is-not-a-flower.com> wrote in message
news:fb********************************@4ax.com...

On Tue, 23 Sep 2003 21:47:31 +0200, "jacob navia"
<ja*********@jacob.remcomp.fr> wrote: Wouldn't it be more efficient to check the high bit and use the
quicker signed conversion if the 64-bit ULL can be represented as a
LL?

Interesting. I do not know if it would be faster but if I add a
test $0x80000000,address+4
jne label
fildq address
jmp label+1
label:
; do the hard conversion here
label+1:

The forward jump would be consistently predicted as not taken, so it would not
take a lot of time, and then the jumps are always correctly predicted... so this
would not disturb the pipeline.

It does add 4 instructions and a 32 bit constant to the code. But this
conversions are not that common, so your idea is a good one.

jacob

[Ben Pfaff]

"jacob navia" <ja*********@jacob.remcomp.fr> writes:

Interesting. I do not know if it would be faster but if I add a
test $0x80000000,address+4 It does add 4 instructions and a 32 bit constant to the code.

Use an 8-bit constant instead:
test $0x80,address+7
--
"When I have to rely on inadequacy, I prefer it to be my own."
--Richard Heathfield

[Keith Thompson]

"Serve La" <[e-mail]> writes:
[...]

Talking about numbers, there's far more compilers in use that support void
main than there are C99 compilers.
Since VC is the most used compiler in the world, not being able to program
C99 in VC means that void main is more portable than C99.

That's probably true, but it's not particularly interesting. There's
no excuse for using void main(). Change the "void" to "int" and add a
"return 0;" at the end; your program is more portable, and the
denizens of comp.lang.c will stop yelling at you.

--
Keith Thompson (The_Other_Keith) ks*@cts.com <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

[lawrence.jones]

Severian <se******@chlamydia-is-not-a-flower.com> wrote:

Wouldn't it be more efficient to check the high bit and use the
quicker signed conversion if the 64-bit ULL can be represented as a
LL?

It would be simpler to just do the signed conversion in any case and
then fixup the result, if necessary, by adding ULLONG_MAX+1.0.

-Larry Jones

This game lends itself to certain abuses. -- Calvin

[Micah Cowan]

Simon Josefsson <ja*@extundo.com> writes:

Richard Heathfield <do******@address.co.uk.invalid> writes:

Serve La wrote:

<snip>

Second, when somebody writes void main everybody starts shouting that it's
not portable. Following this logic, when some compiler refuses to
implement C99 it makes all those C99 features not portable. Isn't that a
bit strange?

Strictly conforming code written to C99 rules is portable to all conforming
C99 compilers, of which the number appears (slowly) to be increasing. The
same cannot be said for void main.

Are there any C99 to C89 translators around? Is it possible to write
one? Compare with the C89 to K&R translators that was popular once.

It's my understanding that this is what the Comeau C99 compiler does.

www.comeaucomputing.com

-Micah

[Serve Laurijssen]

"Keith Thompson" <ks*@cts.com> wrote in message
news:lz************@cts.com...

That's probably true, but it's not particularly interesting. There's
no excuse for using void main(). Change the "void" to "int" and add a
"return 0;" at the end; your program is more portable, and the
denizens of comp.lang.c will stop yelling at you.

Another case of usenet incomprehension.
I don't want to discuss void main, I agree with that of course. (and it's
been beaten to death already)
But when Richard Heathfield told me to "vote with my feet" I started
thinking that the same could be said for features that are implemented on
your implementation but not on others. Just don't use these other
implementations.
But then why is the emphasize in clc on portability?

[Severian]

On Wed, 24 Sep 2003 02:41:10 GMT, la************@eds.com wrote:

Severian <se******@chlamydia-is-not-a-flower.com> wrote:

Wouldn't it be more efficient to check the high bit and use the
quicker signed conversion if the 64-bit ULL can be represented as a
LL?

It would be simpler to just do the signed conversion in any case and
then fixup the result, if necessary, by adding ULLONG_MAX+1.0.

Quite so, and shorter and quicker, too!

- Sev
--
I am just a thought of mine, an egotisticality. (P. Crews)

[Randy Howard]

In article <bk**********@news3.tilbu1.nb.home.nl>, [e-mail]
says...

Since VC is the most used compiler in the world,

Is it really the most used? I would probably suspect either
gcc (across a host of different platforms) or perhaps some
other 8051 specific compiler to the winner there. Last I
checked, there are far, far more 8051 embedded devices in
active use on the planet than there are Wintel boxes.

--
Randy Howard _o
2reply remove FOOBAR \<,
______________________()/ ()______________________________________________
SCO Spam-magnet: po********@sco.com

[Randy Howard]

In article <wUacb.51396$tK5.5971716@zonnet-reader-1>, [e-mail]
says...

But when Richard Heathfield told me to "vote with my feet" I started
thinking that the same could be said for features that are implemented on
your implementation but not on others.
If you are writing code that *must* do something that is outside of the
standard for C, then you must abandon the project, or develop platform
dependent code. Of course, if you are careful you can isolate those
bits so that 95%+ of the remaining program is still within the
"sandbox" so to speak.

That doesn't mean that if a compiler supports doing something wrong,
AND supports doing it correctly, that you should do it the wrong
way just because you can get away with it. Similarly, if more
than one compiler is available, one of which lets you write code
portably to achieve you objectives while another does not, why on
earth (apart from management BS) would you have to use the latter?
But then why is the emphasize in clc on portability?

Because there are numerous platform-specific newsgroups that help people
with the non-portable bits. In each of those, the audience is
specifically attuned to a particular platform and you are much more likely
to get an accurate answer. A group where people from a LOT of different
platforms hang out answer such a question, you're likely to get more
than a few wrong answers, or miss getting a correct answer at all.

So, if you know that asking a platform-dependent question about pthreads
programming is 5% likely to get a good answer in c.l.c, and 95% likely to
get you a flame and a pointer to the FAQ, whereas posting the same
question to comp.programming.threads is going to have inverse statistics
to those, why would you bother to worry about it in this newsgroup?

--
Randy Howard _o
2reply remove FOOBAR \<,
______________________()/ ()______________________________________________
SCO Spam-magnet: po********@sco.com

[Dan Pop]

In <m3************@localhost.localdomain> Micah Cowan <mi***@cowan.name> writes:

Simon Josefsson <ja*@extundo.com> writes:

Richard Heathfield <do******@address.co.uk.invalid> writes:

> Serve La wrote:
>
> <snip>
>
>> Second, when somebody writes void main everybody starts shouting that it's
>> not portable. Following this logic, when some compiler refuses to
>> implement C99 it makes all those C99 features not portable. Isn't that a
>> bit strange?
>
> Strictly conforming code written to C99 rules is portable to all conforming
> C99 compilers, of which the number appears (slowly) to be increasing. The
> same cannot be said for void main.
Are there any C99 to C89 translators around? Is it possible to write
one?

Nope: certain C99 features cannot be implemented in portable C89 code.
Compare with the C89 to K&R translators that was popular once.

It's my understanding that this is what the Comeau C99 compiler does.

Nope: it converts C99 code to C89 code + platform specific extensions.
Therefore, it works only for the supported C89 compilers.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Dan Pop]

In <bk**********@news-reader1.wanadoo.fr> "jacob navia" <ja*********@jacob.remcomp.fr> writes:

"Dan Pop" <Da*****@cern.ch> wrote in message news:bk**********@sunnews.cern.ch...

In <3F***************@made.invalid> LibraryUser <de**********@made.invalid> writes:
What "steady progress" are you talking about? I haven't noticed any
changes in http://gcc.gnu.org/c99status.html for the last couple of
years...

Well, they have done complex arithmetic. I am debugging my implementation of
complex arithmetic using gcc.

They already had complex arithmetic, because it was a GNU C feature long
before C99.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Kevin Easton]

jacob navia <ja*********@jacob.remcomp.fr> wrote:
[...top posting fixed...]

"Ben Pfaff" <bl*@cs.stanford.edu> wrote in message news:87************@pfaff.stanford.edu...

"Serve La" <[e-mail]> writes:

> I asked if MS has any plans to support C99 in the next VisualC.

I had the regrettable need to use MSVC, briefly, today. One line
of code evoked this error, or something to the same effect:
x.c:200: conversion from `unsigned long long' to `double'
not implemented (use `long long' instead)
Sheesh. Talk about half-efforts.

Yes, this bug is since quite a long time.

The problem is that to do this conversion you cannot use the x86, since the
only 64 bit integer conversion in the x86 is signed. Unsigned long long means
that a quite long sequence of machine instructions must be emitted.

Really? Can't you just mask out the highest bit, use the signed conversion
to convert the lower 63 bits, then if the highest bit was set add a
floating point constant to the result?

- Kevin.

[Kevin Easton]

Randy Howard <ra**********@foomegapathdslbar.net> wrote:

In article <u9********************************@4ax.com>,
ir*****************@freenet.de says...

Surprised, anyone? This is not to start flame war, but IMHO people
using braindead M$VC for compiling C code are, err..., well..., nah,
I'm not going to insult someone for using a specific product.

Irrwahn

( using gcc, yet another product of the Sirius Cybernetics Corp. ;] )

Anyone read the latest DDJ, particularly the article on C and C++ compiler
performance? gcc gets it's proverbial butt handed to it in terms of
compile time, run-time performance and code size as compared to 8 or 9
other compilers, including that evil one from MS.

I'm not saying it's not a great product if you're really into writing code
for a ton of obscure platforms (as I seem to be doing more and more
lately), but ...

That's quite well known already. GCC's design is based around
portability, and some design decisions to improve this (particularly the
split between front end and back end portions) rule out some kinds of
optimisations. There's also other optimisations that can't be included
because they're patented.

- Kevin.

[Jarno A Wuolijoki]

On Wed, 24 Sep 2003, Kevin Easton wrote:

x.c:200: conversion from `unsigned long long' to `double'
not implemented (use `long long' instead)

The problem is that to do this conversion you cannot use the x86, since the
only 64 bit integer conversion in the x86 is signed. Unsigned long long means
that a quite long sequence of machine instructions must be emitted.

Really? Can't you just mask out the highest bit, use the signed conversion
to convert the lower 63 bits, then if the highest bit was set add a
floating point constant to the result?

#if LDBL_MANT_DIG>63
Add 2^63, load signed, add 2^63.
#endif

[lawrence.jones]

Randy Howard <ra**********@foomegapathdslbar.net> wrote:

Is it really the most used? I would probably suspect either
gcc (across a host of different platforms) or perhaps some
other 8051 specific compiler to the winner there.

One of the things we discovered working on the original C standard was
that nearly every C programmer believes that the implementation they use
is clearly the one that most people use. :-)

-Larry Jones

Why can't I ever build character in a Miami condo or a casino somewhere?
-- Calvin

[lawrence.jones]

Randy Howard <ra**********@foomegapathdslbar.net> wrote:

Is it really the most used? I would probably suspect either
gcc (across a host of different platforms) or perhaps some
other 8051 specific compiler to the winner there.

One of the things we discovered working on the original C standard was
that nearly every C programmer believes that the implementation they use
is clearly the one that most people use. :-)

-Larry Jones

Why can't I ever build character in a Miami condo or a casino somewhere?
-- Calvin

[Richard Heathfield]

Serve Laurijssen wrote:

But when Richard Heathfield told me to "vote with my feet" I started
thinking that the same could be said for features that are implemented on
your implementation but not on others. Just don't use these other
implementations.
That's right. As long as at least one C99 implementation exists for the
target platform, portability of C99 code to that platform is not an issue,
even if some vendors are slow to support C99. So, if VC doesn't conform,
find a compiler that does, and use that instead.
But then why is the emphasize in clc on portability?

See above. As far as I'm concerned, it's our job to write portable code, and
the compiler vendor's job to provide conforming compilers. If the vendor
can't manage it, then buy from someone who can. Or use a free conforming
compiler if you wish and if one exists.

The inability of Microsoft to produce a C99 compiler is not a good reason
not to embrace the current C standard. (There may well /be/ good reasons,
but that isn't one of them.)

--
Richard Heathfield : bi****@eton.powernet.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

[Richard Heathfield]

Serve Laurijssen wrote:

But when Richard Heathfield told me to "vote with my feet" I started
thinking that the same could be said for features that are implemented on
your implementation but not on others. Just don't use these other
implementations.
That's right. As long as at least one C99 implementation exists for the
target platform, portability of C99 code to that platform is not an issue,
even if some vendors are slow to support C99. So, if VC doesn't conform,
find a compiler that does, and use that instead.
But then why is the emphasize in clc on portability?

See above. As far as I'm concerned, it's our job to write portable code, and
the compiler vendor's job to provide conforming compilers. If the vendor
can't manage it, then buy from someone who can. Or use a free conforming
compiler if you wish and if one exists.

The inability of Microsoft to produce a C99 compiler is not a good reason
not to embrace the current C standard. (There may well /be/ good reasons,
but that isn't one of them.)

--
Richard Heathfield : bi****@eton.powernet.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

[Dan Pop]

In <bk**********@titan.btinternet.com> Richard Heathfield <do******@address.co.uk.invalid> writes:

That's right. As long as at least one C99 implementation exists for the
target platform, portability of C99 code to that platform is not an issue,
even if some vendors are slow to support C99. So, if VC doesn't conform,
find a compiler that does, and use that instead.

Things are more complex than that, in real life. What if VC generates
much better object code, has much better diagnostics and debugging
facilities? Wouldn't it be sheer foolishness to ignore all these
advantages for the sake of being able to use the few bells and whistles
added by C99?

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[lawrence.jones]

Dan Pop <Da*****@cern.ch> wrote:

Things are more complex than that, in real life. What if VC generates
much better object code, has much better diagnostics and debugging
facilities? Wouldn't it be sheer foolishness to ignore all these
advantages for the sake of being able to use the few bells and whistles
added by C99?

That depends on how important said "bells and whistles" are to you.
After all, if you're working on a railroad, bells and whistles are
*very* important.

-Larry Jones

They can make me do it, but they can't make me do it with dignity. -- Calvin