C99 IDE for windows

[Ron Ford]

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?
--
Women have simple tastes. They get pleasure out of the conversation of
children in arms and men in love.
H. L. Mencken

[santosh]

arnuld wrote:

>On Tue, 05 Aug 2008 10:58:20 +0000, Richard Heathfield wrote:

>Using snprintf does not guarantee this. You have to use it
/properly/. And if you use sprintf properly, you get the same safety.
So snprintf isn't actually all that big a deal.

I searched the archives and really much confused. "Ben Pfaff" says:

The point is that strncpy() is as dangerous
as strcpy() if it isn't used with care.

This is true. In particular you can cause a buffer overrun just as
easily with strncpy as you can with strcpy.

In fact you cause a buffer overrun with just about every Standard C
function that takes a pointer to one. The only solution to this would
be either interpreting the code or adding runtime checks for all
pointer operations.

and regarding sprintf vs snprint I get this from "Aleksander Nabaglo"

1: Calculate needed buffer size,
2: Use assert: bug will not be hidden.
int nsp=0;

sprintf(buf, " ..... %n", /* args */ , &nsp);
if(buf_size <= nsp) { assert(0 & " buf[] too short ");
exit(SOME_ERROR_CODE);

is that okay ?

No, it won't compile. Besides a buffer overrun has already triggered
undefined behaviour by the time the if statement is executed, so we
cannot rely on it's behaviour either.

I also heard from someone that using assert() in code going to be
shipped is a bad idea. All assert statement, before the delivery, must
be removed.

It's poor programming to depend on assert for error checking. Assert is
therefore internal consistency verification during development. It's
always possible for a customer to compile your program with NDEBUG
defined, and if your program does error or validity checking with
assert, then it's rendered very fragile.

Do you have some code for safe sprintf() ?

Why? It's easy enough to write your own. Here is it's description 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.

>But it seems from other stuff you've said that you're only interested
in Linux, which is fine,

I actually thought snprint() will save me from buffer problems and now
after a little search I can see that I was using it blindly.

As I said elsewhere, provided the second argument is indeed the size of
the first, then buffer overrun *will* be prevented, though data loss
will occur.

One solution is to use snprintf itself to determine the minimum size of
the buffer that will be required and use a sufficiently large one.

Anyway, I
still like the for( int i = 0;..) localization in C99. I don't like my
programs to be polluted by some index numbers when I know I am on
Linux for next decade, at least.

If your functions are relatively short then there won't be
much "pollution" as you call it. You could also introduce a block,
though that's a very ugly solution, IMO.

PS. "Knowing" things for as much as a decade in advance is very risky in
computing (not the theoretical side.) If I were you, I'd still try to
keep my routines as portable as possible if the costs are not too high.

[Richard Heathfield]

arnuld said:

>On Tue, 05 Aug 2008 10:58:20 +0000, Richard Heathfield wrote:

>Using snprintf does not guarantee this. You have to use it /properly/.
And if you use sprintf properly, you get the same safety. So snprintf
isn't actually all that big a deal.

I searched the archives and really much confused. "Ben Pfaff" says:

The point is that strncpy() is as dangerous
as strcpy() if it isn't used with care.

He's right. Likewise, snprintf has its caveats and gotchas.

and regarding sprintf vs snprint I get this from "Aleksander Nabaglo"

1: Calculate needed buffer size,
2: Use assert: bug will not be hidden.
int nsp=0;

sprintf(buf, " ..... %n", /* args */ , &nsp);
if(buf_size <= nsp) { assert(0 & " buf[] too short ");
exit(SOME_ERROR_CODE);

is that okay ?

It's bizarre. The assert is meaningless, for a start. Secondly, if the idea
is to calculate whether a buffer overrun /has occurred/, then it's too
little too late. Instead:

1) find out how much data you need to store in your string;
2) allocate that much storage;
3) construct your string.

This is not exactly rocket science.

I also heard from someone that using assert() in code going to be shipped
is a bad idea. All assert statement, before the delivery, must be
removed.

