C99 IDE for windows

[arnuld]

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

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.



--

https://www.lispmachine.wordpress.com

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

[santosh]

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

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]

Re: C99 IDE for windows

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

Re: C99 IDE for windows

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]

Re: C99 IDE for windows

On 6 Aug, 10:27, Richard Heathfield <r...@see.sig.i nvalidwrote:

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?

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]

Re: C99 IDE for windows

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]

Meaning of implementation def. behaviour (was: Re: C99 IDE for windows)

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

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

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]

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

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]

Re: C99 IDE for windows

Nick Keighley wrote:

Richard Heathfield <r...@see.sig.i nvalidwrote:
>
[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.

[CBFalconer]

Re: C99 IDE for windows

santosh wrote:

Richard Heathfield wrote:
>

.... snip ...

>

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

He can. He just hasn't learned how.

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

[santosh]

Re: C99 IDE for windows

CBFalconer wrote:

santosh wrote:

>Richard Heathfield wrote:
>>

... snip ...

>>

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

>
He can. He just hasn't learned how.

Perhaps, but teaching him to open a shell is off-topic for this group,
as is getch(), hence the advise to use getchar().

[Richard Heathfield]

Re: C99 IDE for windows

CBFalconer said:

Nick Keighley wrote:

>Richard Heathfield <r...@see.sig.i nvalidwrote:
>>
>[RCH doesn't seem to like snprintf()]
>[I must admit its lack of portability puts me off]

>
What's non-portable?

Programs that rely on the existence and semantics of snprintf.

It is specified in the C99 standard.

Non sequitur.

<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

[Kenny McCormack]

Re: C99 IDE for windows

In article <g7cfdc$quv$2@r egistered.motza rella.org>,
santosh <santosh.k83@gm ail.comwrote:

>CBFalconer wrote:
>

>santosh wrote:

>>Richard Heathfield wrote:
>>>

>... snip ...

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

>>
>He can. He just hasn't learned how.

>
>Perhaps, but teaching him to open a shell is off-topic for this group,
>as is getch(), hence the advise to use getchar().
>

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

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

[Keith Thompson]

Re: C99 IDE for windows

Richard Heathfield <rjh@see.sig.in validwrites:

santosh said:

[...]

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

There's no portable way to determine the maximum length of the result
of a "%p" *printf conversion.

With snprintf, you can make a reasonable guess. The consequence of
guessing wrong is that the resulting string is truncated, and you can
either accept that or try again with a bigger buffer. Even if you're
given an even bigger string on the second attempt, the consequences
are still no worse than a truncated result.

With sprintf, you can make a reasonable guess, but the consequence of
guessing wrong is undefined behavior.

And even for integer and floating-point arguments, where you can (I
think) portably determine the maximum length, getting it right is
still a tedious and error-prone process.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"