A C showstopper
spinoza1111
thread A C Adventure, I have to recreate my utilities library of 1991,
which I did because then (and now) one needs to use the printf
approach to format data: but if one needs, as one often does need, to
format to storage, sprintf has a built in danger that as far as I know
(and correct me if I'm wrong) nobody has or will fix inside of C.
The problem is that any sprintf whatsoever, insofar as it formats
strings, has no control over string length. Most code I've seen
decides to create some silly "buffer" of some silly size.
But in
sprintf(buf, "%s\n", ptr)
characters past the allocated end of "buf" may be overwritten.
The C99 solution (limit the number of characters) is extraordinarily
poor and reinforces my Dim View of the ethics of people in that
effort: some of them participated in the "get Schildt" campaign, and
none of them seems to have been competent working programmers.
In 1991, I implemented the GNU solution, but I don't have the code
anymore. This is asprintf; its contract is to always allocate enough
memory to hold the final string.
There are two ways of implementing asprintf. Either iterate formatting
until everything's formatted, reallocating larger and larger blocks of
memory (and copying previously formatted output characters). Or make a
pass through the data without doing output to find the size needed. My
1991 solution was the former. Today, when I write the code, I shall
use the latter solution.
The GNU solution , not the C99 solution, is the one that occurs to the
competent programmer: the C99 solution cuts off the user at the knees
blindly and is the sort of solution that occurs to managers...not
competent programmers.
However, in 1991, I felt uncomfortable to bill a user for implementing
this type of code. It should be available to applications programs as
it is in most other languages.
This alone demonstrates that C is not a viable programming language
anymore, and may never have been, for applications other than writing
operating systems and compilers.
I'm suspending work on the "adventure" project and shall return when
I'm not so disgusted as I am now.
Rui Maciel
> The problem is that any sprintf whatsoever, insofar as it formats
> strings, has no control over string length.
What about snprintf() ?
Rui Maciel
Sri Harsha Dandibhotla
strings, has no control over string length. Most code I've seen
decides to create some silly "buffer" of some silly size. "
you still have to create some silly buffer of some silly size.
Flash Gordon
He refers to it, but does not understand it well enough to see that it
provides exactly the tool he needs to implement what he wants whilst
also providing the flexibility to do other things.
--
Flash Gordon
Beej Jorgensen
>you still have to create some silly buffer of some silly size.
void *create_some_silly_buffer(size_t some_silly_size)
{
return malloc(some_silly_size);
}
:)
-Beej
Chris M. Thomasson
news:f1c71ada-8763-4b31...@v15g2000prn.googlegroups.com...
> To develop the "unlimited string" processor which I discuss in the
> thread A C Adventure, I have to recreate my utilities library of 1991,
> which I did because then (and now) one needs to use the printf
> approach to format data: but if one needs, as one often does need, to
> format to storage, sprintf has a built in danger that as far as I know
> (and correct me if I'm wrong) nobody has or will fix inside of C.
>
> The problem is that any sprintf whatsoever, insofar as it formats
> strings, has no control over string length. Most code I've seen
> decides to create some silly "buffer" of some silly size.
>
> But in
>
> sprintf(buf, "%s\n", ptr)
>
> characters past the allocated end of "buf" may be overwritten.
Perhaps something like this may be of service:
_________________________________________________________________
#include <stdio.h>
int main(void)
{
char buffer[6] = { '\0' };
char const string[] = "Hello";
size_t size = sprintf(buffer, "%.1s", string);
printf("%lu - %s\n", (unsigned long int)size, buffer);
size = sprintf(buffer, "%.2s", string);
printf("%lu - %s\n", (unsigned long int)size, buffer);
size = sprintf(buffer, "%.3s", string);
printf("%lu - %s\n", (unsigned long int)size, buffer);
size = sprintf(buffer, "%.4s", string);
printf("%lu - %s\n", (unsigned long int)size, buffer);
size = sprintf(buffer, "%.5s", string);
printf("%lu - %s\n", (unsigned long int)size, buffer);
return 0;
}
_________________________________________________________________
Richard Harter
I believe that is what he was referring to with "The C99 solution
(limit the number of characters) is extraordinarily poor ..."
Richard Harter, c...@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
No one asks if a tree falls in the forest
if there is no one there to see it fall.
Flash Gordon
Now read what Rui wrote. snprintf does not have that problem and can
even be used to find out the size of the buffer you do need.
--
Flash Gordon
Sri Harsha Dandibhotla
> Sri Harsha Dandibhotla <harsha....@gmail.com> wrote:
>
> >you still have to create some silly buffer of some silly size.
>
> void *create_some_silly_buffer(size_t some_silly_size)
> {
> return malloc(some_silly_size);
>
> }
>
> :)
>
I like his asprintf better though..
if I were to concatenate multiple strings with my own formatted
strings thrown in middle, it is easier to simply use asprintf rather
than calculate size of each string and also my own formatted strings..
like for instance
sprintf(buf, "%s number1 is : %d number2 is %d %s", str1, random1,
random2, str2);
the numbers can have any number of digits.
Chris M. Thomasson
news:f1c71ada-8763-4b31...@v15g2000prn.googlegroups.com...
> thread A C Adventure, I have to recreate my utilities library of 1991,
> which I did because then (and now) one needs to use the printf
> approach to format data: but if one needs, as one often does need, to
> format to storage, sprintf has a built in danger that as far as I know
> (and correct me if I'm wrong) nobody has or will fix inside of C.
>
> The problem is that any sprintf whatsoever, insofar as it formats
> strings, has no control over string length. Most code I've seen
> decides to create some silly "buffer" of some silly size.
>
> But in
>
> sprintf(buf, "%s\n", ptr)
>
> characters past the allocated end of "buf" may be overwritten.
[...]
Check out this funny little hack:
_________________________________________________________________________
#include <stdio.h>
#include <stdarg.h>
#include <stdlib.h>
#include <assert.h>
static FILE* g_stdnull = NULL;
int
stdnull_init(void)
{
if (! g_stdnull)
{
g_stdnull = fopen("/dev/nul", "w");
if (! g_stdnull)
{
g_stdnull = fopen("nul", "w");
if (! g_stdnull)
{
return 0;
}
}
}
return 1;
}
void
stdnull_deinit(void)
{
if (g_stdnull)
{
fclose(g_stdnull);
g_stdnull = NULL;
}
}
int
get_sprintf_size(char const* format,
...)
{
int size;
va_list args;
va_start(args, format);
size = vfprintf(g_stdnull, format, args);
va_end(args);
return size;
}
int main(void)
{
if (stdnull_init())
{
int size = get_sprintf_size("%s %d\n", "Hello World", 123);
if (size) {
int xsize;
char* buffer = malloc(size + 1);
buffer[0] = '\0';
xsize = sprintf(buffer, "%s %d\n", "Hello World", 123);
assert(size == xsize);
printf("size(%d/%d) - %s", size, xsize, buffer);
free(buffer);
}
stdnull_deinit();
return EXIT_SUCCESS;
}
else
{
fprintf(stderr, "Could not open the NUL device!");
}
return EXIT_FAILURE;
}
_________________________________________________________________________
LOL! Well, it does work if you're platform supports something like the NUL
device. Here is the output I am getting:
size(16/16) - Hello World 123
AFAICT, this allows one to safely allocate a buffer that is guaranteed to be
large enough to hold the entire formatted string.
Any thoughts?
;^)
Chris M. Thomasson
news:h6ru1b$1c0t$1...@news.ett.com.ua...[...]
>
> LOL! Well, it does work if you're platform supports something like the NUL
> device.
Humm, I suppose you could also use a dummy file.
[...]
Chris M. Thomasson
Here is another version of the program which uses a temporary file as a
"fallback" just in case the file open fails with the standard names for some
platforms NUL device:
______________________________________________________________________
#include <stdio.h>
#include <stdarg.h>
#include <stdlib.h>
#include <assert.h>
static FILE* g_stdnull = NULL;
int
stdnull_init(void)
{
if (! g_stdnull)
{
g_stdnull = fopen("/dev/nul", "w");
if (! g_stdnull)
{
g_stdnull = fopen("nul", "w");
if (! g_stdnull)
{
g_stdnull = tmpfile();
if (! g_stdnull)
{
return 0;
}
}
}
}
return 1;
}
void
stdnull_deinit(void)
{
if (g_stdnull)
{
fclose(g_stdnull);
g_stdnull = NULL;
}
}
int
get_sprintf_size(char const* format,
...)
{
int size;
va_list args;
va_start(args, format);
size = vfprintf(g_stdnull, format, args);
va_end(args);
fseek(g_stdnull, 0, SEEK_SET);
return size;
}
int main(void)
{
if (stdnull_init())
{
int size = get_sprintf_size("%s %d\n", "Hello World", 123);
if (size) {
int xsize;
char* buffer = malloc(size + 1);
buffer[0] = '\0';
xsize = sprintf(buffer, "%s %d\n", "Hello World", 123);
assert(size == xsize);
printf("size(%d/%d) - %s", size, xsize, buffer);
free(buffer);
}
stdnull_deinit();
return EXIT_SUCCESS;
}
else
{
fprintf(stderr, "Could not open the NUL device!");
}
return EXIT_FAILURE;
}
______________________________________________________________________
Also, this version attempts to set the file pointer to the beginning of the
file after every call to `get_sprintf_size()'.
Ahhh, I do love the ability to hack some crap together in C. LOL!
;^)
Malcolm McLean
> strings, has no control over string length. Most code I've seen
> decides to create some silly "buffer" of some silly size.
>
> anymore. This is asprintf; its contract is to always allocate enough
> memory to hold the final string.
>
> anymore, and may never have been, for applications other than writing
> operating systems and compilers.
>
bytes or so for numeric fields, and count the length of strings.
To do it properly you have to parse the field values, of course. Then really
you need a vasprintf(), which entails an entire reimplementation of the
printf() engine. There's plenty of source on the web and it's not too hard
to modify it, but it is tedious and not something you ought to have to do.
I'm not sure what that says about C. Few other languages would make as easy
to reimplement basic functionality. On the other hand, you are right, it
shouldn't be a necessary job. (And a perverse implementation can always make
things harder by having million character pointer representations ).
For most applications vanilla sprintf() with a big buffer is good enough. It
just segfaults on a stupid input, like a name of over a thousand characters,
and that is acceptable. This behaviour is fine for my current programs, for
instance.
Richard Harter
Yes and no. He who barks at the moon has pointed to a real
problem; Rui asked if snprintf solves the problem. A fair answer
is yes and no, depending on how reads the tea leaves and the
original assertion.
The problem is that applying a format specification to a set of
arguments produces a string of unknown length. Snprintf "solves"
the problem by failing to complete the production of the output
string.
As you say, one can use snprintf to find out the size of the
buffer one does need; one way is to keep increasing the size of
the buffer until there is enough space. However this is not a
general solution - if the arguments are expressions with side
effects so that the output string changes each time we resize the
buffer. In short, the technique is a hack. None-the-less it
works most of the time. For that matter allocating a silly
ssized buffer works most of the time.
It would be useful if there were a sprintf variant that does not
require the user to supply a buffer but which takes care of
allocation and returns a pointer to the resulting formatted
string.
And, of course, snprintf isn't part of C90.
Malcolm McLean
"Flash Gordon" <sm...@spam.causeway.com> wrote in message
> Now read what Rui wrote. snprintf does not have that problem and can even
> be used to find out the size of the buffer you do need.
>
library functions shouldn't depend on malloc(), so the only possible
solution was to allow snprintf() to return the buffer length required if
passed a null pointer, making asprintf() a trival task to implement. If I've
got it right. My problem of course is that I can't use C99.
Chris M. Thomasson
> "Chris M. Thomasson" <n...@spam.invalid> wrote in message
> news:h6ru8q$1c1u$1...@news.ett.com.ua...
>> "Chris M. Thomasson" <n...@spam.invalid> wrote in message
>> news:h6ru1b$1c0t$1...@news.ett.com.ua...
>>> "spinoza1111" <spino...@yahoo.com> wrote in message
>> [...]
>>>
>>> LOL! Well, it does work if you're platform supports something like the
>>> NUL device.
>>
>> Humm, I suppose you could also use a dummy file.
>>
>>
>> [...]
>
>
> Here is another version of the program which uses a temporary file as a
> "fallback" just in case the file open fails with the standard names for
> some platforms NUL device:
[...]
Well, even though this is a crappy little hack, I should still check if
`malloc()' succeeds or not!
[...]
_________________________________________________________________________
int main(void)
{
if (stdnull_init())
{
int size = get_sprintf_size("%s %d\n", "Hello World", 123);
if (size) {
int xsize;
char* buffer = malloc(size + 1);
if (buffer)
{
buffer[0] = '\0';
xsize = sprintf(buffer, "%s %d\n", "Hello World", 123);
assert(size == xsize);
printf("size(%d/%d) - %s", size, xsize, buffer);
free(buffer);
}
else
{
fprintf(stderr, "Could not allocate %lu bytes!",
(unsigned long int)(size + 1));
}
}
stdnull_deinit();
return EXIT_SUCCESS;
}
else
{
fprintf(stderr, "Could not open the NUL device!");
}
return EXIT_FAILURE;
}
_________________________________________________________________________
Sorry about that NON-SENSE!
;^o
Chris M. Thomasson
> "Chris M. Thomasson" <n...@spam.invalid> wrote in message
> news:h6s000$1crc$1...@news.ett.com.ua...
>> "Chris M. Thomasson" <n...@spam.invalid> wrote in message
>> news:h6ru8q$1c1u$1...@news.ett.com.ua...
>>> "Chris M. Thomasson" <n...@spam.invalid> wrote in message
>>> news:h6ru1b$1c0t$1...@news.ett.com.ua...
>>>> "spinoza1111" <spino...@yahoo.com> wrote in message
>>> [...]
>>>>
>>>> LOL! Well, it does work if you're platform supports something like the
>>>> NUL device.
>>>
>>> Humm, I suppose you could also use a dummy file.
>>>
>>>
>>> [...]
>>
>>
>> Here is another version of the program which uses a temporary file as a
>> "fallback" just in case the file open fails with the standard names for
>> some platforms NUL device:
>
> [...]
>
> Well, even though this is a crappy little hack, I should still check if
> `malloc()' succeeds or not!
>
> [...]
>
ROFL!!!
I guess I should not return `EXIT_SUCCESS' when `malloc()' fails. Too funny!
;^)
[...]
BTW, how many of you find that the overall idea contained within the hack I
whipped up might be "useful"?
Chris M. Thomasson
news:Aoednehx95DZHgzX...@bt.com...
[...]
>
> For most applications vanilla sprintf() with a big buffer is good enough.
> It just segfaults on a stupid input, like a name of over a thousand
> characters, and that is acceptable. This behaviour is fine for my current
> programs, for instance.
seg-fault or viral outbreak?
Malcolm McLean
>> It just segfaults on a stupid input, like a name of over a thousand
>> characters, and that is acceptable. This behaviour is fine for my current
>> programs, for instance.
>
> seg-fault or viral outbreak?
compiler on the same system, with the same privileges as the program itself.
So a segfault or even corrupt output on silly input is acceptable. The worst
thing that could happen was that the output looked right but was in fact
corrupt, but the chances of that are so small, and the chances of another
bug being found in the code so high, since it is development/research
software, that it can be disregarded.
Richard Harter
That, too. The task of creating a well behaved snprintf is
rather more difficult than it seems at first sight. Neither of
Don Quixote's suggestions is well behaved because they
potentially require evaluating the arguments more than once.
What one needs to do is to resize dynamically as one scans the
argument. IIANM (but I often am) the %s specifier is the only
that is potentially unbounded, and one can do a strlen on
pointers. The game then is to break the format string into
pieces and evaluate a bound for the output size of each piece.
My impression is that it's doable but it's tricky.
jacob navia
>
> The problem is that applying a format specification to a set of
> arguments produces a string of unknown length. Snprintf "solves"
> the problem by failing to complete the production of the output
> string.
>
This is just not true. Before writing something like that
you could *read* the specs of snprintf!
The first time you do:
unsigned siz=1+snprintf(NULL,0,format_string,arg1,arg2,arg3);
char *buf = malloc(siz);
snprintf(buf,siz,format_string,arg1,arg2,arg3);
> As you say, one can use snprintf to find out the size of the
> buffer one does need; one way is to keep increasing the size of
> the buffer until there is enough space.
You should know better. Regulars are really spewing nonsense here.
[snip]
>
> Richard Harter, c...@tiac.net
> http://home.tiac.net/~cri, http://www.varinoma.com
> No one asks if a tree falls in the forest
> if there is no one there to see it fall.
Sure, but if the tree falls in a theater everybody sees it...
Ben Bacarisse
<snip>
> [...] IIANM (but I often am) the %s specifier is the only
> that is potentially unbounded,
using * as a width has the same property.
<snip>
--
Ben.
Richard Harter
<ja...@nospam.org> wrote:
>Richard Harter wrote:
>>
>> The problem is that applying a format specification to a set of
>> arguments produces a string of unknown length. Snprintf "solves"
>> the problem by failing to complete the production of the output
>> string.
>>
>
>
>This is just not true. Before writing something like that
>you could *read* the specs of snprintf!
I appreciate your comments, which are quite useful.
None-the-less what I said was true.
>
>The first time you do:
>
>unsigned siz=1+snprintf(NULL,0,format_string,arg1,arg2,arg3);
In this line of code snprintf fails to complete the production of
the output string. All it produces is the length of the string.
>char *buf = malloc(siz);
>snprintf(buf,siz,format_string,arg1,arg2,arg3);
Here, knowing the buffer size, snprintf can produce the output
string.
>
>
>> As you say, one can use snprintf to find out the size of the
>> buffer one does need; one way is to keep increasing the size of
>> the buffer until there is enough space.
>
>You should know better. Regulars are really spewing nonsense here.
I indeed should have read the spec. Again, however, what I said
was true. Your code does multiple passes (actually only 2) until
it has increased the buffer size until there is enough space.
I must admit that I was thinking of doubling the space until one
got enough space. If I had read the spec in advance (I don't use
C99) I hope I would have suggested the code you suggested.
All of that said, calling snprintf twice is still a hack because
every argument gets evaluated twice.
Richard Harter
Ooops, so it does. There probably is some other little nasty in
there to complicate things.
Willem
) "The problem is that any sprintf whatsoever, insofar as it formats
) strings, has no control over string length. Most code I've seen
) decides to create some silly "buffer" of some silly size. "
)
) you still have to create some silly buffer of some silly size.
snprintf returns the number of characters that would have been printed.
This enables you to exactly allocate the amount of memory needed.
asprintf is probably implemented on top of snprintf.
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
bartc
"jacob navia" <ja...@nospam.org> wrote in message
news:h6s9es$dnk$1...@aioe.org...
> Richard Harter wrote:
>>
>> The problem is that applying a format specification to a set of
>> arguments produces a string of unknown length. Snprintf "solves"
>> the problem by failing to complete the production of the output
>> string.
>>
>
>
> This is just not true. Before writing something like that
> you could *read* the specs of snprintf!
>
> The first time you do:
>
> unsigned siz=1+snprintf(NULL,0,format_string,arg1,arg2,arg3);
> char *buf = malloc(siz);
> snprintf(buf,siz,format_string,arg1,arg2,arg3);
You're evaluating each argument twice. Unless you store each argument into a
simple variable first, it's possible the size of the output can change. And
he mentioned side-effects which can have further impact.
As an example of the former problem, imagine a function getmonthname(),
executed an instant before midnight on 31-Aug. The first call will produce
"August" while the second could well produce "September", which is 3
characters longer.
And this is not necessarily fixed by storing a char*, you may need to copy
the full string.
--
Bartc
Chris M. Thomasson
>>
>> The problem is that applying a format specification to a set of
>> arguments produces a string of unknown length. Snprintf "solves"
>> the problem by failing to complete the production of the output
>> string.
>>
>
>
> This is just not true. Before writing something like that
> you could *read* the specs of snprintf!
>
> The first time you do:
>
> unsigned siz=1+snprintf(NULL,0,format_string,arg1,arg2,arg3);
> char *buf = malloc(siz);
> snprintf(buf,siz,format_string,arg1,arg2,arg3);
Should that be something like:
_________________________________________________________________
int size = snprintf(NULL,0,format_string,arg1,arg2,arg3);
if (size > -1)
{
char* buf;
++size;
buf = malloc(size);
if (buf)
{
snprintf(buf,siz,format_string,arg1,arg2,arg3);
/* [...]; */
free(buf);
}
}
_________________________________________________________________
?
[...]
Chris M. Thomasson
news:auikm.71256$OO7....@text.news.virginmedia.com...
you would need to copy the string if `getmonthname()' returned a pointer to
a buffer that can be changed by some other locus of control/mysterious
force. For instance:
______________________________________________________________________
char const* getmonthname(void)
{
static char buffer[100] = { '\0' };
/* calc month name; store in `buffer' */
return buffer;
}
void foo()
{
char const* monthname = getmonthname();
int size = snprintf(NULL, 0, "%s", monthname);
if (size > -1)
{
char* buf;
++size;
buf = malloc(size);
if (buf)
{
int xsize = snprintf(buf, size, "%s", monthname);
if (size != xsize)
{
puts("OH SH%T! the buffer was changed by something!!!");
if (xsize > size)
{
puts("OH FUC%! we are DOOMED!!!!!!");
}
}
free(buf);
}
}
}
______________________________________________________________________
Moi
> On Sun, 23 Aug 2009 19:03:27 +0100, "Malcolm McLean"
> <regn...@btinternet.com> wrote:
>
>
>>"Flash Gordon" <sm...@spam.causeway.com> wrote in message
>>> Now read what Rui wrote. snprintf does not have that problem and can
>>> even be used to find out the size of the buffer you do need.
>>>
>>It is actually the only answer. For some reason the decision was taken
>>that library functions shouldn't depend on malloc(), so the only
>>possible solution was to allow snprintf() to return the buffer length
>>required if passed a null pointer, making asprintf() a trival task to
>>implement. If I've got it right. My problem of course is that I can't
>>use C99.
>
> That, too. The task of creating a well behaved snprintf is rather more
> difficult than it seems at first sight. Neither of Don Quixote's
> suggestions is well behaved because they potentially require evaluating
> the arguments more than once. What one needs to do is to resize
> dynamically as one scans the argument. IIANM (but I often am) the %s
> specifier is the only that is potentially unbounded, and one can do a
> strlen on pointers. The game then is to break the format string into
> pieces and evaluate a bound for the output size of each piece. My
> impression is that it's doable but it's tricky.
A nice hack IMHO to implement snprintf() on systems where it is not
available,
is tho fprintf() to a file, and read back the answer. This will only need
one pass, and the arguments are only evaluated once.
On a unix-like systems, the file can even be unlinked after creation.
Since all of the printing takes place in OS-buffers, this will be almost
optimal.
AvK
Chris M. Thomasson
news:40f7e$4a91b9bd$5350c024$31...@cache120.multikabel.net...
[...]
> A nice hack IMHO to implement snprintf() on systems where it is not
> available,
> is tho fprintf() to a file, and read back the answer. This will only need
> one pass, and the arguments are only evaluated once.
>
> On a unix-like systems, the file can even be unlinked after creation.
> Since all of the printing takes place in OS-buffers, this will be almost
> optimal.
That's basically what I did here except I used `vfprintf()':
bartc
"Chris M. Thomasson" <n...@spam.invalid> wrote in message
Yes. And that is not impossible as the rest of your reply suggests.
--
Bartc
Chris M. Thomasson
It's definitely not impossible. Well, perhaps improbable, but not
impossible.
Chris McDonald
<tripe snipped>
>This alone demonstrates that C is not a viable programming language
>anymore, and may never have been, for applications other than writing
>operating systems and compilers.
So (after 26 follow-up articles, so far) this wasn't really
a "C showstopper" after all, as far as the C languages goes.
We've seen that pre-C99 solutions are possible, if cumbersome, and
that C99 solutions are quite reasonable. C remains a viable language,
and those of us who don't shout "Fire" as soon as our comprehension is
challenged can get back to C programming.
>I'm suspending work on the "adventure" project and shall return when
>I'm not so disgusted as I am now.
... but, hopefully, it will be a "Spinoza showstopper".
--
Chris.
bartc
> "bartc" <ba...@freeuk.com> wrote in message
> news:zVikm.71266$OO7....@text.news.virginmedia.com...
>>
>> "Chris M. Thomasson" <n...@spam.invalid> wrote in message
>> news:h6sd3r$1i48$1...@news.ett.com.ua...
>>> "bartc" <ba...@freeuk.com> wrote in message
>>> news:auikm.71256$OO7....@text.news.virginmedia.com...
>>>>
>>>> "jacob navia" <ja...@nospam.org> wrote in message
>>>> news:h6s9es$dnk$1...@aioe.org...
>>>>> unsigned siz=1+snprintf(NULL,0,format_string,arg1,arg2,arg3);
>>>>> char *buf = malloc(siz);
>>>>> snprintf(buf,siz,format_string,arg1,arg2,arg3);
>>>>
>>>> You're evaluating each argument twice. Unless you store each
>>>> argument into a simple variable first, it's possible the size of
>>>> the output can change. And he mentioned side-effects which can
>>>> have further impact. As an example of the former problem, imagine a
>>>> function
>>>> getmonthname(), executed an instant before midnight on 31-Aug. The
>>>> first call will produce "August" while the second could well
>>>> produce "September", which is 3 characters longer.
>>>>
>>>> And this is not necessarily fixed by storing a char*, you may need
>>>> to copy the full string.
>>>
>>> you would need to copy the string if `getmonthname()' returned a
>>> pointer to a buffer that can be changed by some other locus of
>>> control/mysterious force.
>>
>> Yes. And that is not impossible as the rest of your reply suggests.
>
> It's definitely not impossible. Well, perhaps improbable, but not
> impossible.
I can think of half-a-dozen ways the result of getmonthname() (or whatever
function) can change between two successive calls. For a start, the string
can come from a file. On the next call, the file contents might be
different.
If the string points to the contents of a memory-mapped device, those
contents again can change between calls.
The string might simply point into some shared memory, especially on a
simple microprocessor system, where some interrupt or other can change the
contents.
If you added an extra argument to your snprintf call, one with side-effects,
yet again there's another way for the string to be changed! Although
side-effects can more directly cause problems anyway.
The string can be the result of character-recognising part of the screen, or
speech-to-text conversion, or just text streaming from stdin!
Is that six ways yet? At least.
--
Bartc
Chris M. Thomasson
> Chris M. Thomasson wrote:
[...]
>> It's definitely not impossible. Well, perhaps improbable, but not
>> impossible.
>
> I can think of half-a-dozen ways the result of getmonthname() (or whatever
> function) can change between two successive calls. For a start, the string
> can come from a file. On the next call, the file contents might be
> different.
>
> If the string points to the contents of a memory-mapped device, those
> contents again can change between calls.
>
> The string might simply point into some shared memory, especially on a
> simple microprocessor system, where some interrupt or other can change the
> contents.
>
> If you added an extra argument to your snprintf call, one with
> side-effects, yet again there's another way for the string to be changed!
> Although side-effects can more directly cause problems anyway.
>
> The string can be the result of character-recognising part of the screen,
> or speech-to-text conversion, or just text streaming from stdin!
>
> Is that six ways yet? At least.
Don't you think that this aspect of said function would have the behavior
explicitly documented? Otherwise, it's return value is completely useless
because it's going to be subjected to race-conditions. Think about it for a
moment.
char* month = getmonthname();
puts(month);
How can you be sure that the output will be coherent? What good what a
crappy function that like be? Unless, you could do something like:
char* month = getmonthname();
getmonthname_lock();
puts(month);
getmonthname_unlock();
This is why I say that a function that behaves like that is improbable, or a
very crappy design.
Chris M. Thomasson
[...]
>
> char* month = getmonthname();
> getmonthname_lock();
> puts(month);
> getmonthname_unlock();
>
______________________________________________________________________
void foo()
{
int size;
getmonthname_lock();
size = snprintf(NULL, 0, "%s", getmonthname());
if (size > -1)
{
char* buf;
++size;
buf = malloc(size);
if (buf)
{
int xsize = snprintf(buf, size, "%s", getmonthname());
getmonthname_unlock();
if (size != xsize)
{
puts("OH SH%T! the buffer was changed by something!!!");
if (xsize > size)
{
puts("OH FUC%! we are DOOMED!!!!!!");
}
}
free(buf);
}
}
else
{
getmonthname_unlock();
}
}
______________________________________________________________________
Don't you think a function that returned a buffer which can be mutated on
the fly would provide the user a method that would allow her/him to perform
atomic operations on said buffer? Otherwise, what good would it be?
bartc
"Chris M. Thomasson" <n...@spam.invalid> wrote in message
> "bartc" <ba...@freeuk.com> wrote in message
> news:7gjkm.71273$OO7....@text.news.virginmedia.com...
>> Chris M. Thomasson wrote:
> [...]
>>> It's definitely not impossible. Well, perhaps improbable, but not
>>> impossible.
>>
>> I can think of half-a-dozen ways the result of getmonthname() (or
>> whatever function) can change between two successive calls. For a start,
>> the string can come from a file. On the next call, the file contents
>> might be different.
>>
>> If the string points to the contents of a memory-mapped device, those
>> contents again can change between calls.
>>
>> The string might simply point into some shared memory, especially on a
>> simple microprocessor system, where some interrupt or other can change
>> the contents.
> Don't you think that this aspect of said function would have the behavior
> explicitly documented? Otherwise, it's return value is completely useless
> because it's going to be subjected to race-conditions. Think about it for
> a moment.
>
>
> char* month = getmonthname();
>
> puts(month);
>
>
> How can you be sure that the output will be coherent? What good what a
> crappy function that like be? Unless, you could do something like:
>
>
> char* month = getmonthname();
> getmonthname_lock();
> puts(month);
> getmonthname_unlock();
>
>
>
> This is why I say that a function that behaves like that is improbable, or
> a very crappy design.
Perhaps I used an over-elaborate example for the snprintf() issue.
itoa(rand()) might have been simpler...
Getting back to getmonthname() and deriving the value from a memory-mapped
device ram for example. Even assuming all your safeguards are in place, it's
possible that such a function will read the string from the device memory
while the device is locked, copy it to a static area, and return a pointer
to that.
It will still be the case that a subsequent getmonthname() call could
produce a different string, unless the locks are done at the higher-level.
But the user of snprintf() and getmonthname() should not need to bother with
that. He only needs to know that a call to getmonthname() in August will
produce a different value to a call made in September.
--
Bartc
Flash Gordon
> On Sun, 23 Aug 2009 17:14:16 +0100, Flash Gordon
> <sm...@spam.causeway.com> wrote:
>
>> Sri Harsha Dandibhotla wrote:
>>> On Aug 23, 6:33 pm, Rui Maciel <rui.mac...@gmail.com> wrote:
>>>> spinoza1111 wrote:
>>>>> The problem is that any sprintf whatsoever, insofar as it formats
>>>>> strings, has no control over string length.
>>>> What about snprintf() ?
>>>>
>>>> Rui Maciel
>>> "The problem is that any sprintf whatsoever, insofar as it formats
>>> strings, has no control over string length. Most code I've seen
>>> decides to create some silly "buffer" of some silly size. "
>>>
>>> you still have to create some silly buffer of some silly size.
>> Now read what Rui wrote. snprintf does not have that problem and can
>> even be used to find out the size of the buffer you do need.
>
> Yes and no. He who barks at the moon has pointed to a real
> problem; Rui asked if snprintf solves the problem. A fair answer
> is yes and no, depending on how reads the tea leaves and the
> original assertion.
I would read what he wrote as suggesting using snprintf to solve the
problem. Mind you, thinking about it, vsnprintf might be more useful...
> The problem is that applying a format specification to a set of
> arguments produces a string of unknown length. Snprintf "solves"
> the problem by failing to complete the production of the output
> string.
Which allows you to solve the problem in one of the two ways the OP
suggested.
> As you say, one can use snprintf to find out the size of the
> buffer one does need; one way is to keep increasing the size of
> the buffer until there is enough space. However this is not a
> general solution - if the arguments are expressions with side
> effects so that the output string changes each time we resize the
> buffer. In short, the technique is a hack. None-the-less it
> works most of the time. For that matter allocating a silly
> ssized buffer works most of the time.
Check the return value and save yourself all of that work. Actually, I
would use vsnprintf and wrap it in a function which solves the
multiple-evaluation problem.
> It would be useful if there were a sprintf variant that does not
> require the user to supply a buffer but which takes care of
> allocation and returns a pointer to the resulting formatted
> string.
There is, it's called snprintf.
> And, of course, snprintf isn't part of C90.
True. However, the OP alluded to it not solving the problem, where as it
does actually provide a solution.
--
Flash Gordon
Chris M. Thomasson
Granted.
> Getting back to getmonthname() and deriving the value from a memory-mapped
> device ram for example. Even assuming all your safeguards are in place,
> it's
> possible that such a function will read the string from the device memory
> while the device is locked, copy it to a static area, and return a pointer
> to that.
>
> It will still be the case that a subsequent getmonthname() call could
> produce a different string, unless the locks are done at the higher-level.
Yes, yes:
getmonthname_lock();
char* month1 = getmonthname();
char* month2 = getmonthname();
assert(! strcmp(month1, month2));
getmonthname_unlock();
I would expect that the assertion would always pass.
> But the user of snprintf() and getmonthname() should not need to bother
> with that. He only needs to know that a call to getmonthname() in August
> will produce a different value to a call made in September.
That's still a race condition waiting to happen if it returns a pointer to
some internal static buffer. If the locking is not used, one might get an
output of:
Augtember
or some incoherent output.
Chris M. Thomasson
> Richard Harter wrote:
[...]
>> It would be useful if there were a sprintf variant that does not
>> require the user to supply a buffer but which takes care of
>> allocation and returns a pointer to the resulting formatted
>> string.
>
> There is, it's called snprintf.
I believe it's called `asprintf'
spinoza1111
> spinoza1111wrote:
> > The problem is that any sprintf whatsoever, insofar as it formats
> > strings, has no control over string length.
>
> What about snprintf() ?
I covered that as C99's answer. C99's answer is no good. You replace
the possibility of memory overwrites with the possibility of something
that can be EVEN WORSE.
This is the error no-one sees, where an snprintf truncates silently.
This type of error normally affects the end-user, including clients of
systems whose information is destroyed (such as military veterans
trying to get medical care, whose forms fail to include the required
information). C programmers might think it's cute to truncate. I
don't.
>
> Rui Maciel
spinoza1111
wrote:
> On Aug 23, 6:33 pm, Rui Maciel <rui.mac...@gmail.com> wrote:
>
> >spinoza1111wrote:
> > > The problem is that any sprintf whatsoever, insofar as it formats
> > > strings, has no control over string length.
>
> > What about snprintf() ?
>
>
> "The problem is that any sprintf whatsoever, insofar as it formats
> decides to create some silly "buffer" of some silly size. "
>
> you still have to create some silly buffer of some silly size.
Correctomundo. As soon as a programmer starts yapping about creating a
"buffer" you know he's a dork.
spinoza1111
> Rui Maciel wrote:
> >spinoza1111wrote:
>
> >> The problem is that any sprintf whatsoever, insofar as it formats
> >> strings, has no control over string length.
>
> > What about snprintf() ?
>
> provides exactly the tool he needs to implement what he wants whilst
> also providing the flexibility to do other things.
Hey, CREEP, reply to the poster whose points you're addressing or
don't post. You're wrong, and at this point outvoted. The wikipedia
points out the problem you don't see as does another poster. Clearly,
your software is fulla "buffers" which silently overflow and no-one's
the wiser.
> --
> Flash Gordon
spinoza1111
> Sri Harsha Dandibhotla wrote:
> > On Aug 23, 6:33 pm, Rui Maciel <rui.mac...@gmail.com> wrote:
> >>spinoza1111wrote:
> >>> The problem is that any sprintf whatsoever, insofar as it formats
> >>> strings, has no control over string length.
> >> What about snprintf() ?
>
>
> > "The problem is that any sprintf whatsoever, insofar as it formats
> > decides to create some silly "buffer" of some silly size. "
>
> > you still have to create some silly buffer of some silly size.
>
> even be used to find out the size of the buffer you do need.
(Sigh). How do you know the size of the "buffer" you do need? You're
already in a mess, Flash, because you think the software can
predetermine the size! Go join Twitter.
> --
> Flash Gordon
spinoza1111
> On Sun, 23 Aug 2009 17:14:16 +0100, Flash Gordon
>
>
>
>
>
> <s...@spam.causeway.com> wrote:
> >Sri Harsha Dandibhotla wrote:
> >> On Aug 23, 6:33 pm, Rui Maciel <rui.mac...@gmail.com> wrote:
> >>>spinoza1111wrote:
> >>>> The problem is that any sprintf whatsoever, insofar as it formats
> >>>> strings, has no control over string length.
> >>> What about snprintf() ?
>
> >>> Rui Maciel
>
> >> "The problem is that any sprintf whatsoever, insofar as it formats
> >> strings, has no control over string length. Most code I've seen
> >> decides to create some silly "buffer" of some silly size. "
>
> >> you still have to create some silly buffer of some silly size.
>
> >Now read what Rui wrote. snprintf does not have that problem and can
> >even be used to find out the size of the buffer you do need.
>
Hey, CREEP, I'll thank you to use my name when you use my
contributions. It's spinoza1111.
> problem; Rui asked if snprintf solves the problem. A fair answer
> is yes and no, depending on how reads the tea leaves and the
A fair answer is NO.
> original assertion.
>
> The problem is that applying a format specification to a set of
> arguments produces a string of unknown length. Snprintf "solves"
> the problem by failing to complete the production of the output
> string.
>
> As you say, one can use snprintf to find out the size of the
> buffer one does need; one way is to keep increasing the size of
> the buffer until there is enough space. However this is not a
> general solution - if the arguments are expressions with side
> effects so that the output string changes each time we resize the
> buffer. In short, the technique is a hack. None-the-less it
> works most of the time. For that matter allocating a silly
> ssized buffer works most of the time.
>
> It would be useful if there were a sprintf variant that does not
> require the user to supply a buffer but which takes care of
> allocation and returns a pointer to the resulting formatted
> string.
There is, and I mentioned it in the OP. It's asprintf, and I
implemented it in 1991. It's available in the GNU compiler. My code
wasn't a "hack". It was a documented solution which keeps on
mallocing, freeing the malloc, and mallocing again until the sprintf
is completed or the remalloc fails.
The problem is that "C", it is clear from this discussion alone, isn't
a singular programming language at all. It's a set of options and
praxis.
Praxis (day to day practice in groups) is part of any language, but a
formal language needs to minimize it. C fails to do so.
>
> And, of course, snprintf isn't part of C90.
>
> Richard Harter, c...@tiac.nethttp://home.tiac.net/~cri,http://www.varinoma.com
> No one asks if a tree falls in the forest
> if there is no one there to see it fall.- Hide quoted text -
>
> - Show quoted text -
spinoza1111
> "Chris M. Thomasson" <n...@spam.invalid> wrote in messagenews:h6s0ki$1d3g$1...@news.ett.com.ua...
>
>
>
>
>
> > "Chris M. Thomasson" <n...@spam.invalid> wrote in message
> >> "Chris M. Thomasson" <n...@spam.invalid> wrote in message
> >>> "Chris M. Thomasson" <n...@spam.invalid> wrote in message
> >>>> "spinoza1111" <spinoza1...@yahoo.com> wrote in message
> >>> [...]
>
> >>>> LOL! Well, it does work if you're platform supports something like the
> >>>> NUL device.
>
> >>> Humm, I suppose you could also use a dummy file.
>
> >>> [...]
>
> >> Here is another version of the program which uses a temporary file as a
> >> "fallback" just in case the file open fails with the standard names for
> >> some platforms NUL device:
>
> > [...]
>
> > Well, even though this is a crappy little hack, I should still check if
> > `malloc()' succeeds or not!
>
> > [...]
>
> ROFL!!!
>
> I guess I should not return `EXIT_SUCCESS' when `malloc()' fails. Too funny!
>
> ;^)
>
> [...]
>
> BTW, how many of you find that the overall idea contained within the hack I
> whipped up might be "useful"?- Hide quoted text -
I implemented it in 1991, kid. So it's useful. Now all you have to do
is change variables to Hungarian and write literate comments as I did.
spinoza1111
> spinoza1111<spinoza1...@yahoo.com> writes:
>
> <tripe snipped>
>
> >This alone demonstrates that C is not a viable programming language
> >anymore, and may never have been, for applications other than writing
> >operating systems and compilers.
>
> So (after 26 follow-up articles, so far) this wasn't really
> a "C showstopper" after all, as far as the C languages goes.
>
> We've seen that pre-C99 solutions are possible, if cumbersome, and
> that C99 solutions are quite reasonable. C remains a viable language,
> and those of us who don't shout "Fire" as soon as our comprehension is
> challenged can get back to C programming.
I'm afraid your comprehension is challenged, cowboy.
I saw the problem in 1991 and wrote an asprintf as part of a library
of code to address each deficiency of C wrt each problem I
encountered. I tested this library in full. I documented it in full.
I'm looking at having to do the same today all over again since in the
intervening years the problem hasn't been solved by the C community,
which prefers to jerk its collective pud off and hound Herb Schildt.
All you're saying, cowboy, is that "any" problem can be solved by C in
Turing's sense. But as we know, this is bullshit.
>
> >I'm suspending work on the "adventure" project and shall return when
> >I'm not so disgusted as I am now.
>
> ... but, hopefully, it will be a "Spinoza showstopper".
Fuck you, asshole.
>
> --
> Chris.
Chris M. Thomasson
news:0a64e79d-bd5d-4419...@m3g2000pri.googlegroups.com...
On Aug 24, 2:12 am, "Chris M. Thomasson" <n...@spam.invalid> wrote:
> > "Chris M. Thomasson" <n...@spam.invalid> wrote in
> > messagenews:h6s0ki$1d3g$1...@news.ett.com.ua...
> >
> > BTW, how many of you find that the overall idea contained within the
> > hack I
> > whipped up might be "useful"?- Hide quoted text -
> I implemented it in 1991, kid.
Hey, thanks for the compliment! You know, it still makes my day when
somebody wants to check my ID when I am purchasing alcohol.
;^)
> So it's useful.
Agreed.
> Now all you have to do is change variables to Hungarian
There can be a "downside" to Hungarian notation. This is very contrived
example of course but it could possibly happen. Think of prefixing a bunch
of signed int variables with 'int' (e.g., `intMyVar'). Then for whatever
reason you decide to change them to unsigned variables. Well, you're going
to have to change every variable name's prefix to `uint' or something that
represents the variables unsigndness, so to speak.
> and write literate comments as I did.
:^)
spinoza1111
> "Flash Gordon" <s...@spam.causeway.com> wrote in message
>
> news:s7r8m6x...@news.flash-gordon.me.uk...
>
> > Richard Harter wrote:
> [...]
> >> It would be useful if there were a sprintf variant that does not
> >> require the user to supply a buffer but which takes care of
> >> allocation and returns a pointer to the resulting formatted
> >> string.
>
> > There is, it's called snprintf.
>
> I believe it's called `asprintf'
asprintf isn't available on all compilers. C isn't portable. To write
portable C, you have to reinvent the wheel. To reinvent the wheel
properly, you need to be able to write English in addition to
effective C, and very few people here have the ability to construct a
complex sentence.
To construct an asprintf, you must construct it on top of an snprintf
if you're using a C99 compliant compiler, or else either recreate the
logic of printf. You have to scan for percents and sum the length of
strings and determine the string length of numbers. I suppose you
could use Malcolm's value of 30.
You then have to stress test.
To use the "hacks" presented here, you have to read the code line by
line to make sure the hacker hasn't fucked up. As a personal matter, I
don't like to read most code written by others, since their aesthetic
is usually not mine (I found John Nash's code most pleasant on the
other hand). I'd rather code my own, with longer identifiers and
overall a more elegant way of expression...not that it's perfect and
bug free.
C is great in worlds without strings. That would be an operating
system kernel. If you want to write C, learn how to develop operating
systems. Don't mess up military veterans' benefits, small businesses,
or schools with this language.
>
>
>
> >> And, of course, snprintf isn't part of C90.
>
> > True. However, the OP alluded to it not solving the problem, where as it
> > does actually provide a solution.- Hide quoted text -
Chris M. Thomasson
On Aug 24, 7:15 am, "Chris M. Thomasson" <n...@spam.invalid> wrote:
> > "Flash Gordon" <s...@spam.causeway.com> wrote in message
> >
> > news:s7r8m6x...@news.flash-gordon.me.uk...
> >
> > > Richard Harter wrote:
> > [...]
> > >> It would be useful if there were a sprintf variant that does not
> > >> require the user to supply a buffer but which takes care of
> > >> allocation and returns a pointer to the resulting formatted
> > >> string.
> >
> > > There is, it's called snprintf.
> >
> > I believe it's called `asprintf'
> asprintf isn't available on all compilers.
Yeah, I know. Too bad it's not. Oh well, shi% happens.
> C isn't portable. To write
> portable C, you have to reinvent the wheel. To reinvent the wheel
> properly, you need to be able to write English in addition to
> effective C, and very few people here have the ability to construct a
> complex sentence.
> To construct an asprintf, you must construct it on top of an snprintf
> if you're using a C99 compliant compiler, or else either recreate the
> logic of printf. You have to scan for percents and sum the length of
> strings and determine the string length of numbers. I suppose you
> could use Malcolm's value of 30.
> You then have to stress test.
Well, you don't really have to recreate `printf()'. You can use the hack
code I presented here:
http://clc.pastebin.com/f31279cba
It's certainly easier than recreating `printf()'. Whether or not it's
actually practical, well, that another matter.
> To use the "hacks" presented here, you have to read the code line by
> line to make sure the hacker hasn't fucked up.
;^)
> As a personal matter, I
> don't like to read most code written by others, since their aesthetic
> is usually not mine (I found John Nash's code most pleasant on the
> other hand). I'd rather code my own, with longer identifiers and
> overall a more elegant way of expression...not that it's perfect and
> bug free.
> C is great in worlds without strings. That would be an operating
> system kernel. If you want to write C, learn how to develop operating
> systems.
Well, I have to use a low-level language like C for some things that are not
related to kernel programming.
> Don't mess up military veterans' benefits, small businesses,
> or schools with this language.
Yikes!
Chris M. Thomasson
[...]
> > It would be useful if there were a sprintf variant that does not
> > require the user to supply a buffer but which takes care of
> > allocation and returns a pointer to the resulting formatted
> > string.
> There is, and I mentioned it in the OP. It's asprintf, and I
> implemented it in 1991. It's available in the GNU compiler. My code
> wasn't a "hack".
I am not sure I would call the following pseudo-code examples "hacks":
http://groups.google.com/group/comp.lang.c/msg/530d1bd4156e1927
http://groups.google.com/group/comp.lang.c/msg/169710a0cea76ce8
Now, yes, I agree that the following is a hack:
http://clc.pastebin.com/f31279cba
> It was a documented solution which keeps on
> mallocing, freeing the malloc, and mallocing again until the sprintf
> is completed or the remalloc fails.
It's a shame that you basically had to re-implement the internal machinery
of `printf()'.
Chris McDonald
>I'm afraid your comprehension is challenged, cowboy.
Wow! Someone take "your" seat on the ferry, again, Ed?
<more tripe snipped>
Perhaps your BFF Herb has already written the solution for you.
You could always commune with him, and you your apprise himm of how often
he's discussed here?
>All you're saying, cowboy, is that "any" problem can be solved by C in
>Turing's sense. But as we know, this is bullshit.
No, I didn't say that - are you reading impaired too?
Don't, for a minute, claim to state what I said
(or to parody your style "don't you lecture me").
>> >I'm suspending work on the "adventure" project and shall return when
>> >I'm not so disgusted as I am now.
>>
>> ... but, hopefully, it will be a "Spinoza showstopper".
>Fuck you, asshole.
Just grow up Ed, else we'll all treat you like the trolling fool that you are.
--
Chris.
Keith Thompson
> spinoza1111 <spino...@yahoo.com> writes:
[more of the same]
> Just grow up Ed, else we'll all treat you like the trolling fool
> that you are.
Chris, what exactly is stopping you from treating him like the
trolling fool that he is now?
He's not going to change his behavior. You can. Please stop
feeding the troll.
--
Keith Thompson (The_Other_Keith) ks...@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"
spinoza1111
> "spinoza1111" <spinoza1...@yahoo.com> wrote in message
>
> news:5bbfaa15-5d6a-4196...@y10g2000prg.googlegroups.com...
> [...]
>
> > > It would be useful if there were a sprintf variant that does not
> > > require the user to supply a buffer but which takes care of
> > > allocation and returns a pointer to the resulting formatted
> > > string.
> > There is, and I mentioned it in the OP. It's asprintf, and I
> > implemented it in 1991. It's available in the GNU compiler. My code
> > wasn't a "hack".
>
> I am not sure I would call the following pseudo-code examples "hacks":
>
> http://groups.google.com/group/comp.lang.c/msg/530d1bd4156e1927
>
> http://groups.google.com/group/comp.lang.c/msg/169710a0cea76ce8
>
> Now, yes, I agree that the following is a hack:
>
> http://clc.pastebin.com/f31279cba
>
> > It was a documented solution which keeps on
> > mallocing, freeing the malloc, and mallocing again until the sprintf
> > is completed or the remalloc fails.
>
> It's a shame that you basically had to re-implement the internal machinery
> of `printf()'.
Yes, it's a crying shame that I had to do it over and do it right. And
C is such a great language, too!
>
>
>
> > The problem is that "C", it is clear from this discussion alone, isn't
> > a singular programming language at all. It's a set of options and
> > praxis.
> > Praxis (day to day practice in groups) is part of any language, but a
> > formal language needs to minimize it. C fails to do so.- Hide quoted text -
spinoza1111
> Chris McDonald <ch...@csse.uwa.edu.au> writes:
> [more of the same]
> > Just grow up Ed, else we'll all treat you like the trolling fool
> > that you are.
>
> Chris, what exactly is stopping you from treating him like the
> trolling fool that he is now?
>
> He's not going to change his behavior. You can. Please stop
> feeding the troll.
As I have said, the grammar of "troll" is isomorphic to "Jew" in anti-
Semitic tracts. It derives from Nordic racist texts, and it fulfills
here the function of racism: unifying the community against the
outsider, no matter how that outsider is marked...here by his ability
to write above a small lower bound of complexity in an unusual
combination with programming skill somewhat above the norm, and the
fact that he was programming C when you were shitting your pants.
Your use of "trolling" is itself "trolling" by your own definition,
since you dishonestly address another with a comment about me in order
to elicit a response from me.
You assert your membership in a community dishonestly by labeling a
person who has raised a valid technical flaw in C for discussion,
because you either don't have the skills to address this problem, or
else you're afraid of bullying if your solution has been found in
error.
spinoza1111
> "spinoza1111" <spinoza1...@yahoo.com> wrote in message
Boo hoo. What, are you still using edlin to edit? In a modern editor,
case-sensitively changing int to uint while examining each change is
baby stuff. You can use a regex to automate the change.
I used systematic naming conventions in IBM 1401 SPS, when my editor
was an IBM 026 keypunch. You young whippersnappers moan and groan
about having to change things using fancy editors. I used to have to
walk to the computer center in the snow uphill both ways (etc.)
Chris McDonald
>Chris McDonald <ch...@csse.uwa.edu.au> writes:
>> spinoza1111 <spino...@yahoo.com> writes:
>[more of the same]
>> Just grow up Ed, else we'll all treat you like the trolling fool
>> that you are.
>Chris, what exactly is stopping you from treating him like the
>trolling fool that he is now?
>He's not going to change his behavior. You can. Please stop
>feeding the troll.
Ed trolling to hear the sound of his own voice is one thing,
but Ed's throwing hissy fits and abusing people is another.
Sorry Keith, but it's not your newsgroup, either.
--
Chris.
Richard Harter
<spino...@yahoo.com> wrote:
>On Aug 24, 1:58=A0am, c...@tiac.net (Richard Harter) wrote:
>> On Sun, 23 Aug 2009 17:14:16 +0100, Flash Gordon
>>
>> Yes and no. He who barks at the moon has pointed to a real
>
>Hey, CREEP, I'll thank you to use my name when you use my
>contributions. It's spinoza1111.
Spinoza1111 is the name associated with your postings. According
to rumor, that barking dog, the name endowed upon you by your
parents is Edward Nilges. However your true name, the one is your
very essence, is He who barks at the moon. Deal with it.
>There is, and I mentioned it in the OP. It's asprintf, and I
>implemented it in 1991. It's available in the GNU compiler. My code
>wasn't a "hack". It was a documented solution which keeps on
>mallocing, freeing the malloc, and mallocing again until the sprintf
>is completed or the remalloc fails.
The trouble is that neither of the two methods that you mentioned
are entirely satisfactory because they require re-evaluating the
arguments. I expect that you will immediately appreciate why
this is problematic. I have no idea what the GNU code does but I
wouldn't be surprised if they put a layer on top of snprintf.
Richard Harter, c...@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
Richard Harter
<spino...@yahoo.com> wrote:
>On Aug 24, 8:27=A0am, "Chris M. Thomasson" <n...@spam.invalid> wrote:
>> "spinoza1111" <spinoza1...@yahoo.com> wrote in message
>> > It was a documented solution which keeps on
>> > mallocing, freeing the malloc, and mallocing again until the sprintf
>> > is completed or the remalloc fails.
And if you documented the code it must be okay.
I checked the gnu implmentation and they do the double evaluation
also. There's simply clay feet everywhere.
Richard Harter, c...@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
Chris M. Thomasson
news:h6s000$1crc$1...@news.ett.com.ua...
> "Chris M. Thomasson" <n...@spam.invalid> wrote in message
> news:h6ru8q$1c1u$1...@news.ett.com.ua...
>> "Chris M. Thomasson" <n...@spam.invalid> wrote in message
>> news:h6ru1b$1c0t$1...@news.ett.com.ua...
>>>
>>> LOL! Well, it does work if you're platform supports something like the
>>> NUL device.
>>
>> Humm, I suppose you could also use a dummy file.
>>
>>
>> [...]
>
>
> Here is another version of the program which uses a temporary file as a
> "fallback" just in case the file open fails with the standard names for
> some platforms NUL device:
[...]
> int
> stdnull_init(void)
> {
> if (! g_stdnull)
> {
> g_stdnull = fopen("/dev/nul", "w");
> if (! g_stdnull)
> {
> g_stdnull = fopen("nul", "w");
> if (! g_stdnull)
> {
> g_stdnull = tmpfile();
> if (! g_stdnull)
> {
> return 0;
> }
> }
> }
> }
> return 1;
> }
[...]
I should open the file using "r+" instead of "w". Sorry about that
non-sense.
;^/
Chris M. Thomasson
On Aug 24, 8:08 am, "Chris M. Thomasson" <n...@spam.invalid> wrote:
> "spinoza1111" <spinoza1...@yahoo.com> wrote in message
> > > Now all you have to do is change variables to Hungarian
> >
> > There can be a "downside" to Hungarian notation. This is very contrived
> > example of course but it could possibly happen. Think of prefixing a
> > bunch
> > of signed int variables with 'int' (e.g., `intMyVar'). Then for whatever
> > reason you decide to change them to unsigned variables. Well, you're
> > going
> > to have to change every variable name's prefix to `uint' or something
> > that
> > represents the variables unsigndness, so to speak.
> Boo hoo.
lol.
> What, are you still using edlin to edit? In a modern editor,
> case-sensitively changing int to uint while examining each change is
> baby stuff. You can use a regex to automate the change.
> I used systematic naming conventions in IBM 1401 SPS, when my editor
> was an IBM 026 keypunch. You young whippersnappers moan and groan
> about having to change things using fancy editors.
Na, it's just that we are all hardcore super lazy bastards!
=^D
> I used to have to
> walk to the computer center in the snow uphill both ways (etc.)
Let me guess, you were also barefoot right? Just kidding!
:^)
spinoza1111
> On Sun, 23 Aug 2009 19:13:30 -0700 (PDT),spinoza1111
>
> >On Aug 24, 8:27=A0am, "Chris M. Thomasson" <n...@spam.invalid> wrote:
> >> "spinoza1111" <spinoza1...@yahoo.com> wrote in message
> >> > It was a documented solution which keeps on
> >> > mallocing, freeing the malloc, and mallocing again until the sprintf
> >> > is completed or the remalloc fails.
>
> And if you documented the code it must be okay.
No. But if one documents the code PRIOR to coding, one does a better
job in my experience. See the free source code for my compiler. It can
be downloaded from Apress without buying my book, unfortunately and
boo hoo for me.
I code slow because I document prior, and I felt guilty for having to
bill a client for writing documentation. When, a few years prior, I'd
used True Basic to develop hydrostatic evaluation, I got the product
done faster although I had to create my own gui engine, since True
Basic supported strings without any nonsense.
One should be able to post C code here and expect it to run with all
compilers and on all platforms. Were C as good as Java, this would
indeed be possible. But as it is, one has to specify all sorts of
crazy command line options and compilers that will work. Now isn't the
ineluctable conclusion from this, that C most egregiously sucks?
When I started out, studly Dudley programmers in Chicago's Loop,
working for insurance companies like Prudential, clung to assembler
language precisely because they didn't want to feel like de-sexed
organization men (one such programmer said he and his mates brought
binoculars to work in order to watch hippies making love in Grant
Park, and that is just...sad). But the hard fact was that they were
more productive in Cobol, despite the numerous deficiencies of that
language (all global variables all the time, etc.)
C is at best a generalized assembler and for this reason it is
inappropriate to use it anywhere save in writing an operating system.
If you want to code in C, write an OS. If your employer sucks, form a
labor union. Anything else is mostly passive-aggression.
>
> I checked the gnu implmentation and they do the double evaluation
> also. There's simply clay feet everywhere.
Pity.
>
> Richard Harter, c...@tiac.nethttp://home.tiac.net/~cri,http://www.varinoma.com
spinoza1111
> On Sun, 23 Aug 2009 16:50:57 -0700 (PDT),spinoza1111
>
> <spinoza1...@yahoo.com> wrote:
> >On Aug 24, 1:58=A0am, c...@tiac.net (Richard Harter) wrote:
> >> On Sun, 23 Aug 2009 17:14:16 +0100, Flash Gordon
>
> >> Yes and no. He who barks at the moon has pointed to a real
>
> >Hey, CREEP, I'll thank you to use my name when you use my
> >contributions. It'sspinoza1111.
>
> to rumor, that barking dog, the name endowed upon you by your
> parents is Edward Nilges. However your true name, the one is your
> very essence, is He who barks at the moon. Deal with it.
>
> >There is, and I mentioned it in the OP. It's asprintf, and I
> >implemented it in 1991. It's available in the GNU compiler. My code
> >wasn't a "hack". It was a documented solution which keeps on
> >mallocing, freeing the malloc, and mallocing again until the sprintf
> >is completed or the remalloc fails.
>
> The trouble is that neither of the two methods that you mentioned
> are entirely satisfactory because they require re-evaluating the
> arguments. I expect that you will immediately appreciate why
> this is problematic. I have no idea what the GNU code does but I
> wouldn't be surprised if they put a layer on top of snprintf.
Oops. Thanks for pointing that out.
If an evaluation has side effects as in mySprintF("%s\n", p++) the way
to handle this would be making a pass through the format string while
evaluating as varargs all of the arguments. You shall have to make a
table of "final" pointers and lengths, and then use this table to do
the actual formatting.
You're going to have to malloc the table. If it is unbounded in the
general case, and it is, you're going to need to use malloc and
remalloc to expand it.
My goal is to stay withing the Unfriendly Confines of the C machine,
aka the C Nightmare. Truly heroic in my case, since I hate C. Rather
like Parsival inside Klingsor's unholy realm.
>
> Richard Harter, c...@tiac.nethttp://home.tiac.net/~cri,http://www.varinoma.com
spinoza1111
You have a strange notion of maturity, one that I saw first in the
1970s in structured walkthroughs. Structured walkthroughs were when
effective necessarily critical of a central tenet of modern
capitalism: that managers, merely because they are managers, know
everything (cf. in this connection John Kenneth Galbraith's essay "The
Economics of Innocent Fraud). Therefore, the effectiveness of
structured walkthroughs in many organizations was destroyed, in part
by *redefinining* what it means to be a grownup!
That is: the truth-telling, independent grownup, by pushing back
against management in the structured walkthrough, rapidly was coded in
this era as the "disruptive" element whose "pushback" (as it was known
within IBM and NASA) was delaying fulfillment of deadlines, deadlines
that were all-important because they were the only way for the MBA
types to know if they weren't being fucked over by the help (where
this concern is foregrounded when you fuck the help over).
"Maturity" rapidly became what Viennese call *schlamperei*, which is
untranslatable but roughly means "going along to get along", "not
rocking the boat", and "not biting the hand that feeds" (as if a
paycheck were a gift).
Tests for "maturity" were normalized for example to tests for "bad
language" in an increasingly Fundamentalist America in which the 1973
movie The Exorcist had translated all dissent into a form of cursing
and swearing and Satanism.
The result? Far from even "reinventing the wheel" in C, something that
would be constructive, you seem here to be making no progress, and
making the same mistakes over and over again, while marginalizing
people like Schildt and Navia...who in a just world would be the
leaders of this group and not its scapegoats.
I'm on topic, and I create interesting and somewhat useful threads in
this intellectual slum. Like Falstaff, I am witty in myself and the
cause of wit that is in other men, both in the sense of a levity that
is lacking in Heathfield's posts, and an alternate older meaning of
wit as intelligence, since I make you clowns think for a change. I can
even code C that occasionally even works. You should stump up a
collection and pay me to post, even as Heathfield is probably being
paid to post by his publisher, or the CIA.
>
> --
> Chris.
Keith Thompson
I never said it was. I have no authority here; I just offer my
opinion and my advice.
I suggest that his "throwing hissy fits and abusing people" does not
require a response. If you ignore him, he probably won't go away,
but he'll be much easier to ignore.
Old Wolf
> It would be useful if there were a sprintf variant that does not
> require the user to supply a buffer but which takes care of
> allocation and returns a pointer to the resulting formatted
> string.
How does it allocate the memory? Plenty
of devices that are programmed in C,
use various allocation strategies other
than a "malloc" or equivalent. This function
would be unnecessarily constraining, and
shouldn't be in the C standard. (It could
be in something like POSIX though). For the
same reason, strdup() isn't in C.
> And, of course, snprintf isn't part of C90.
C90 was deficient in this area; C99 fixed it.
What more do you want?
In C99 you can implement the Nilgewater
second suggestion of pre-parsing the input
to determine how much memory is needed.
He has declared he is going to reinvent the wheel anyway..
Old Wolf
> All of that said, calling snprintf twice is still a hack because
> every argument gets evaluated twice.
You would put it in a function, call
it my_asprintf() or something. Inside
that function you can use the C99
va_copy mechanism to be able to use
the arguments twice.
I'd be surprised if someone hasn't
posted code on the thread already!
(haven't read it all yet)
Old Wolf
implementing asprintf in C99, here it is:
#include <stdio.h>
#include <stdarg.h>
#include <stdlib.h>
char *my_asprintf(char const *fmt, ...)
{
va_list ap1, ap2;
char *p = NULL;
int len;
va_start(ap1, fmt);
va_copy(ap2, ap1);
len = vsnprintf(NULL, 0, fmt, ap1);
va_end(ap1);
if ( len > 0 )
p = malloc(len);
if ( p )
vsprintf(p, fmt, ap2);
va_end(ap2);
return p;
}
Old Wolf
> p = malloc(len);
I have an off-by-one error; this should be
p = malloc(len + 1);
Phil Carmody
> On Sun, 23 Aug 2009 22:39:38 +0200, jacob navia
> <ja...@nospam.org> wrote:
>
>>Richard Harter wrote:
>>>
>>> The problem is that applying a format specification to a set of
>>> arguments produces a string of unknown length. Snprintf "solves"
>>> the problem by failing to complete the production of the output
>>> string.
>>The first time you do:
>>
>>unsigned siz=1+snprintf(NULL,0,format_string,arg1,arg2,arg3);
>
> In this line of code snprintf fails to complete the production of
> the output string. All it produces is the length of the string.
>
>
>>char *buf = malloc(siz);
>>snprintf(buf,siz,format_string,arg1,arg2,arg3);
>
> Here, knowing the buffer size, snprintf can produce the output
> string.
The buffer size as was, yes. However, a signal handler's
changed the first char pointed to by argN from a '\0' to a ' '
in the meantime... ;-)
Phil
--
If GML was an infant, SGML is the bright youngster far exceeds
expectations and made its parents too proud, but XML is the
drug-addicted gang member who had committed his first murder
before he had sex, which was rape. -- Erik Naggum (1965-2009)
Phil Carmody
> Keith Thompson <ks...@mib.org> writes:
>
>>Chris McDonald <ch...@csse.uwa.edu.au> writes:
>>> spinoza1111 <spino...@yahoo.com> writes:
>>[more of the same]
>>> Just grow up Ed, else we'll all treat you like the trolling fool
>>> that you are.
>
>>Chris, what exactly is stopping you from treating him like the
>>trolling fool that he is now?
>
>>He's not going to change his behavior. You can. Please stop
>>feeding the troll.
>
>
> Ed trolling to hear the sound of his own voice is one thing,
> but Ed's throwing hissy fits and abusing people is another.
One is best ignored, and the other is best ignored?
Not seeing a difference there.
> Sorry Keith, but it's not your newsgroup, either.
It isn't, but I know that the two Chris' are >this< close to
being temporarily killfiled because all I ever see from them
are responses to Ed Bilges. (The other one's worse, though,
if that makes you feel happy.)
Chris McDonald
>It isn't, but I know that the two Chris' are >this< close to
>being temporarily killfiled because all I ever see from them
>are responses to Ed Bilges. (The other one's worse, though,
>if that makes you feel happy.)
That's fine - bye Phil.
Sorry, but I don't wish to be the target of Ed's bilious abuse
in a public forum.
--
Chris.
Ben Bacarisse
About, I think, asprintf:
> I checked the gnu implmentation and they do the double evaluation
> also. There's simply clay feet everywhere.
There is a twisty maze of function calls involved so I am not entirely
sure what is going on in glibc. What is this double evaluation that
is a sign of clay feet?
I don't think you can be talking about the rather crude double
evaluation problem that a macro would introduce, but neither does it
seem to be the more subtle problem of a value that formats differently
on two occasions despite the value itself not changing (for example a
pointer to a volatile static string that changes over time).
--
Ben.
Tom St Denis
> You're going to have to malloc the table. If it is unbounded in the
> general case, and it is, you're going to need to use malloc and
> remalloc to expand it.
>
> My goal is to stay withing the Unfriendly Confines of the C machine,
> aka the C Nightmare. Truly heroic in my case, since I hate C. Rather
> like Parsival inside Klingsor's unholy realm.
I was telling myself I was going to stay out of clc for a while but
alas here I am ...
I have a few questions for you
1) Why are you writing an application with unbounded input lengths?
In 99% of all applications it's sufficient to set limits on inputs
making this moot. What sort of strings are you processing that you
absolutely can't set an upper limit on?
2) Why is a two pass solution so bad?
3) w.r.t. having to use realloc/malloc/free/etc what do you think your
$FAVOURITE_LANGUAGE does anyways? You don't think Java doesn't just
behind the scenes realloc the memory it allocated once you concatenate
more data? How do you think computers work and why do you think this
is limited to C?
4) Why are you against writing a library that does the realloc/etc
behind the scenes and then just write applications that call your
library? And why would that be a sign that C is bad?
5) Why do we care?
Tom
Keith Thompson
The only way to avoid that is to ignore him. You *will* be the
target of his abuse if you keep responding to him. I don't wish
to be the target of a nest of hornets; it doesn't follow that I
should poke it with a stick.
Nick Keighley
> On Aug 24, 12:31 am, spinoza1111 <spinoza1...@yahoo.com> wrote:
> > You're going to have to malloc the table. If it is unbounded in the
> > general case, and it is, you're going to need to use malloc and
> > [realloc] to expand it.
>
> > My goal is to stay [within] the
...C language
> I was telling myself I was going to stay out of clc for a while but
> alas here I am ...
>
> I have a few questions for you
>
> 1) Why are you writing an application with unbounded input lengths?
he isn't he's writing a general purpose libray. (Almost) unbounded
strings,
arrays tables etc. are nice to write your application in terms of.
Your application may be bounded (are you sure though?) but a library
cannot be. I think its written into the GNU programming standards
that there should be no arbitary limits.
> In 99% of all applications it's sufficient to set limits on inputs
> making this moot. What sort of strings are you processing that you
> absolutely can't set an upper limit on?
he does seem to making life difficult for himself. I'm guessing a text
editor
for NASA sized data sets.
> 2) Why is a two pass solution so bad?
because you do two passes... It is two passes of printf which is a
little
language all of its own. The malloc()s may drown the printf()s (but
they
may not- we need measurements or analysis).
> 3) w.r.t. having to use realloc/malloc/free/etc what do you think your
> $FAVOURITE_LANGUAGE does [anyway]?
call malloc I expect. The point is *I* don't have to call malloc()
(or free() more to the point).
> You don't think Java doesn't just
> behind the scenes realloc the memory it allocated once you concatenate
> more data?
I'm sure Jave behaves in a similar fashion to $FAVOURITE_LANGUAGE
>How do you think computers work[?]
tiny tiny little elves carry bits around. Which are really small bits
of
electricity. Electricity is a sort of blueish fluff.
> and why do you think this is limited to C?
Real Men punch their own cards and single step at the console.
It you can't understand self modifying code you don't belong at the
console.
> 4) Why are you against writing a library that does the realloc/etc
> behind the scenes and then just write applications that call your
> library? And why would that be a sign that C is bad?
>
> 5) Why do we care?
his thesis is that he has to write the library whilst in
OTHER_LANGUAGE
it would be written for him. This is the argument for all computer
languages. He just thinks C is a particularly poor language. After
he's said
that once everything else is just trolling.
Oh and Spinoza. and already read your calling-me-a-troll-is-equivalent-
to-anti-sematism.
It's crap.
Dik T. Winter
...
> I covered that as C99's answer. C99's answer is no good. You replace
> the possibility of memory overwrites with the possibility of something
> that can be EVEN WORSE.
>
> This is the error no-one sees, where an snprintf truncates silently.
What is the return value if you tell it the buffer size is 0?
Moreover, the truncation is certainly not silently, the return value
is there not for nothing.
--
dik t. winter, cwi, science park 123, 1098 xg amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
Richard Harter
<old...@inspire.net.nz> wrote:
You need to read the rest of the thread. The reason it is a hack
is that the required length might be different on the second
pass.
Richard Harter, c...@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
Rui Maciel
> I believe that is what he was referring to with "The C99 solution
> (limit the number of characters) is extraordinarily poor ..."
...which doesn't make any sense and apparently was only mentioned to be able to launch personal attacks.
Rui Maciel
Rui Maciel
> I covered that as C99's answer. C99's answer is no good. You replace
> the possibility of memory overwrites with the possibility of something
> that can be EVEN WORSE.
How, exactly? The snprintf() function only truncates it's output if the programmer sets it's buffer size
smaller than the length of the string being passed to it. As the buffer size represents the string's maximum
acceptable length, if snprintf() truncates anything then it was due to the programmer's incompetence and not
due to a library and much less a language problem.
<snip dramatic nonsense>
Rui Maciel
Richard Harter
A simple implementation makes two passes over the arguments. The
first determines the length of the formatted output string.
Space is then allocated for a buffer to hold the string. Then a
second pass is made to write the formatted output string into the
buffer.
The catch is that the formatted strings determined by the two
passes don't have to be the same. The arguments are expressions
that can be differ in content and size from pass 1 to pass 2.
For example:
asprintf(char ** buffer,"%s\n",fortune_cookie());
where fortune_cookie() returns a different cookie each time it is
called.
jacob navia
No, in this case it will be evaluated once: when asprintf is
called.
I just can't understand what happens with you today.
Did you drank your coffee? You seem asleep.
lcc-win implements asprintf, as many other compilers do.
It is a pity that the C99 committee did not
standardize existing practice. It is a very practical function.
Chris M. Thomasson
news:b8cfd098-4ab6-4d1e...@x6g2000prc.googlegroups.com...
I attempted to emulate `asprintf()' in a pre-C99 environment here:
http://clc.pastebin.com/f63d41ab5
I was wondering if I am misusing the varargs in the function `my_asprintf()'
in any way that might get me into undefined behavior land? Please note that
I have fairly limited experience with them and probably missed something
important!
;^o
Thanks.
Chris M. Thomasson
news:87vdkdm...@kilospaz.fatphil.org...
> Chris McDonald <ch...@csse.uwa.edu.au> writes:
>> Keith Thompson <ks...@mib.org> writes:
>>
>>>Chris McDonald <ch...@csse.uwa.edu.au> writes:
>>>> spinoza1111 <spino...@yahoo.com> writes:
>>>[more of the same]
>>>> Just grow up Ed, else we'll all treat you like the trolling fool
>>>> that you are.
>>
>>>Chris, what exactly is stopping you from treating him like the
>>>trolling fool that he is now?
>>
>>>He's not going to change his behavior. You can. Please stop
>>>feeding the troll.
>>
>>
>> Ed trolling to hear the sound of his own voice is one thing,
>> but Ed's throwing hissy fits and abusing people is another.
>
> One is best ignored, and the other is best ignored?
> Not seeing a difference there.
>
>> Sorry Keith, but it's not your newsgroup, either.
>
> It isn't, but I know that the two Chris' are >this< close to
> being temporarily killfiled because all I ever see from them
> are responses to Ed Bilges. (The other one's worse, though,
> if that makes you feel happy.)
I think I have the right to respond to spinoza1111. If that get's me
killfiled, well, shi% happens.
;^/
Keith Thompson
[...]
> A simple implementation makes two passes over the arguments. The
> first determines the length of the formatted output string.
> Space is then allocated for a buffer to hold the string. Then a
> second pass is made to write the formatted output string into the
> buffer.
>
> The catch is that the formatted strings determined by the two
> passes don't have to be the same. The arguments are expressions
> that can be differ in content and size from pass 1 to pass 2.
> For example:
>
> asprintf(char ** buffer,"%s\n",fortune_cookie());
>
> where fortune_cookie() returns a different cookie each time it is
> called.
Unless asprintf is a macro, it's not going to call fortune_cookie()
more than once.
Then again, "char **buffer" isn't a valid argument unless it is a
macro -- but the GNU asprintf is just a variadic function.
Richard Harter
<old...@inspire.net.nz> wrote:
>On Aug 24, 5:58=A0am, c...@tiac.net (Richard Harter) wrote:
>> It would be useful if there were a sprintf variant that does not
>> require the user to supply a buffer but which takes care of
>> allocation and returns a pointer to the resulting formatted
>> string.
>
>How does it allocate the memory? Plenty
>of devices that are programmed in C,
>use various allocation strategies other
>than a "malloc" or equivalent. This function
>would be unnecessarily constraining, and
>shouldn't be in the C standard. (It could
>be in something like POSIX though). For the
>same reason, strdup() isn't in C.
I opine that the allocation question is a red herring - if you
use it you use its allocator to get rid of the storage. You
don't like its allocation, don't use it.
That is a good qustion - where do you put it? One way would be
to add a section to the standard that specifies standard
extensions. A conforming implementation needn't provide the
standard extensions but it must meet the specifications if it
does.
None of this is going to happen, of course.
>
>> And, of course, snprintf isn't part of C90.
>
>C90 was deficient in this area; C99 fixed it.
>What more do you want?
>
>In C99 you can implement the Nilgewater
>second suggestion of pre-parsing the input
>to determine how much memory is needed.
>
>He has declared he is going to reinvent the wheel anyway.
I wouldn't be surprised if it were one of those three sided
things with constant radius.
Keith Thompson
[...]
> I think I have the right to respond to spinoza1111. If that get's me
> killfiled, well, shi% happens.
Certainly you have that right, just has he has the right to be
a troll.
Please consider whether the annoyance it causes to others and the
damage it does to this newsgroup's S/N ration is worth whatever
satisfaction it brings you.
Ben Bacarisse
> On Mon, 24 Aug 2009 11:31:31 +0100, Ben Bacarisse
> <ben.u...@bsb.me.uk> wrote:
>
>>c...@tiac.net (Richard Harter) writes:
>>
>>About, I think, asprintf:
>>
>>> I checked the gnu implmentation and they do the double evaluation
>>> also. There's simply clay feet everywhere.
>>
>>There is a twisty maze of function calls involved so I am not entirely
>>sure what is going on in glibc. What is this double evaluation that
>>is a sign of clay feet?
>>
>>I don't think you can be talking about the rather crude double
>>evaluation problem that a macro would introduce, but neither does it
>>seem to be the more subtle problem of a value that formats differently
>>on two occasions despite the value itself not changing (for example a
>>pointer to a volatile static string that changes over time).
>
> A simple implementation makes two passes over the arguments.
It seems you are claiming that glibc uses such a simple implementation
but when I looked i could not see any evidence for two passes. I
accept that I got lost in the maze of function that implement the
printf family so I may have missed something. Can you point to the
code that shows glibc's clay feet in this matter?
Maybe you did not mean glibc when you said GNU. There is a lot of GNU
code after all...
> The
> first determines the length of the formatted output string.
> Space is then allocated for a buffer to hold the string. Then a
> second pass is made to write the formatted output string into the
> buffer.
>
> The catch is that the formatted strings determined by the two
> passes don't have to be the same. The arguments are expressions
> that can be differ in content and size from pass 1 to pass 2.
> For example:
>
> asprintf(char ** buffer,"%s\n",fortune_cookie());
>
> where fortune_cookie() returns a different cookie each time it is
> called.
That (presumably) is because you assume a macro implementation of
asprintf that references the argument list more than once. glibc does
use a macro but not in that way (it simply makes asprintf and call to
some internal __IO_xxx function). Were you looking at a very old
implementation or did I misunderstand the code?
--
Ben.
Rui Maciel
> (Sigh). How do you know the size of the "buffer" you do need?
Please provide an example where the programmer doesn't know the size of the string that he must pass to
snprintf().
Rui Maciel
jacob navia
void LogError(char *ErrorMessage,int errorcode, char *callingFunction)
{
// Here you do not know anything about the length of the arguments
}
Ben Bacarisse
> On Sun, 23 Aug 2009 22:54:37 -0700 (PDT), Old Wolf
<snip>
>>He has declared he is going to reinvent the wheel anyway.
>
> I wouldn't be surprised if it were one of those three sided
> things with constant radius.
I can't decide if this is an in-joke for mathematicians or if you
intended to write "diameter" rather than "radius".
--
Ben.
Flash Gordon
> c...@tiac.net (Richard Harter) writes:
>> On Sun, 23 Aug 2009 22:39:38 +0200, jacob navia
>> <ja...@nospam.org> wrote:
>>
>>> Richard Harter wrote:
>>>> The problem is that applying a format specification to a set of
>>>> arguments produces a string of unknown length. Snprintf "solves"
>>>> the problem by failing to complete the production of the output
>>>> string.
> ...
>>> The first time you do:
>>>
>>> unsigned siz=1+snprintf(NULL,0,format_string,arg1,arg2,arg3);
>> In this line of code snprintf fails to complete the production of
>> the output string. All it produces is the length of the string.
>>
>>
>>> char *buf = malloc(siz);
>>> snprintf(buf,siz,format_string,arg1,arg2,arg3);
>> Here, knowing the buffer size, snprintf can produce the output
>> string.
>
> The buffer size as was, yes. However, a signal handler's
> changed the first char pointed to by argN from a '\0' to a ' '
> in the meantime... ;-)
The signal handler could mess you up during a call to printf...
buffer initially contains "123\0"
printf gets as far as printing "12"
signal handler changes buffer to "1\0XX"
Oops, printf wanders off in to the wild blue yonder despite the buffer
being printed with %s always containing a valid string (followed by some
garbage).
Oh, and the signal handler is padding the buffer with X because it
should only contain digits and this makes it easy to see corruption... ;-)
The moral being that when dealing with memory that might be written to
by a signal handler you need to use volatile sig_atomic_t or implement
some form of locking (in a generic sense, not a specific sense). If you
don't do that you are bound to get strange and unusual problems.
--
Flash Gordon
Flash Gordon
The same would apply to a user written implementation of asprintf using
vsnprintf.
> lcc-win implements asprintf, as many other compilers do.
> It is a pity that the C99 committee did not
> standardize existing practice. It is a very practical function.
I would have more use for a slightly different function, one where you
pass in a pointer to a pointer to a malloc'd block which it then expands
if necessary. reasprintf?
It's not hard to implement, so I'm not bothered. I would have no
objection to it being added.
--
Flash Gordon
Charlton Wilbur
troll> As I have said, the grammar of "troll" is isomorphic to "Jew"
troll> in anti- Semitic tracts.
You mean that the *usage* of "troll" is analogous to "Jew"; however, in
that, you're wrong. "Jew" describes an essential quality of a person,
whether ethnicity or religion, while "troll" describes a style of
anti-social behavior.
troll> It derives from Nordic racist texts,
It doesn't, actually; it derives from the verb "to troll," as in for
fish, by dangling a line with one or more baited hooks and waiting for
the fish to bite. The fact that it has a double meaning, in that it
also refers to a repulsive creature that hides below bridges, probably
accounts for its longevity, but it's not the original source.
troll> and it fulfills here the function of racism: unifying the
troll> community against the outsider, no matter how that outsider
troll> is marked...here by his ability to write above a small lower
troll> bound of complexity in an unusual combination with
troll> programming skill somewhat above the norm, and the fact that
troll> he was programming C when you were shitting your pants.
You flatter yourself overmuch.
Charlton
--
Charlton Wilbur
cwi...@chromatico.net
lawrenc...@siemens.com
>
> There can be a "downside" to Hungarian notation. This is very contrived
> example of course but it could possibly happen. Think of prefixing a bunch
> of signed int variables with 'int' (e.g., `intMyVar'). Then for whatever
> reason you decide to change them to unsigned variables. Well, you're going
> to have to change every variable name's prefix to `uint' or something that
> represents the variables unsigndness, so to speak.
Although quite common, that's a complete misuse of Hungarian notation.
The fundamental idea was to use *high level* data types like length,
temperature, and person, not low level data types like int and double.
The data type was supposed to be the used for variable name with
prefixes for things like "pointer to" or "array of", and suffixes only
where necessary to distinguish multiple variables of the same type in
the same scope.
--
Larry Jones
You can never really enjoy Sundays because in the back of your
mind you know you have to go to school the next day. -- Calvin
John Bode
[snip]
> The problem is that any sprintf whatsoever, insofar as it formats
> strings, has no control over string length. Most code I've seen
> decides to create some silly "buffer" of some silly size.
>
> But in
>
> sprintf(buf, "%s\n", ptr)
>
> characters past the allocated end of "buf" may be overwritten.
>
Use the precision specification with a wildcard value as part of the
conversion specifier, then provide the precision size as an argument
to *printf:
sprintf(buf, "%.*s", (int) sizeof buf - 1, ptr);
will limit the result string to fit in buf (at least up to INT_MAX
characters).
Rui Maciel
> void LogError(char *ErrorMessage,int errorcode, char *callingFunction)
> {
> // Here you do not know anything about the length of the arguments
> }
Where would you intend to use snprintf() in that case?
Rui Maciel
Chris M. Thomasson
news:4a93098f$0$21205$a729...@news.telepac.pt...
Perhaps to build a formatted log message and store it into a buffer?
spinoza1111
> Chris M. Thomasson <n...@spam.invalid> wrote:
>
>
>
> > There can be a "downside" to Hungarian notation. This is very contrived
> > example of course but it could possibly happen. Think of prefixing a bunch
> > of signed int variables with 'int' (e.g., `intMyVar'). Then for whatever
> > reason you decide to change them to unsigned variables. Well, you're going
> > to have to change every variable name's prefix to `uint' or something that
> > represents the variables unsigndness, so to speak.
>
> Although quite common, that's a complete misuse of Hungarian notation.
> The fundamental idea was to use *high level* data types like length,
> temperature, and person, not low level data types like int and double.
"Apps Hungarian" turned out to be less useful than "system Hungarian".
Simonyi's was apps, but simultaneously with his "invention", systems
Hungarian was already in use in IBM mainframe assembler programming.
Its inventors were unknown, so Simonyi gets the credit.
I read about a form of one-character "Hungarian" in a book by Diebold
published in 1960 about 1401 assembler programming. The practice
predated Simonyi.
spinoza1111
> >>>>> "troll" ==spinoza1111 <spinoza1...@yahoo.com> writes:
>
> troll> As I have said, the grammar of "troll" is isomorphic to "Jew"
> troll> in anti- Semitic tracts.
>
> You mean that the *usage* of "troll" is analogous to "Jew"; however, in
> that, you're wrong. "Jew" describes an essential quality of a person,
> whether ethnicity or religion, while "troll" describes a style of
> anti-social behavior.
Words, mere words, aren't "behavior".
>
> troll> It derives from Nordic racist texts,
>
> It doesn't, actually; it derives from the verb "to troll," as in for
> fish, by dangling a line with one or more baited hooks and waiting for
> the fish to bite. The fact that it has a double meaning, in that it
> also refers to a repulsive creature that hides below bridges, probably
> accounts for its longevity, but it's not the original source.
The word "troll" was in fact in use in California in the 1980s by
homeowners and landlords to refer to homeless people. A T shirt was
printed up with a picture of the "not" semiotic superimposed over a
"repulsive" creature with a runny nose.
This was unfair to homeless people, because it blamed the victim for
his victimization even as the Nazis found the Jews in the ghettos the
Nazis created to be "repulsive".
When a person (in Navia's case, an accomplished and intelligent
person) has views that don't reinforce the low "standards" of your
community, he is hounded and when he responds, you blame him for being
a "drama queen". Likewise, many (not all) "trolls" are simply using
the medium as intended to reply to slurs.
>
> troll> and it fulfills here the function of racism: unifying the
> troll> community against the outsider, no matter how that outsider
> troll> is marked...here by his ability to write above a small lower
> troll> bound of complexity in an unusual combination with
> troll> programming skill somewhat above the norm, and the fact that
> troll> he was programming C when you were shitting your pants.
>
> You flatter yourself overmuch.
I don't think I do. At any rate, one community norm is that the
thought leaders like Heathfield will primarily engage in negative
correction, being at pains to torpedo ideas without being able to
contribute anything new. For example, Heathfield tells us in "Another
Spinoza Challenge" that "C does not have call be reference", meaning
that "call by reference" is implemented using the value of the
address.
In this community, Job One is strangling new ideas and contributions
at birth, and the label "troll" fulfills this function.
It may sound hip and cool, but like most hip putdowns, it accomplishes
the task of domination.
>
> Charlton
>
> --
> Charlton Wilbur
> cwil...@chromatico.net