Assertions are best used for checking program assumptions. If you have an
assertion such as assert(foo bar), what you're saying is "either foo is
greater than bar at this point, OR MY CODE IS WRONG". You never use
assertions to check the validity of data, only the validity of assumptions
you have made as a programmer. Since you obviously wouldn't dream of
shipping your code until you'd fixed all the bugs, there is no point in
leaving the assertions in place in the production code - so you can turn
them off by defining NDEBUG (which means you don't have to delete them
from the source code).

Do you have some code for safe sprintf() ?

I have a safe /strategy/ for sprintf:

1) find out how much storage you need for the string;
2) allocate that much;
3) call sprintf to build the string.

>But it seems from other stuff you've said that you're only interested in
Linux, which is fine,

I actually thought snprint() will save me from buffer problems and now
after a little search I can see that I was using it blindly.

You're not the first, and you won't be the last.

<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

[Ben Bacarisse]

Richard Heathfield <rj*@see.sig.invalidwrites:

<snip>

>>No, it doesn't have to be silent, because you could be listening
- but by the time you've taken the trouble to add the code to listen
for data loss and take corrective action to ensure that no data loss
occurs after all,

Exactly.

>>you might as well have used sprintf in the first place.

But the difference is that with sprintf you need to know this in
advance, while with snprintf you can "adapt as you go", so to speak.

Mostly you do know in advance. On the rare occasions when you don't, it's
generally easy enough to find out.

Generally, yes, but how do you find out how much storage you need for
%p? I don't know any reliable way.

<snip>

>>Arbitrary data loss might be okay for some people, but it's something
I try to avoid if I can.

Just as with strncpy there are rare times when snprintf is exactly
what you want. I once worked with a network event logging system that
gave you one packet to say what you wanted and truncation was the only
option. Life being what it is, that was before the snprintf family
had come into being, so I basically had to write it (simplified for
the cases that were needed) and I've never actually wanted this
truncation semantics since.

--
Ben.

[Richard Heathfield]

Ben Bacarisse said:

<snip>

how do you find out how much storage you need for
%p? I don't know any reliable way.

If the implementation uses the same representation each time for a given
pointer value, then it can be done using tmpfile and fprintf (which, of
course, returns the number of characters written).

If the implementation is pathological, you can at least get the length of
*a* representation of a pointer by this method, and then you can read back
in the value you just wrote out.

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

Ben Bacarisse wrote:

Richard Heathfield <rj*@see.sig.invalidwrites:

<snip>

>>>No, it doesn't have to be silent, because you could be listening
- but by the time you've taken the trouble to add the code to
listen for data loss and take corrective action to ensure that no
data loss occurs after all,

Exactly.

you might as well have used sprintf in the first place.

But the difference is that with sprintf you need to know this in
advance, while with snprintf you can "adapt as you go", so to speak.

Mostly you do know in advance. On the rare occasions when you don't,
it's generally easy enough to find out.

Generally, yes, but how do you find out how much storage you need for
%p? I don't know any reliable way.

char *str;
FILE *tmpf = tmpfile();

if (tmpf)
int n = fprintf(tmpf, "%p", (void*)ptr);
if (n < 0) /* error */
else str = malloc(n + 1);

if (str) /* use sprintf */
fclose(tmpf);

<snip>

[Ben Bacarisse]

Richard Heathfield <rj*@see.sig.invalidwrites:

arnuld said:

<snip>

>and regarding sprintf vs snprint I get this from "Aleksander Nabaglo"

1: Calculate needed buffer size,
2: Use assert: bug will not be hidden.
int nsp=0;

