C99 IDE for windows

[santosh]

(e-mail address removed) said:


I don't see why it's advantageous to postpone until runtime a
calculation that can be performed trivially at compilation time.

Would it be as trivial for, say, a long double? I have had cases where
the same long double object produced an output of several lines of
digits for some values and just a few digits for others. Is there a
deterministic formula for doing this at compile-time based only on the
information derivable from float.h?

Ah, I think I understand what you thought I meant. You seem to think
that (given a C99 implementation to work with) I'm offering you three
choices:

(1a) snprintf twice
(1b) snprintf once
(1c) sprintf once

I wasn't. I was offering you *two* choices:

(2a) snprintf twice
(2b) snprintf once (to get the size), followed by buffer provision,
followed by sprintf

It is my contention that (2b) is superior to (2a).

How? 2b isn't any more portable than 2a, and it *might* be
infinitesimally faster. No data loss occurs in either case. So why is
2b superior to 2a?

It is my further contention that (2b) is not optimal, but we've
already had that fight, right?

Agreed.

 

[arnuld]

The maximum number of decimal digits an int can represent, plus one for
the sign and one for the null terminator.

sizeof(int) on my machine is 4 and I tried your expression 4 times:


printf( "max_of_int = %d\n", ( (sizeof(int)* CHAR_BIT) +2 / 3 + 2 ));
printf( "max_of_int = %d\n", ( ((sizeof(int)* CHAR_BIT)) + (2 / 3) + 2) );
printf( "max_of_int = %d\n", ( ( ((sizeof(int)* CHAR_BIT) +2) / 3) + 2) );
printf( "max_of_int = %d\n", ( ((sizeof(int)* CHAR_BIT) +2) / (3 + 2) ));


so, 1st printf() is yours and the only match is second. I will takeit
part by part:

sizeof(int)*CHAR_BIT

why are you multiplying the "size of an int" with "how many bits
in a char" ?

2/3 , it gives what, i mean why it is there ?

+ 2 - okay, one for null character and one for sign

It's possible, yes. For example, if CHAR_BIT is 33 (i.e. there are 33
bits in a byte)

and what normal desktop machine have that value, Intel Dual Core, AMD
Athlon 64 3000+ ?

with no padding bits and one sign
bit, we have 164 value bits (and 1 sign bit), so INT_MAX is a
fifty-digit number (in fact it's
23384026197294446691258957323460528314494920687615), and my expression
(excluding provision for the sign byte and the null byte) yields 166 / 3
= 55, so a massive five bytes are wasted.

