C99 IDE for windows

[Richard Heathfield]

Re: sprintf basics (was: C99 IDE for windows)

arnuld said:

>On Wed, 06 Aug 2008 06:53:05 +0000, Richard Heathfield wrote:

>
>

>I mean it depends on the circumstances. For example, if you want to
>"sprint" three possibly-negative ints and a ten-byte string, separated
>by spaces, you know at compile time that you need
>>
> 3 * /* three */
> ((sizeof(int) * CHAR_BIT + 2) / 3) + /* ints, */
> 1) + /* possibly negative, */
> 10 + /* and a ten-byte string, */
> 3 + /* and three separating spaces,
> */
> 1 /* and a null terminator */

>

>... SNIP..

>
>
I really did not understand the most of it ;)

Then stick with snprintf.

In fact, stick with Visual Basic.

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[santosh]

Re: sprintf basics (was: C99 IDE for windows)

arnuld wrote:

>On Wed, 06 Aug 2008 13:00:12 +0500, arnuld wrote:

>

>Now what is UB in this case. From this example i can see that sprintf
>does not put any '\0' (NULL byte) in the end of the array while
>snprintf does.

>
>
does it mean that I have to put /ARRSIZE - 1/ characters, keeping the
last for NULL byte ?

No. With snprintf N-1 characters will be written to a buffer of N
elements and then a null character will be added. With sprintf however
many characters that are generated by interpretation of the format
specifier and the subsequent arguments, if any, will be written and a
null character added at the end.

See the draft Standard for details. Search for n1256.pdf with Google.

[Richard Heathfield]

Re: C99 IDE for windows

santosh said:

<snip>

However barring the '0' and '#' before
the 'p' specifier, the rest is correct, and it emphasises my main
point,

Really? I'd have thought the opposite was true.

which is that with floating point values, it's not as easy to
pre-calculate the buffer size needed, as it is with integers.

Sure it is. In general? No, perhaps not. But within a given problem domain,
it's normally not so bad as all that.

Of course the 'p' specifier throws an additional spanner into the works.

I think it throws a spanner into snprintf's works, too - I could be wrong,
but is there any *obligation* on implementations to choose the same
textual representation for a pointer on every invocation? If not, then
snprintf's "let me tell you how big a buffer you would have needed *this*
time" doesn't really mean a lot where %p is concerned.

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[santosh]

Re: C99 IDE for windows

Richard Heathfield wrote:

santosh said:

<snip>

>Of course the 'p' specifier throws an additional spanner into the
>works.

>
I think it throws a spanner into snprintf's works, too - I could be
wrong, but is there any *obligation* on implementations to choose the
same textual representation for a pointer on every invocation? If not,
then snprintf's "let me tell you how big a buffer you would have
needed *this* time" doesn't really mean a lot where %p is concerned.

The behaviour is implementation defined, and I doubt that it is
allowable for implementation defined behaviour to suddenly change
during runtime or compile-time. Such behaviour must be defined, known
to the programmer before-hand. It could only change during translation
or execution *if* the implementation provided a way to access the new
definition from within the program. This would increase program
complexity to such an extent that no one would then program in C. :-)

[santosh]

Re: C99 IDE for windows

arnuld wrote:

>On Mon, 04 Aug 2008 16:47:21 -0400, CBFalconer wrote:

>
>

>You are much more portable relying on the C90 standard. The result
>is almost always compatible with C99 (the only exception I know of
>has to do with the modulus operator and negative values). You
>can't use the // comments, but that is no loss IMO.

>
what about snprintf, which saves from overflowing the array attacks.

If you can get the second parameter of snprintf right, you can construct
a perfectly defined call to sprintf too.

And what about localization of index integers like for( in i = 0...) .

{
int i;
for (...)
...
}

I know you are trying to help me, what I am saying that the softwares
I am paid to write for are designed only to run on Linux and nothing
else.

Fair enough, though if all else is equal, a more portable solution is
always a better investment for the future.

>With gcc, I habitually use:
> -W -Wall -ansi -pedantic -Wwrite-strings -Wfloat-equal -ftrapv ...

>
Doesn't -Wextra give access to -Wwrite-strings and -Wfloat-equal ?

Not according to the gcc documentation I have.

[Chris Dollin]

Re: C99 IDE for windows

santosh wrote:

Richard Heathfield wrote:

>santosh said:

>
<snip>
>