sprintf(buf, " ..... %n", /* args */ , &nsp);
if(buf_size <= nsp) { assert(0 & " buf[] too short ");
exit(SOME_ERROR_CODE);

is that okay ?

It's bizarre. The assert is meaningless, for a start. Secondly, if the idea
is to calculate whether a buffer overrun /has occurred/, then it's too
little too late.

It looks like the assert is there so that you don't get a *silent*
buffer overflow. The advice given is to calculate the size needed
*and* to check that you did not need more. So this assert is of the
right sort -- it checks internal program logic to spot, during
development, a logic error that might otherwise slip past.

--
Ben.

[santosh]

santosh wrote:

Ben Bacarisse wrote:

>Richard Heathfield <rj*@see.sig.invalidwrites:

<snip>

>>>>No, it doesn't have to be silent, because you could be listening
- but by the time you've taken the trouble to add the code to
listen for data loss and take corrective action to ensure that no
data loss occurs after all,

Exactly.

you might as well have used sprintf in the first place.

But the difference is that with sprintf you need to know this in
advance, while with snprintf you can "adapt as you go", so to
speak.

Mostly you do know in advance. On the rare occasions when you don't,
it's generally easy enough to find out.

Generally, yes, but how do you find out how much storage you need for
%p? I don't know any reliable way.

char *str;
FILE *tmpf = tmpfile();

if (tmpf)
int n = fprintf(tmpf, "%p", (void*)ptr);
if (n < 0) /* error */
else str = malloc(n + 1);

if (str) /* use sprintf */
fclose(tmpf);

<snip>

Oops sorry about all the syntax errors in that code.

[Richard Heathfield]

Ben Bacarisse said:

Richard Heathfield <rj*@see.sig.invalidwrites:

>arnuld said:

<snip>

>>and regarding sprintf vs snprint I get this from "Aleksander Nabaglo"

1: Calculate needed buffer size,
2: Use assert: bug will not be hidden.
int nsp=0;

sprintf(buf, " ..... %n", /* args */ , &nsp);
if(buf_size <= nsp) { assert(0 & " buf[] too short ");
exit(SOME_ERROR_CODE);

is that okay ?

It's bizarre. The assert is meaningless, for a start. Secondly, if the
idea is to calculate whether a buffer overrun /has occurred/, then it's
too little too late.

It looks like the assert is there so that you don't get a *silent*
buffer overflow.

Firstly, by the time the assertion happens (IF it happens), the overrun has
already occurred, and that's UB, so all bets are off.

Secondly, whether the buffer is big enough is very likely to be dependent
on runtime data, in which case an assertion is effectively being used for
data validation - never a good idea.

(Thirdly, the assertion might not happen at all, because NDEBUG might be
defined. Included only for completeness, since it's true of all
assertions.)

The advice given is to calculate the size needed
*and* to check that you did not need more. So this assert is of the
right sort -- it checks internal program logic to spot, during
development, a logic error that might otherwise slip past.

I see your point, and I'm prepared to meet it about halfway. It's still
broken code, IMHO. It's like having a safety net laid out flat on the
concrete.

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

[Ben Bacarisse]

Richard Heathfield <rj*@see.sig.invalidwrites:

Ben Bacarisse said:

>Richard Heathfield <rj*@see.sig.invalidwrites:

>>arnuld said:

<snip>

>>>and regarding sprintf vs snprint I get this from "Aleksander Nabaglo"

1: Calculate needed buffer size,
2: Use assert: bug will not be hidden.
int nsp=0;

sprintf(buf, " ..... %n", /* args */ , &nsp);
if(buf_size <= nsp) { assert(0 & " buf[] too short ");
exit(SOME_ERROR_CODE);

is that okay ?

It's bizarre. The assert is meaningless, for a start. Secondly, if the
idea is to calculate whether a buffer overrun /has occurred/, then it's
too little too late.

It looks like the assert is there so that you don't get a *silent*
buffer overflow.

Firstly, by the time the assertion happens (IF it happens), the overrun has
already occurred, and that's UB, so all bets are off.

Don't be so pessimistic -- the great thing about UB is that it can't
get any worse! The assert can't make the program any less
well-defined UB, and there just the chance that something good happens
as if by magic.

Secondly, whether the buffer is big enough is very likely to be dependent
on runtime data, in which case an assertion is effectively being used for
data validation - never a good idea.

I don't get this. They seem to be suggesting that the calculation
be checked via another route and that seems to be what assert is for,
surely? It would be clearer if the assert was for the condition they
test in the 'if', but...

(Thirdly, the assertion might not happen at all, because NDEBUG might be
defined. Included only for completeness, since it's true of all
assertions.)

Which, I think, explains why the assert is written the way it is. The
author wants the exit to happen, even in production code. Now that is
odd, even to me, but all I am trying to do in see what the thinking was.
I'd either just assert(buf_size nsp) or keep the "if" test and
replace the assert with an error message.

>The advice given is to calculate the size needed
*and* to check that you did not need more. So this assert is of the
right sort -- it checks internal program logic to spot, during
development, a logic error that might otherwise slip past.

I see your point, and I'm prepared to meet it about halfway. It's still
broken code, IMHO. It's like having a safety net laid out flat on the
concrete.

A better analogy would be a safety net over a hole in the floor.
The idea that it might catch you before you hit the basement.

--
Ben.

[CBFalconer]

arnuld wrote:

>

.... snip ...

>
I actually thought snprint() will save me from buffer problems and
now after a little search I can see that I was using it blindly.
Anyway, I still like the for( int i = 0;..) localization in C99. I
don't like my programs to be polluted by some index numbers when I
know I am on Linux for next decade, at least.

Bear in mind that everything you have been told, or advised, here
has nothing to do with Linux. It applies to all C programs. The
only requirement is that the compiler meet the demands of the
standard, and most do (at least to the C90 standard). However most
also require care in usage to keep them compatible. Look at your
compiler manuals.

For gcc the essential steps are to run it with:

gcc -W -Wall -ansi -pedantic

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

[user923005]

On Aug 4, 11:32*pm, arnuld <[e-mail]:
[snip]

I also heard from someone that using assert() in code going to be shipped
is a bad idea. All assert statement, before the delivery, must be removed..

Using assert() is strictly a debugging tool. The meaning of:
assert(foo);
is "I am absolutely sure that foo is true. I would be utterly
astonished if foo were *ever* false."

You cannot rely on assert() as a runtime correction to anything
because release builds typically #undef it. If you rely on assert()
to catch problems, the behavior can change when you recompile. And it
leaves a *very* bad impression when an assert() fires on a customer
site.

If you think that there is even a remote chance that boolean foo will
ever be false, then you need to do this:
if (foo)
perform_normal_stuff();
else
handle_panic_situation();

If you want to see a masterful use of assert [there are 1980 well done
asserts in the code], I highly recommend this chess program for study:
Look here:
http://arctrix.com/nas/chess/fruit/
Alternative here:
http://wbec-ridderkerk.nl/html/download.htm

[snip]

[Antoninus Twink]

On 5 Aug 2008 at 18:04, CBFalconer wrote:

For gcc the essential steps are to run it with:

gcc -W -Wall -ansi -pedantic

Interesting. So you've silently dropped the extra flags that force gcc
to be non-conforming, despite swearing blind for post after post in a
recent thread that they didn't, in the face of clear evidence to the
contrary? At least be grown up enough to admit your mistakes.

[Kenny McCormack]

In article <sl*******************@nospam.invalid>,
Antoninus Twink <no****@nospam.invalidwrote:

>On 5 Aug 2008 at 18:04, CBFalconer wrote:

>For gcc the essential steps are to run it with:

gcc -W -Wall -ansi -pedantic

Interesting. So you've silently dropped the extra flags that force gcc
to be non-conforming, despite swearing blind for post after post in a
recent thread that they didn't, in the face of clear evidence to the
contrary? At least be grown up enough to admit your mistakes.

Grown up? CBF? What planet are you posting from?

Actually, in terms of physical (not mental) age, CBF is, I believe,
about as old as dirt.

[arnuld]

On Tue, 05 Aug 2008 15:44:14 +0000, Richard Heathfield wrote:

I have a safe /strategy/ for sprintf:

1) find out how much storage you need for the string;
2) allocate that much;
3) call sprintf to build the string.

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