Feel free to devise a better algorithm, bearing in mind that you can't
take logs or do anything else that involves runtime evaluation (because
otherwise it won't be a constant integer expression and therefore it
won't be suitable for sizing a C90 array).

Irrelevant, since it is always sufficient.

hahahaha... It feels like 2 aliens are talking to each other in some
mysterious language...

I did not laugh because of two aliens. Laughing part is "I am paid to
write C Code" when I can't understand your conversation..

and I call myself a Programmer... huh...

 

[s0suk3]

(e-mail address removed) said:



Much of my code is deployed as source. My users can use any conforming C
compiler they like; whether it's C90- or C99-conforming is of no
consequence.


They haven't got one.


Well, as long as you know.


Pull the ladder up, Jack!



I don't see why it's advantageous to postpone until runtime a calculation
that can be performed trivially at compilation time. There are
circumstances where it is advantageous to use malloc, but I don't see this
as one of them.




Assuming you have snprintf, you get that assurance even if you call it once
and then follow up with a call to sprintf.


No, you get the right size with your first call...


...you use a buffer of that right size to hand to sprintf.


Ah, I think I understand what you thought I meant. You seem to think that
(given a C99 implementation to work with) I'm offering you three choices:

(1a) snprintf twice
(1b) snprintf once
(1c) sprintf once

I wasn't. I was offering you *two* choices:

(2a) snprintf twice
(2b) snprintf once (to get the size), followed by buffer provision,
followed by sprintf

I see. But if you call snprintf() first to tell you the size, it's
completely irrelevant whether in the second call you use sprintf() or
snprintf(); it's merely a matter of implicitness or explicitness.
(Small exception: as CBFalconer mentioned, if, for some reason, the
value to be converted might change between the two calls, being
explicit about the size and using snprintf() for the second call would
be safer.)

<snip>

Sebastian

 

[CBFalconer]

santosh said:

It's infinitesimally faster - or at least it might be! But more to
the point, it's less to type, so less to get wrong.

Possibly. However, it probably significantly increases the amount
of code loaded from the library. This may significantly increase
the runtime module size, assuming static library. Two functions
are normally bigger than one.

 

[Kenny McCormack]

Oh come on now. Gnu has relatively minor failures in C99
compliance. Admittedly it isn't all the way there, but you only
need one compiler.

It looks very much like someone has hacked CBF's account. This does not
sound at all like the CBF we all knew.

Anyway, the dogma of the group (certain that of RH) is "all or its crap".
If you can find one little thing to nit-pick about, then the
implementation is crap.

Besides that, is the fact that the dogma of the group has also always been
that the compilers listed above (namely, Microsoft [i.e., Windows], gcc
[i.e., Linux] and Borland [i.e., DOS/Windows]) represent a miniscule and
essentially irrelevant part of the C world. That the "big money" is in
embedded systems (not hosted) and that what really matters is all the
(unnamed) compilers for embedded systems (that we never hear about on
this group - funny, that)

 

[santosh]

CBFalconer said:

<snip>

In this call:

int ret = 0;
int n = 0;
ret = fprintf(temp_file, "%p%n", (void*)ptr, n);

If an output error occurred after the 'p' specifier had been processed,
n will still contain the number of characters written out, while ret
will contain a negative value.

But I think this is not likely at all.

 

[Keith Thompson]

Oh come on now. Gnu has relatively minor failures in C99
compliance. Admittedly it isn't all the way there, but you only
need one compiler.

No, if you need to produce code that will run on multiple systems, you
may need multiple compilers. And if you're distributing source code,
you need to ensure that the code will be compatible with your users'
compilers, which you might not have access to.

Given the current state of the market, the best way to ensure that is
to restrict yourself to the intersection of C90 and C99. If you use,
say, gcc for your own system, you can take advantage of the features
that gcc offers -- but what if your users want to compile your code on
a system that doesn't have gcc? Or what if they want to use a
different compiler because it generates faster code for their system
than gcc does?

 

[santosh]

CBFalconer <[email protected]> writes:

[ ... ]

No, if you need to produce code that will run on multiple systems, you
may need multiple compilers. And if you're distributing source code,
you need to ensure that the code will be compatible with your users'
compilers, which you might not have access to.

Given the current state of the market, the best way to ensure that is
to restrict yourself to the intersection of C90 and C99.

Which is more or less C90.

<snip>

 

[Antoninus Twink]

First off, a conforming implementation could, for example, say that
the "%p" conversion yields a random number of underscores followed by
the pointer representation in hexadecimal. *scanf would just ignore
the underscores. This would be a silly implementation, but I believe
it would be conforming.

It is absolutely astonishing that two grown-up people can conduct a
conversation about nonsense like this, apparently in all seriousness.

 

[Keith Thompson]

CBFalconer <[email protected]> writes:

[ ... ]

No, if you need to produce code that will run on multiple systems, you
may need multiple compilers. And if you're distributing source code,
you need to ensure that the code will be compatible with your users'
compilers, which you might not have access to.

Given the current state of the market, the best way to ensure that is
to restrict yourself to the intersection of C90 and C99.

Which is more or less C90.

Right. To quantify the "more or less", you have to avoid implicit int
and using any of the new C99 keywords (inline, restrict, are there
others?) as identifiers, and probably a few other things I haven't
thought of.

More generally, you have to avoid anything that conflicts with C99.
For example, writing your own "bool.h" or "complex.h" header would be
a bad idea.

Note that C99 keywords like _Bool aren't an issue, since you can't
portably use them in C90 anyway.

 

[CBFalconer]

CBFalconer said:

Which you can get from the return value anyway. How does %n
improve matters? (Third time of asking.)

Didn't realize, in the heat of the news replying, that I could just
use the *printf returned value. I have even been known to use it.
Then the only useful idea in that particular set is using the
(occasionally available) null device. And the only real purpose of
%n is to take length measurements in the middle of the *printf
call.

 

[arnuld]

That's equivalent to mine.
okay



To get the number of bits in an int.

so, my machine has 32 bytes in an int

No idea. That's your invention, not mine.

your example: sizeof(int) * CHAR_BIT + 2, its okay till here. 32 bytes +
2 bytes more ( 1 more sign and 1 for null character)

now you divide that expression by 3 and then add 2 to it. Why ?

I couldn't possibly comment.

thanks

 

[arnuld]

That's a lot of bytes.

eeee....... Richard

I *really* want to know why you divided the whole thing by 3 and added 2
to the result.

I know the final result is number of decimal digits an int can represent,
which is the maximum value of int on a machine. I am asking is that some
kind of formula like n(n+1)/2 ?

 

[Spiro Trikaliotis]

Hello,

Here, RH is "cheating": In fact, he does not calculate the number of
digits in the decimal system. He calculates the number of digits in
octal!

Of course, one has to remember that the octal representation needs at
least as many digits as the decimal representation. Without this fact,
this calculation would be pointless.

Regards,
Spiro.

"Anybody who would spend considerable effort emulating a C64 is not
particularly sane to begin with; it is unreasonable to expect them to produce
sane software."
("asuffield" in http://forums.thedailywtf.com/forums/p/7199/134136.aspx)

 

[Spiro Trikaliotis]

Hello Richard,

Right. Actually, I explained the entire calculation, for a variety of
number bases, on 22 July of this year (i.e. about two weeks ago).

Oh, I missed that one. On 22 July? I was on vacation on that day.

Regards,
Spiro.

"Anybody who would spend considerable effort emulating a C64 is not
particularly sane to begin with; it is unreasonable to expect them to produce
sane software."
("asuffield" in http://forums.thedailywtf.com/forums/p/7199/134136.aspx)

 

[Howard Jaegermeister]

There you have it gentlemen. What more evidence do you need?

Thank you Judas for the victim;
Stay a while; you'll watch it bleed.

(For those of you slow on the uptake: The "it" is proof that the regs
and wannabees [santosh] would far, far rather give totally worthless and
incomprehensible [to newbies] advice, than give a useful "off-topic"
answer.)

I think santosh prefers the C programming language to a syntax equivalent
of the american playground classic: smear the queer.

 

[David Thompson]

Richard Heathfield wrote:

(2b) snprintf once (to get the size), followed by buffer provision,
followed by sprintf [vs snprintf twice]

It's infinitesimally faster - or at least it might be! But more to
the point, it's less to type, so less to get wrong.

Possibly. However, it probably significantly increases the amount
of code loaded from the library. This may significantly increase
the runtime module size, assuming static library. Two functions
are normally bigger than one.

In general, but very unlikely in this case. Because of their
near-total duplication of extensive (compared to other std-lib
features) functionality, all of the *printf routines (and similarly
*scanf) are usually (near-trivial) wrappers around, or sometimes just
entrypoints into, a single 'engine'.

- formerly david.thompson1 || achar(64) || worldnet.att.net

 

[Stefan Ram]

you mean you missed the 4th step
1) find out how much storage you need for the string
2) malloc() that much
3) call sprintf to build the string
4) don't forget to free() the memory

Still, both of you did not check the result of malloc.