>>Of course the 'p' specifier throws an additional spanner into the
>>works.

>>
>I think it throws a spanner into snprintf's works, too - I could be
>wrong, but is there any *obligation* on implementations to choose the
>same textual representation for a pointer on every invocation? If not,
>then snprintf's "let me tell you how big a buffer you would have
>needed *this* time" doesn't really mean a lot where %p is concerned.

>
The behaviour is implementation defined, and I doubt that it is
allowable for implementation defined behaviour to suddenly change
during runtime or compile-time. Such behaviour must be defined, known
to the programmer before-hand.

"If the current clock-time has an even number of seconds, display
this way; otherwise, display that (longer) way".

It could only change during translation
or execution *if* the implementation provided a way to access the new
definition from within the program.

That's OK; the definition is the same at all times.

This would increase program
complexity to such an extent that no one would then program in C. :-)

No, it would reduce uptake of the willfully variable implementation
to such an extent that no one would them program on it -- or at least,
that part of it.

--
'It changed the future .. and it changed us.' /Babylon 5/

Hewlett-Packard Limited registered no:
registered office: Cain Road, Bracknell, Berks RG12 1HN 690597 England

[Richard Heathfield]

Re: C99 IDE for windows

santosh said:

Richard Heathfield wrote:

>santosh said:

>
<snip>
>

>>Of course the 'p' specifier throws an additional spanner into the
>>works.

>>
>I think it throws a spanner into snprintf's works, too - I could be
>wrong, but is there any *obligation* on implementations to choose the
>same textual representation for a pointer on every invocation? If not,
>then snprintf's "let me tell you how big a buffer you would have
>needed *this* time" doesn't really mean a lot where %p is concerned.

>
The behaviour is implementation defined, and I doubt that it is
allowable for implementation defined behaviour to suddenly change
during runtime or compile-time.

C&V, please.

Such behaviour must be defined, known to the programmer before-hand.

Yes, but there's nothing in the Standard that says the behaviour can't
follow dynamic rules.

Case in point: I have compiler conformance documentation here that, under
"4.9.6.1 The output for %p conversion in fprintf", says: "In near data
models, four hex digits (XXXX). In far data models, four hex digits,
colon, four hex digits (XXXX:XXXX)."

So for that implementation we have two different definitions of behaviour,
depending on the invocation options. Note, too, that it doesn't say
anything about normalising the pointer, so we could certainly end up with
two different strings representing the same pointer, even within this
fairly limited excursion into the libertarian world of
implementation-defined behaviour. Given this as a starting point, it isn't
difficult to imagine conformance documentation that says something like
"the output for %p conversion in printf is a hash of the pointer bits and
the current time and various other system-dependent values, expressed as a
non-padded and arbitrarily long string of non-colon characters followed by
a colon and the address in decimal notation".

It could only change during translation
or execution *if* the implementation provided a way to access the new
definition from within the program.

Or if the change was in accordance with some kind of dynamic rule.

This would increase program
complexity to such an extent that no one would then program in C. :-)

No, mostly we just pray for sane implementations . :-)

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[arnuld]

Re: sprintf basics (was: C99 IDE for windows)

On Wed, 06 Aug 2008 08:34:07 +0000, Richard Heathfield wrote:

Then stick with snprintf.

:(

In fact, stick with Visual Basic.

Richard....... no... I hate VB


--

https://www.lispmachine.wordpress.com

my email is @ the above blog
check the "About Myself" page

[Nick Keighley]

Re: C99 IDE for windows

On 5 Aug, 16:44, Richard Heathfield <r...@see.sig.i nvalidwrote:

[RCH doesn't seem to like snprintf()]
[I must admit its lack of portability puts me off]

<snip>

I have a safe /strategy/ for sprintf:
>
1) find out how much storage you need for the string;

how?
If I do it by machine what's wrong with using snprintf()?
Internally it's probably using the same code as sprintf()
making it highly likely to get the same answer.
If I do it by hand then I have to recalculate it every time
I change machines (or compiler flags).

2) allocate that much;
3) call sprintf to build the string.

<snip>

--
Nick Keighley

Infinitely many bits doesn't give you "100% accuracy". You will
only be able to represent the algebraic numbers.

Sure, if you use one of those old-fashioned implementations that only
has aleph-null-bit floating-point. Any decent modern implementation
should provide at least aleph-one bits.
(Bill Pursell and Keith Thompson clc)

[Chris Torek]