--
www.lispmachine.wordpress.com
my email is @ the above blog
check the "About Myself" page

[Richard Heathfield]

arnuld said:

>On Tue, 05 Aug 2008 15:44:14 +0000, Richard Heathfield wrote:

>I have a safe /strategy/ for sprintf:

1) find out how much storage you need for the string;
2) allocate that much;
3) call sprintf to build the string.

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

Only if you've allocated the memory dynamically, which isn't necessarily
the case.

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

On Wed, 06 Aug 2008 06:24:59 +0000, Richard Heathfield wrote:

>arnuld said:
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

Only if you've allocated the memory dynamically, which isn't necessarily
the case.

you mean I can simply do:

1) enum { ARRSIZE = 101 }
2) char array[ARRSIZE]
3) sprintf( ..... )

--
www.lispmachine.wordpress.com
my email is @ the above blog
check the "About Myself" page

[santosh]

arnuld wrote:

>On Wed, 06 Aug 2008 06:24:59 +0000, Richard Heathfield wrote:

>>arnuld said:
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

>Only if you've allocated the memory dynamically, which isn't
necessarily the case.

you mean I can simply do:

1) enum { ARRSIZE = 101 }
2) char array[ARRSIZE]
3) sprintf( ..... )

You can, but if array is not large enough a buffer overrun will occur,
while with snprintf you can prevent that at the cost of data loss.

