C99 IDE for windows

[santosh]

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 but I got the idea that
you must know your input size in advance which I already know. e.g if
I am sure that my input is no more than 10 bytes then:

char arrc[10];
sprintf(arrc, "This input is definitely more than 10 bytes");

what will it do. In curiosity I have played with this code:

<snip>

C doesn't say what happens after undefined behaviour is invoked. The
expected result could be derived, the program could crash, the machine
could crash, the fuses for your building's power supply could blow...

In short, there is not much point in experimenting with undefined
behaviour. It is of course nice to see what really happens on a buffer
overrun on your implementation, but undefined behaviour being what it
is, the same "thing" might not happen on the very next run of the same
program, or after the same program is recompiled with differring
options, or if it's run after a system upgrade, or with another
implementation on another machine etc.

Even if an instance of UB is defined and documented by your compiler,
there is no requirement that the next compiler define it or document
what it has defined or define it in a way that is compatible with the
previous compiler's behaviour and so on.

 

[arnuld]

C doesn't say what happens after undefined behaviour is invoked. The
expected result could be derived, the program could crash, the machine
could crash, the fuses for your building's power supply could blow...

In short, there is not much point in experimenting with undefined
behaviour.

.. SNIP...

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.

 

[arnuld]

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 ?

 

[santosh]

Now what is UB in this case.

The buffer overrun.

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

Firstly NULL is a macro that expands to a null pointer constant. It is
not conceptually related to the null *character* , i.e., '\0'.

Secondly snprintf and sprintf both always terminate their output with a
null character. From which example do you claim that sprintf did not
put any '\0' byte at the end of the array, while snprintf did? If it
was from a program that invokes Undefined Behaviour then your
observations and conclusions are not valid.

 

[santosh]

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.

 

[santosh]

santosh said:


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.

 

[Chris Dollin]

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.

 

[arnuld]

Then stick with snprintf.

In fact, stick with Visual Basic.

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

 

[Nick Keighley]

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

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]

santosh said:

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, "implementation-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.

 

[pereges]

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.

 

[santosh]

"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]

santosh said:


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.

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.

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.

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.

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]

pereges wrote:

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();

 

[arnuld]

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.

so, for both sprintf and snprintf, the character count must be N-1,
reserving the last character for null.

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

I downloaded it, 3.6 MB ,went straight to section 7.19.6.6 for sprintf.
Sadly after reading it and experimenting with both, I am no longer happier
at using snprintf as a replacement, in my specific case, as I already know
the maximum number of characters to be written.

 

[santosh]

so, for both sprintf and snprintf, the character count must be N-1,
reserving the last character for null.
Yes.


I downloaded it, 3.6 MB ,went straight to section 7.19.6.6 for
sprintf. Sadly after reading it and experimenting with both, I am no
longer happier at using snprintf as a replacement, in my specific
case, as I already know the maximum number of characters to be
written.

In this case sprintf is fine and more portable too, though I suppose it
wouldn't matter for your case.

 

[Nick Keighley]

Nick Keighley said:

On 5 Aug, 16:44, Richard Heathfield <[email protected]> wrote:

[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?

er... I used to work with someone with those initials who was also
called Richard... oops.

[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?

I believe there are versions Out There written in C90.
But that probably destroys my "it uses the same code" argument

<snip>

 

[santosh]

santosh said:


What's wrong with:

open a shell, find the program, run the program from the shell.

That's the ideal. But assuming that 'pereges' cannot do that (since if
he could, he obviously wouldn't be misusing getch like this), getchar
provides the behaviour he needs (block just before return from main)
without rendering the code nonportable.

 

[santosh]

santosh said:



Fine, but that doesn't mean they can't be rule-based, as long as the
rules are fully specified.

In fact the Standard seems, (at a second glance), to be far more
restrictive that what I said above. I'll take the liberty of including
the relevant citations from n1256.

3.4.4
1 unspecified behavior
use of an unspecified value, or other behavior where this
International Standard provides two or more possibilities and imposes
no further requirements on which is chosen in any instance

3.4.1
1 implementation-defined behavior
unspecified behavior where each implementation documents how the
choice is made

3.4
1 behavior
external appearance or action

Here "unspecified value" is not defined, as far as I can see. However
for each instance of unspecified behaviour it seems that the Standard
provides all possible courses of action and the implementation is
merely required to choose one course from this list, and from this list
only, though the choice needn't be documented. And implementation
defined behaviour is merely a subset of unspecified behaviour where the
implementation's choice needs to be documented.

In light of this interpretation (though I'm sure I've overlooked
something important somewhere), how can the Standard specify the output
of the 'p' conversion specifier as implementation defined if it has not
itself defined the possible forms of that behaviour a conforming
implementation is required to select one from and document it?

<snip>

 

[CBFalconer]

.... snip ...

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.

Not so. From the standard:

7.19.6.6 The sprintf function
Synopsis
[#1]
#include <stdio.h>
int sprintf(char * restrict s,
const char * restrict format, ...);
Description

[#2] The sprintf function is equivalent to fprintf, except
that the output is written into an array (specified by the
argument s) rather than to a stream. A null character is
written at the end of the characters written; it is not
counted as part of the returned value. If copying takes
place between objects that overlap, the behavior is
undefined.

Returns

[#3] The sprintf function returns the number of characters
written in the array, not counting the terminating null
character, or a negative value if an encoding error
occurred.