Re: C99 IDE for windows

>santosh said:

>>Of course the 'p' specifier throws an additional spanner into the
>>works.

>Richard Heathfield wrote:

>I think it throws a spanner into snprintf's works, too - I could be
>wrong, but is there any *obligation* on implementations to choose the
>same textual representation for a pointer on every invocation? If not,
>then snprintf's "let me tell you how big a buffer you would have
>needed *this* time" doesn't really mean a lot where %p is concerned.

In article <g7bofi$jmr$1@r egistered.motza rella.org>
santosh <santosh.k83@gm ail.comwrote:

>The behaviour is implementation defined, and I doubt that it is
>allowable for implementation defined behaviour to suddenly change
>during runtime or compile-time.

In this case, "implementa tion-defined" simply means it must be
documented. It could be documented as "prints ten characters on
Mondays and five hundred characters on Fridays", for instance.
(Not very realistic, I admit, but pretty clearly permitted.)

>Such behaviour must be defined, known to the programmer
>before-hand.

Assuming, of course, that the programmer reads the implementation
document. If the goal is to write portable C, including porting
to future implementations , this becomes difficult. "Before I write
this, I need to read the documentation for a compiler that will
not be designed for another decade." :-)

In any case, to handle this with snprintf(), one might write, e.g.:

do {
need = snprintf(NULL, 0, fmt, arg1, arg2, ..., argN);
... handle error (need<0) case ...
result = snprintf(buf, size, fmt, arg1, arg2, ..., argN);
} while (result != need);

which is not guaranteed to terminate, but will not lose data. Or
more realistically, one could simply check whether result==need
after the second snprintf(), to make sure nothing important changed
(perhaps, e.g., one of the "arg"s mysteriously changed between the
two calls, which could happen in multithreaded code).

One can always make mistakes. The snprintf() function is no
protection against this. On the other hand, while no tool is ever
perfect, some tools are clearly better than others: sprintf() is
a useable tool, but snprintf() is a better one.
--
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: gmail (figure it out) http://web.torek.net/torek/index.html

[pereges]

Re: C99 IDE for windows

On Jul 19, 5:49 am, Ron Ford <r...@nowhere.n etwrote:

I'm looking for a freeware c99 compiler for windows. I had intended to use
MS's Visual C++ Express and use its C capability. In the past with my MS
products, I've simply needed to make .c the filetype to invoke the C
compiler. Here's a link
>

http://www.microsoft.com/express/download/#webInstall

>
The download is 2.6 megs, which is near a reasonable size for a compiler,
but then setup.exe wants to download 87 megs of dot net framework hoggs
that I don't want on my machine.
>
In the past I've gone with Bloodshed, but I find myself unable to get the
shell to stay open so I can see some output.
>
The development environment for gcc is austere.
>
Anyone have another suggestion?

In blood shed, using a getch() statement just before the return 0
statement in main function has worked for me. The shell stays open
(unless you enter some character) and you can see the output.

I think its not considered standard C but if seeing the output is the
only aim then nothing wrong with it I guess.

[Richard Heathfield]

Re: C99 IDE for windows

Nick Keighley said:

On 5 Aug, 16:44, Richard Heathfield <r...@see.sig.i nvalidwrote:
>
[RCH doesn't seem to like snprintf()]

That's at least the second time, so it's presumably not a typo, so I'm
moved to ask where you get the C from, in RCH?

[I must admit its lack of portability puts me off]

Right. And that's the whole thing. When I *know* snprintf will be available
with portable semantics on all my target platforms, I will happily use it.
Until then, why pollute my code unnecessarily with non-portable stuff?

<snip>
>

>I have a safe /strategy/ for sprintf:
>>
>1) find out how much storage you need for the string;

>
how?

Depends.

If I do it by machine what's wrong with using snprintf()?

What if you haven't /got/ snprintf?

Internally it's probably using the same code as sprintf()
making it highly likely to get the same answer.
If I do it by hand then I have to recalculate it every time
I change machines (or compiler flags).

I've given an example elsethread of how simple examples can be calculated
at compile time. More complicated examples are, necessarily, more
complicated.

<snip>

--
Richard Heathfield <http://www.cpax.org.uk >
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[santosh]

Re: C99 IDE for windows

Chris Dollin wrote:

santosh wrote:
>

>Richard Heathfield wrote:

>>santosh said:

>>
><snip>
>>