An exercise: Consider the format specifier "%+0#*.*LG\t%0#p\n%ls\n"
How many characters does a buffer need to be to prevent a overrun? Can
you find out without using *printf function?

[Richard Heathfield]

arnuld said:

>On Wed, 06 Aug 2008 06:24:59 +0000, Richard Heathfield wrote:

>>arnuld said:
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

>Only if you've allocated the memory dynamically, which isn't necessarily
the case.

you mean I can simply do:

1) enum { ARRSIZE = 101 }
2) char array[ARRSIZE]
3) sprintf( ..... )

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 */

which is a constant integer expression and can be used as an array size. So
in this case, dynamic allocation is not required and thus no free() call
is necessary. But if, on the other hand, you wanted space for n ints, then
of course you would need to allocate dynamically.

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

[Richard Heathfield]

santosh said:

<snip>

An exercise: Consider the format specifier "%+0#*.*LG\t%0#p\n%ls\n"

An exercise: Consider shooting the analyst. :-)

How many characters does a buffer need to be to prevent a overrun?

No amount will be sufficient, since an overrun is always one possible
result of undefined behaviour - and that format specifier *will* invoke
undefined behaviour if you pass it to *printf.

Can you find out without using *printf function?

Simply looking it up in the Standard was sufficient.

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

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:
#include <stdio.h>

int main( void )
{
char arrc[10];

sprintf(arrc, "This is more than 10 bytes, of course");
printf("-------------------------------\n");
printf("%s", arrc);

return 0;
}

=============== OUTPUT =================
[arnuld@dune ztest]$ gcc -std=c99 -pedantic -Wall -Wextra test.c
[arnuld@dune ztest]$ ./a.out
-------------------------------
Segmentation fault
[arnuld@dune ztest]$

Now if I add a '\n'

1.) after the %s in last printf.
2.) or in the end of the string literal (the 2nd argument to sprintf)
then the the output is this:

[arnuld@dune ztest]$ ./a.out
-------------------------------
This is more than 10 bytes, of course
Segmentation fault
[arnuld@dune ztest]$
It prints the message though Segfaults. I don't understand it.

--
www.lispmachine.wordpress.com
my email is @ the above blog
check the "About Myself" page

[santosh]

Richard Heathfield wrote:

santosh said:

<snip>

>An exercise: Consider the format specifier "%+0#*.*LG\t%0#p\n%ls\n"

An exercise: Consider shooting the analyst. :-)

>How many characters does a buffer need to be to prevent a overrun?

No amount will be sufficient, since an overrun is always one possible
result of undefined behaviour - and that format specifier *will*
invoke undefined behaviour if you pass it to *printf.

>Can you find out without using *printf function?

Simply looking it up in the Standard was sufficient.

Yes, it does seem rather silly. However barring the '0' and '#' before
the 'p' specifier, the rest is correct, and it emphasises my main
point, which is that with floating point values, it's not as easy to
pre-calculate the buffer size needed, as it is with integers. Of course
the 'p' specifier throws an additional spanner into the works.

[santosh]

arnuld wrote:

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

On Wed, 06 Aug 2008 13:20:36 +0530, santosh wrote:

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.

--
www.lispmachine.wordpress.com
my email is @ the above blog
check the "About Myself" page

[arnuld]

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 ?
--
www.lispmachine.wordpress.com
my email is @ the above blog
check the "About Myself" page

[santosh]

arnuld wrote:

>On Wed, 06 Aug 2008 13:20:36 +0530, santosh wrote:

>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.

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.

[Richard Heathfield]

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]

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]

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]

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]

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]

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]

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]

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
--
www.lispmachine.wordpress.com
my email is @ the above blog
check the "About Myself" page

[Nick Keighley]

On 5 Aug, 16:44, Richard Heathfield <[e-mail]:

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

>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 <g7**********@registered.motzarella.org>
santosh <sa*********@gmail.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, "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.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: gmail (figure it out) http://web.torek.net/torek/index.html

[pereges]

On Jul 19, 5:49 am, Ron Ford <[e-mail]:

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]

Nick Keighley said:

On 5 Aug, 16:44, Richard Heathfield <[e-mail]:

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

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]

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]

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

[arnuld]

On Wed, 06 Aug 2008 14:01:59 +0530, santosh wrote:

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.

--
www.lispmachine.wordpress.com
my email is @ the above blog
check the "About Myself" page

[santosh]

arnuld wrote:

>On Wed, 06 Aug 2008 14:01:59 +0530, santosh wrote:

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.

Yes.

>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.

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

[Richard Heathfield]

santosh said:

<snip>

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.

Fine, but that doesn't mean they can't be rule-based, as long as the rules
are fully 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.

Not in ISO C, you can't, because in ISO C you can't assume you're using a
"near data model", and you can't assume you're using a "far data model",
because you might not even be using that kind of memory organisation at
all. What's more, even if you know you are, how are you going to
determine, using only the guarantees available to you in the ISO C
Standard, precisely which kind of "data model" you are using on a given
execution of the code?

<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,

Bear in mind that even the conformance docs I showed you - which are from a
commercial implementation - were very vague about details like what the
bit before the colon represented, and what the bit after the colon
represented. So programmers aren't necessarily going to get as much
information from the conformance docs as you might like them to have. But
let's just say that we /do/ specify the exact hash method, and let's just
say that it's a weird one that might result in a hash of a few bytes (and
normally does) but might occasionally result in a hash of a few megabytes.
That really messes us up for %p, doesn't it?

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.

Yeah, and that's the trouble - you are relying on QoI rather than on what
the Standard guarantees. And we have already seen that QoI isn't always as
Q as we might like it to be, even for some relatively popular flavours of
I.

>>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.

Yes, but that still gives you the problem that successive calls to *printf
might give wildly varying results for the number of characters needed to
represent %p.

I think the intent behind implementation defined behaviour is that
conforming implementations define it to a sufficiently precise and
useful level.

What you and I think isn't really all that important compared to what the
Standard actually says.

Otherwise the Standard could just as well have classified
them under undefined behaviour.

In a sense, implementation-defined behaviour /is/ undefined (but only in a
sense). Consider C99's weasel words about main(), for example. If a C99
implementation defines void main, then void main is implementation-defined
- ON THAT IMPLEMENTATION. On other implementations, it remains undefined.

This isn't true for everything, obviously. We've pretty much got UCHAR_MAX
nailed down, for example. But for something as nebulous as %p, it's a real
problem.

>>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. :-)

The idea has been discussed before. Personally, I think it would be a
valuable teaching tool - even /without/ the optional hardware add-ons.

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

[Richard Heathfield]

santosh said:

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

What's wrong with:

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

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

[Nick Keighley]

On 6 Aug, 10:27, Richard Heathfield <[e-mail]:

Nick Keighley said:

On 5 Aug, 16:44, Richard Heathfield <[e-mail]:

[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>
--
Nick Keighley

[santosh]

Richard Heathfield wrote:

santosh said:

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

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]

Richard Heathfield wrote:

santosh said:

<snip>

>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.

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]

arnuld wrote:

>

.... 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.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

[CBFalconer]

Richard Heathfield wrote:

arnuld said:

.... snip ...

>

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

Then stick with snprintf. In fact, stick with Visual Basic.

Now that is unnecessary nasty treatment of a newbie.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

[CBFalconer]

Nick Keighley wrote:

Richard Heathfield <[e-mail]:

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

What's non-portable? It is specified in the C99 standard.

>
<snip>

>I have a safe /strategy/ for sprintf:

1) find out how much storage you need for the string;

how?

Assuming the parameters specifying the elements to be printed do
not change between the calls, call snprintf twice. The first time
replace the string with NULL and the size with 0. The returned
value will specify how many chars are needed. Add 1 (for the '\0'
mark), find or make a buffer with that space, and do the second
call.

If the items are likely to change between calls, copy them to
appropriate locations first. Then check and print from those.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.