>>>Of course the 'p' specifier throws an additional spanner into the
>>>works.
>>>
>>I think it throws a spanner into snprintf's works, too - I could be
>>wrong, but is there any *obligation* on implementations to choose
>>the same textual representation for a pointer on every invocation?
>>If not, then snprintf's "let me tell you how big a buffer you would
>>have needed *this* time" doesn't really mean a lot where %p is
>>concerned.

>>
>The behaviour is implementation defined, and I doubt that it is
>allowable for implementation defined behaviour to suddenly change
>during runtime or compile-time. Such behaviour must be defined, known
>to the programmer before-hand.

>
"If the current clock-time has an even number of seconds, display
this way; otherwise, display that (longer) way".

But since all possible ways are specified, it okay, albeit less than
ideal. One can test the time for even seconds and adapt as necessary.

However this is not the case with the output for 'p' specifier changing
from invocation to invocation. Being implementation defined, it can
only change from one implementation to another. If it must change
during runtime, then all possibilities have to be defined and
documented.

For example this could be one possible definition of the format of
output produced by the 'p' specifier:

* The output generated for the p specifier is identical to the output
that would be generated if the void* value were cast to unsigned long
and printed with the '#lx' specifier.

If p's behaviour must vary during runtime then similar definitions
should be documented for each such instance. Simply varying in an
undefined manner is not implementation defined behaviour.

[santosh]

Re: C99 IDE for windows

Richard Heathfield wrote:

santosh said:
>

>Richard Heathfield wrote:

>>santosh said:

>>
><snip>
>>

>>>Of course the 'p' specifier throws an additional spanner into the
>>>works.
>>>
>>I think it throws a spanner into snprintf's works, too - I could be
>>wrong, but is there any *obligation* on implementations to choose
>>the same textual representation for a pointer on every invocation?
>>If not, then snprintf's "let me tell you how big a buffer you would
>>have needed *this* time" doesn't really mean a lot where %p is
>>concerned.

>>
>The behaviour is implementation defined, and I doubt that it is
>allowable for implementation defined behaviour to suddenly change
>during runtime or compile-time.

>
C&V, please.

The definition for implementation defined behaviour in section 3.4 of
n1256, taken in conjunction with the definition for unspecified
behaviour, on which it depends, seems to state pretty strongly that
_all_ the details of an instance of implementation defined behaviour
must be specified.

>Such behaviour must be defined, known to the programmer before-hand.

>
Yes, but there's nothing in the Standard that says the behaviour can't
follow dynamic rules.
>
Case in point: I have compiler conformance documentation here that,
under "4.9.6.1 The output for %p conversion in fprintf", says: "In
near data models, four hex digits (XXXX). In far data models, four hex
digits, colon, four hex digits (XXXX:XXXX)."

This is fine, as far as I can see, since all possibilities are
specified. Thus one can program appropriately depending on the type of
the pointer.

<snip>

Given this as a
starting point, it isn't difficult to imagine conformance
documentation that says something like "the output for %p conversion
in printf is a hash of the pointer bits and the current time and
various other system-dependent values, expressed as a non-padded and
arbitrarily long string of non-colon characters followed by a colon
and the address in decimal notation".

This *is* problematic since the exact hash method used is not specified,
even assuming that cross references do tell us the output formats of
the time and system dependent functions.

So this is a case where an instance of implementation defined behaviour
is not defined in a sufficiently useful manner. I suppose it's a QoI
issue, at least in this instance.

>It could only change during translation
>or execution *if* the implementation provided a way to access the new
>definition from within the program.

>
Or if the change was in accordance with some kind of dynamic rule.

Yes, in which case those dynamic rules must be specified.

I think the intent behind implementation defined behaviour is that
conforming implementations define it to a sufficiently precise and
useful level. Otherwise the Standard could just as well have classified
them under undefined behaviour.

>This would increase program
>complexity to such an extent that no one would then program in C. :-)

>
No, mostly we just pray for sane implementations . :-)

Right. I suppose that we should perhaps be glad that the comp.lang.c
regulars aren't implementors too, or the DS9K would actually exist. :-)

[santosh]

Re: C99 IDE for windows

pereges wrote:

<snip>

In blood shed, using a getch() statement just before the return 0
statement in main function has worked for me. The shell stays open
(unless you enter some character) and you can see the output.
>
I think its not considered standard C but if seeing the output is the
only aim then nothing wrong with it I guess.

What's wrong with:

getchar();